สิ่งที่ควรพิจารณาสำหรับเว็บไซต์“ ยอดเยี่ยม” และต่อต้าน?

บริษัท ของฉันกำลังพิจารณาที่จะรวมแอพพลิเคชั่นและไซต์เทียร์ 1 (เช่นการผลิตขั้นปลาย) ลงในฐานรหัสที่ครอบคลุมทั้งหมด

ทฤษฎีคือการอนุญาตการออกแบบและฟังก์ชั่นโดยรวมของพวกเขาสามารถเป็นเนื้อเดียวกันและการจัดการจากส่วนกลาง

ฉันไม่มีข้อกังวลใด ๆ เกี่ยวกับวิธีการนี้เนื่องจากโครงสร้างข้อมูลที่สนับสนุนแต่ละแอปพลิเคชันแตกต่างกันมากกฎเกณฑ์ทางธุรกิจมีความซับซ้อนและเป็นเอกลักษณ์ของแต่ละแอปพลิเคชันและฐานรหัสโดยรวมสำหรับแอปพลิเคชันที่มีอยู่นั้นแตกต่างกันมาก

แก้ไข :

สภาพแวดล้อมในปัจจุบันประกอบด้วยไซต์ ASP.Net 1.1 สามแห่งที่แทบจะไม่เคยเห็นความรักที่แท้จริงเลยตั้งแต่แรกถูกเขียน (เนื่องจากส่วนใหญ่ไม่มีนักพัฒนาที่มีประสบการณ์ใน บริษัท ) และแอปพลิเคชัน MVC2 หนึ่งที่เคยเป็นไซต์ ASP.Net 1.1 ก่อน อัพเกรดเมื่อปีที่แล้ว เราเขียนเฉพาะใน C #

บริษัท มีขนาดค่อนข้างเล็กมีพนักงานประมาณ 50 คน สามคนเป็นนักพัฒนาที่แท้จริง การจัดการ (แม้แต่การจัดการด้านไอที) ไม่มีภูมิหลังด้านไอทีหรือประสบการณ์ใด ๆ นอกเหนือจากการจัดการโครงการของโครงการด้านไอที (และดังนั้นบางคนก็ผ่านความรู้เกี่ยวกับคำศัพท์และผลกระทบทางธุรกิจ)

แอปพลิเคชั่นส่วนใหญ่เป็นบริการออนไลน์เพื่อสนับสนุนผลิตภัณฑ์ที่ขายโดย บริษัท บริษัท ไม่ได้จำหน่ายซอฟต์แวร์ใด ๆ โดยตรง

ดังนั้นเพื่อวลีสถานการณ์ทั้งหมดนี้ในคำถามที่เฉพาะเจาะจงและมีเหตุผลตอบ: อะไรคือเหตุผลที่น่าสนใจสำหรับและต่อต้านการพยายามดึงระบบทั้งหมดของคุณเข้าด้วยกันเป็นโซลูชัน over-arching เดียวที่กำหนดเงื่อนไขปัจจุบัน (เช่นฐานรหัสเก่าระบบธุรกิจที่ซับซ้อนและกฎ )?

ความคิดที่ไม่ดี

ปฏิกิริยานี้ขึ้นอยู่กับสมมติฐานดังต่อไปนี้:

1. มีแอปพลิเคชั่นที่แตกต่างกันค่อนข้างมากซึ่งถูกทำให้เป็นเนื้อเดียวกัน
2. มีหลายทีมที่ทำงานกับแอพพลิเคชั่นที่แตกต่างกัน
3. ไม่มีสถาปนิกซอฟต์แวร์ที่ได้รับการยอมรับและมีอำนาจจัดการแอพพลิเคชั่นอย่างแข็งขัน

จะเกิดอะไรขึ้นถ้าคุณไปข้างหน้า

ส่วนใหญ่แล้วจะมีความพยายามที่รวมเข้าด้วยกันเพื่อนำทุกอย่างมารวมกันภายใต้วิธีการออกแบบเดียว สิ่งนี้จะแสดงให้เห็นถึงความพยายามอย่างมากที่จำเป็นในการทำให้ทุกอย่างทำงานเหมือนกันและอาจถูกบรรจุกระป๋องว่าใช้งานไม่ได้

หากกดบนพื้นที่เก็บข้อมูลส่วนกลางบางประเภทที่มีข้อมูลการกำหนดค่า (เช่นการเข้าถึงการรักษาความปลอดภัยระดับการบันทึกเป็นต้น) จะต้องตรงจุดที่ใครบางคนจะชี้ให้เห็นอย่างชัดเจนและพูดว่า

"เฮ้ทำไมเราไม่แค่ดัดแปลงวิธีการกำหนดค่าภายนอกนี้ไปยังแอปพลิเคชันเก่ามันจะเร็วกว่านี้มาก"

และอีกสักครู่ต่อมาคนอื่นจะก้าวไปด้วย

"และเนื่องจากเรากำลังปรับโครงสร้างใหม่อยู่แล้วทำไมเราไม่ใช้มาตรฐานการออกแบบสำหรับแต่ละโดเมนแอปพลิเคชัน - การประมวลผลทางเว็บมีลักษณะเช่นนี้การประมวลผลกฎธุรกิจเช่นนี้และการเข้าถึงฐานข้อมูลเช่นนี้"

จนกระทั่งในที่สุด

"โอ้และมีรหัสทั่วไปจำนวนมากที่นี่ทำไมไม่รวบรวมห้องสมุดที่ใช้ร่วมกันได้ง่ายเราอาจต้องใช้การรวมการทำงานบางอย่างในช่วงเวลาปกติพูดทุกคืน"

ณ จุดนี้ทุกคนถอนหายใจด้วยความโล่งอกที่เสาหินขนาดมหึมาไม่ได้ถูกสร้างขึ้น

เราทำงานนี้กับ บริษัท ของฉัน ฉันคิดว่ามันเป็นไปได้และมีประโยชน์ที่ชัดเจน (คุณพูดถึงพวกเขา) อย่างไรก็ตามนี่อาจจะเป็นโครงการ 5 ถึง 7 ปีอย่างน้อยที่สุดแน่นอนและต้องการทุกอย่างที่จะต้องเขียนใหม่ หากคุณสามารถลงชื่อออกในบางสิ่งเช่นนั้นฉันก็จะบอกว่าให้ทำ ถ้าไม่เช่นนั้นเตรียมตัวให้พร้อมสำหรับการเสียชีวิตในเดือนมีนาคม

Googleไม่ได้ดังนั้นก็แน่นอนเป็นไปได้

ลิงค์นั้น BTW เป็นงานนำเสนอที่น่าสนใจจาก Googler เกี่ยวกับวิธีจัดการฐานรหัสการรวมระบบอย่างต่อเนื่องการทดสอบและอื่น ๆ

หากไม่มีความมุ่งมั่นอย่างแรงกล้าในการใช้เครื่องมืออย่างไรก็ตามอย่างที่ Google ทำคุณมีแนวโน้มที่จะได้รับบาดเจ็บ

คำถามที่สำคัญนี่คือเหตุผลว่าทำไม ? ทำไมผู้บริหารระดับสูงถึงต้องการทำเช่นนี้? พวกเขาหวังว่าจะได้ประโยชน์จากการออมการใช้ประโยชน์หรือประโยชน์อื่นใด

หากคุณสามารถจัดการปัญหาเหล่านั้นให้เพียงพอเพื่อให้บรรลุเป้าหมายคุณอาจหลีกเลี่ยงฐานรหัสเดียวที่เกี่ยวข้องกับคุณในขณะที่ยังคงให้ผลลัพธ์ที่มีประสิทธิภาพเช่นเดียวกัน

เราได้ผ่านกระบวนการที่คล้ายกัน เรามีผลิตภัณฑ์ที่มีมาระยะหนึ่งแล้ว ปีที่แล้วเราเปิดตัวผลิตภัณฑ์อื่นที่ 95% เหมือนกับผลิตภัณฑ์แรกโดยบางครั้ง 5% ของความแตกต่างที่ลึกซึ้ง แต่บางครั้งก็มีความแตกต่างอย่างมีนัยสำคัญกับความแตกต่างเหล่านั้นจะได้รับการพัฒนาและดูแลโดยทีมแยกต่างหาก

เมื่อเราเริ่มทำงานกับผลิตภัณฑ์ใหม่ทีมเก่ายังคงทำการเปลี่ยนแปลงที่ส่งผลกระทบต่อเราใน 5% นั้นเนื่องจากพวกเขาไม่เข้าใจผลิตภัณฑ์ใหม่ ดังนั้นเราจึงแยกรหัส 5% ออกซึ่งทำให้เราสามารถปล่อยรุ่นแรกให้เสร็จตรงเวลา

จากนั้นงานบำรุงรักษาก็เริ่มมากขึ้นและเราพบว่าเราทำการเปลี่ยนแปลงรหัสเกือบเหมือนกันเกือบทุกครั้ง ทีมเก่ายังมีความเข้าใจที่ดีขึ้นมากเกี่ยวกับผลิตภัณฑ์ใหม่ในตอนนี้ดังนั้นเราจึงค่อยๆรวบรวมสิ่งที่เราคดเคี้ยวอีกครั้งและค้นหาวิธีสถาปัตยกรรมที่มีประสิทธิภาพมากขึ้นเพื่อแสดงความแตกต่าง

ดังนั้นเมื่อคุณบอกว่าโครงสร้างข้อมูลนั้นแตกต่างกันและฐานรหัสโดยรวมนั้นไม่เหมือนกันคำถามที่ฉันจะถามก็คือถ้ามันต้องเป็นแบบนั้นหรือนั่นเป็นวิธีที่พวกมันวิวัฒนาการมา เห็นได้ชัดว่าคุณต้องคำนึงถึงกฎและข้อกำหนดทางธุรกิจที่แตกต่างกัน แต่กุญแจสำคัญคือการแยกความแตกต่างเหล่านั้นออกเป็นโมดูลที่เล็กที่สุดเท่าที่จะเป็นไปได้ หากคุณมักจะพบว่าตัวเองกำลังใช้คุณสมบัติเดียวกันที่แน่นอนสำหรับลูกค้าหลายรายด้วยวิธีที่แตกต่างกันเล็กน้อยสำหรับฐานรหัสที่แตกต่างกันการรวมบัญชีสามารถช่วยได้จริงๆและฉันสงสัยว่ากรณีหรือการจัดการอาจไม่ได้เสนอ

คุณมักจะไม่สามารถรวบรวมแอปพลิเคชั่นจำนวนมากไว้ในฐานรหัสเดียวกันได้เพราะจะใช้ความพยายามอย่างมากและสำหรับโปรแกรมเก่าที่ถูกทอดทิ้งซึ่งอาจทำงานได้มากกว่าที่คาดไว้ในตอนแรก

ที่กล่าวว่าไม่มีอะไรผิดปกติในการมีแอปพลิเคชันทั้งหมดของคุณในที่เก็บรหัสเดียวกันซึ่งแต่ละแอปพลิเคชันมีพื้นที่แยกต่างหาก สิ่งนี้ช่วยให้คุณมีเอกสารออนไลน์ที่สร้างขึ้นสำหรับฐานรหัสทั้งหมดในมุมมองเดียวที่สอดคล้องซึ่งโดยทั่วไปเป็นสิ่งที่ดีตามที่คุณต้องการให้มองเห็นได้มากที่สุดเท่าที่จะทำได้

ผู้ที่ตัดสินใจในเรื่องนี้ควรพิจารณาอย่างยิ่งว่าทำไมพวกเขาถึงต้องการทำเช่นนั้นและพิจารณาว่าพวกเขาต้องการทำงานมากแค่ไหน

หากมีสิ่งเดียวที่ทำให้การพัฒนาองค์กรไม่มีประสิทธิภาพและมีราคาแพงมันเป็นภาพลวงตาที่เป็นไปได้ที่จะสร้างระบบเดียวที่ทำทุกอย่าง หากคุณมีเจ้าของผลิตภัณฑ์เพียงคนเดียวที่เข้าใจรายละเอียดทั้งหมดของระบบและสามารถตัดสินใจทั้งหมดโดยไม่ต้องใช้เวลาหนึ่งสัปดาห์ในการประชุมอาจใช้งานได้ แต่ฉันไม่เคยเห็นว่าเกิดขึ้น

โดยทั่วไปแล้วคุณจะดีกว่าถ้าคุณปฏิบัติต่อมันมากกว่าการพัฒนาสำหรับอินเทอร์เน็ต - เพียงแค่สร้างแอปของคุณเองยอมรับว่าในทางปฏิบัติคุณไม่มีการควบคุมอะไรเลยนอกรหัสของคุณเอง คุณสามารถได้รับความสอดคล้องทั้งหมดที่คุณต้องการด้วย OAuth และ API อย่างง่ายสำหรับการตั้งค่าผู้ใช้และ CSS ที่แชร์เล็กน้อย

มันค่อนข้างคล้ายกับเจตนาดั้งเดิมของ SOA แต่ถ้าคุณเรียกมันว่าคุณจะต้องจบลงด้วยระบบการทำงานขนาดใหญ่ที่แตกต่างและแทบจะไม่พยายามทำทุกอย่าง

ความคิดแรกของฉันคือสิ่งนี้จะเป็น PITA ทั้งหมดสำหรับการเผยแพร่

การแยกฟังก์ชั่นที่จัดการได้นั้นมีเหตุผลมากขึ้นหากหลีกเลี่ยงเลเยอร์การจัดการและการอนุมัติทั้งหมด

การแบ่งสิ่งที่พบบ่อยออกเป็นส่วนประกอบ / บริการและสร้างมาตรฐานให้กับ IMHO นั้นจะง่ายกว่ามาก

คุณสามารถวิธีนี้แตกต่างกันโดยใช้เทคโนโลยีบูรณาการเช่นการช่วยกู้กับรูปแบบของการใช้งานเว็บของคุณในทำนองเดียวกัน โดยพื้นฐานแล้วแต่ละแอปพลิเคชันยังคงแยก การจัดส่งใช้กฎ XSLT เพื่อตัดทอนผลลัพธ์ของตนเป็นเทมเพลต HTML แบบคงที่ที่คุณออกแบบ สิ่งนี้ทำให้ธีม HTML / CSS แบบคงที่ค่อนข้างง่ายสามารถนำไปใช้กับชุดแอปพลิเคชันทั้งหมดที่มีความฉิบหายน้อยที่สุด