ทำไมทีมพัฒนายืนยันว่าการใช้โซลูชันเดียวสำหรับหลายโครงการใน Visual Studio“ เพิ่มความซับซ้อนในการพึ่งพาซึ่งกันและกัน”

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

สิ่งนี้มีผลกระทบที่เป็นอันตรายต่อการสร้างความน่าเชื่อถือและคุณภาพเนื่องจากพวกเขาไม่ได้ส่งซอร์สโค้ดที่ทันสมัยที่สุดมาให้เราเสมอ เราพยายามที่จะกดพวกเขาเพื่อรวมรหัสอ้างอิงทั้งหมดในโซลูชันเดียว แต่เราได้รับการต่อต้าน - โดยเฉพาะพวกเขาพูดคุยเกี่ยวกับการพึ่งพาซึ่งกันและกันระหว่างโมดูล (อ่าน "โครงการ" ใน Visual Studio) เพิ่มขึ้นหากทุกอย่างอยู่ใน ไฟล์โซลูชันเดียว ไม่มีการใช้รหัสใดในโซลูชันแยกต่างหากที่อื่น

ฉันยืนยันว่านี่เป็นเรื่องไร้สาระและรูปแบบการพัฒนาที่ดีจะหลีกเลี่ยงปัญหาดังกล่าว

ทีมที่มีปัญหายังดำเนินการแก้ไขข้อผิดพลาดและการพัฒนาคุณสมบัติใหม่ในผลิตภัณฑ์ที่มีอยู่ซึ่งประสบการณ์ที่ได้รับนั้นเต็มไปด้วยปัญหาที่พูดได้น้อยที่สุดและได้รับความทุกข์ทรมานจากปัญหาเดียวกัน เราถูกปฏิเสธการเข้าถึงแหล่งควบคุม ( TFS ) ของพวกเขาและวิธีการที่เราดำเนินการเพื่อรวมรหัสฐานคือการพยายามและลดจำนวนของการอัปเดตที่ขาดหายไปและอย่างน้อยก็ลดลงเป็นครั้งคราว (ใช่แล้ว - แนะนำให้รู้จักกับผลิตภัณฑ์) โดยการพูดว่า "ส่ง ZIP ของโฟลเดอร์โซลูชันทั้งหมดให้เราเพื่อให้เราสามารถคลายซิปเปิดใน Visual Studio และกดF5 สำหรับการทดสอบ "ในแง่ของโครงสร้างและคุณภาพทั่วไปรหัสนั้นค่อนข้างแย่และยากที่จะให้การสนับสนุนประสบการณ์นี้เป็นสาเหตุที่ฉันตั้งใจจะทำให้กระบวนการทำงานถูกต้องในช่วงต้นของการพัฒนาให้เร็วที่สุดเท่าที่จะทำได้

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

คุณไม่จำเป็นต้องบอกวิธีจัดโครงสร้างโครงการของพวกเขา แต่ให้เป็นข้อกำหนดที่ยากมากที่คุณสามารถสร้างระบบจากแหล่งที่มาด้วยการเรียกใช้สคริปต์เดียวโดยไม่เกิดข้อผิดพลาดใด ๆ หากสคริปต์นั้นเรียกใช้ Visual Studio หรือ Msbuild หรือเครื่องมืออื่น ๆ และหากเรียกใช้ครั้งเดียว 50 หรือ 100 ครั้งก็ไม่ควรเกิดปัญหา

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

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

อย่างไรก็ตามฉันขอแนะนำให้เพิ่มสคริปต์สร้าง สิ่งนี้มีประโยชน์แม้ว่าจะมีไฟล์โซลูชันเพียงไฟล์เดียวเท่านั้น ตัวอย่างเช่นมันอนุญาตให้หนึ่งรัน VS build ด้วยการกำหนดค่าที่ต้องการให้คุณคัดลอกไฟล์สุดท้ายสำหรับการปรับใช้ (และไม่มีอะไรเพิ่มเติม) ไปยังโฟลเดอร์ "deploy" และอาจใช้เครื่องมือและขั้นตอนอื่น ๆ เพื่อทำให้การสร้างเสร็จสมบูรณ์ ดูF5 ไม่ใช่กระบวนการสร้าง! และการทดสอบโจเอล

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

ในทีมพัฒนาฉันเป็นส่วนหนึ่งของเรามีไลบรารี่อิสระที่เราเขียนซึ่งใช้ในหลาย ๆ ผลิตภัณฑ์เป็นโซลูชันแยกต่างหากซึ่งในกรณีนี้มันสมเหตุสมผลหรือไม่อย่างนั้นเราจะต้องรวบรวม Application A เพื่อทำให้ Application B ทันสมัยอยู่เสมอ ซึ่งอาจจำเป็นต้องปรับปรุง Application C ให้ทันสมัยอยู่เสมอ

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

บริษัท ซอฟต์แวร์ทุกแห่งที่ฉันเคยทำงานให้มีทีมพัฒนาหลักที่ให้สาขาใหญ่ครอบคลุมกรณีการใช้งานพื้นฐานของผลิตภัณฑ์ของ บริษัท

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

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

ดังนั้นกำหนดวิสัยทัศน์ที่ยิ่งใหญ่ของคุณลงในคำขอดึงที่ทำลายล้างไม่กี่ที่แกนกลางและเตรียมที่จะปกป้องตัวเองในการทบทวน!

มีเคอร์เนลของความจริงในการยืนยัน "การใช้โซลูชั่นเดียวสำหรับหลายโครงการเพิ่มความซับซ้อนซึ่งกันและกัน"

วิธีแก้ปัญหาเดียวทำให้การอ้างอิงโครงการจากโครงการอื่น (เช่นการนำรหัสของโครงการกลับมาใช้ใหม่ "แนะนำความซับซ้อนในการพึ่งพาซึ่งกันและกัน") ได้ง่ายขึ้น:

• แทนที่จะเรียกดูทั้งระบบไฟล์ / แคชแอสเซมบลีส่วนกลางของคุณทั้งหมดสำหรับแอสเซมบลีที่อ้างอิงคุณสามารถเลือกโครงการจากชุดของโครงการที่เกี่ยวข้องในโซลูชันที่ จำกัด และ,
• เมื่ออ่านซอร์สโค้ดมันง่ายกว่ามากที่จะข้ามไปยังโปรเจ็กต์ที่อ้างอิงในการแก้ปัญหามากกว่าการประกอบ (ไบนารี) โดยพลการ

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