วิธีการพัฒนาเมื่อนักพัฒนาซอฟต์แวร์หลายร้อยคนทำงานบนโซลูชันเดียว?

เราเป็นองค์กรที่ประกอบด้วยนักพัฒนาประมาณ 200 คนที่ทำงานอย่างต่อเนื่องในผลิตภัณฑ์เดียว (ใช้ Git revision control) ซึ่งมีการวางแผนที่จะวางจำหน่ายในวันที่กำหนด

เนื่องจากนักพัฒนาจำนวนมากเรากำลังพยายามสร้างทีม "ข้ามหน้าที่" ที่มีนักพัฒนาประมาณ 10 คนในแต่ละทีมส่งผลให้มีทีมพัฒนาประมาณ 20 ทีมในองค์กร

เนื่องจากเราต้องการรักษา "มาตรฐานสูง" อย่างต่อเนื่อง (หมายถึงเมื่อนักพัฒนาทำการดึงผลิตภัณฑ์อย่างน้อยควรจะสามารถคอมไพล์ได้ ฯลฯ ) ของผลิตภัณฑ์ในที่เก็บหลักเราจึงต้องการใช้ประตูคุณภาพบางประเภท

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

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

ปลายอีกด้านของสเปกตรัมอาจเป็นเช่นนั้น (เราคิดว่า Linus Torvalds / Linux ทำ) โครงสร้างต้นไม้หรือปิรามิดซึ่ง "คลังเก็บหลัก" มีแหล่งดึงสามแหล่งสามแห่งนี้มีแหล่งดึงที่เชื่อถือได้ ฯลฯ อย่างไรก็ตามเรารู้สึกว่าด้วยโครงสร้างเช่นการเปลี่ยนแปลงนั้นมีสายโซ่ยาวที่จะปีนขึ้นไปเพื่อเข้ามาใน "พื้นที่เก็บข้อมูลหลัก" นอกจากนี้หากเกิดข้อขัดแย้งในการผสานปัญหาจะเกิดกับผู้พัฒนารายอื่นมากกว่า "ผู้พัฒนาดั้งเดิม"

จากข้อมูลพื้นฐานและความคิดเห็นทั้งหมดที่ระบุไว้เราจะเรียนรู้และอ่านวิธีการพัฒนาที่แนะนำสำหรับนักพัฒนาจำนวนมากได้อย่างไร องค์กรขนาดใหญ่ (Microsoft, Facebook, Ubuntu และอื่น ๆ ) มีโครงสร้างการพัฒนาอย่างไร

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

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

เกี่ยวกับการตรวจสอบบิลด์คุณจะต้องใช้เซิร์ฟเวอร์การรวมต่อเนื่อง (CI)ซึ่งมีจุดประสงค์เพื่อสร้างและตรวจสอบรหัสโดยอัตโนมัติ โดยการตรวจสอบรหัสฉันหมายความว่ารหัสประสบความสำเร็จในการรวบรวมและการทดสอบผ่าน Infact Jenkins (CI Server) สามารถเชื่อมโยงกับระบบตรวจสอบรหัสGerritซึ่งเป็นส่วนหนึ่งของขั้นตอนการตรวจสอบGerritโดยอัตโนมัติกระบวนการทั้งหมด

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

มันอาจจะคุ้มค่าเมื่อพิจารณากระบวนการพัฒนาแบบ Agile เช่นScrumที่มีจุดประสงค์เพื่อแยกผลิตภัณฑ์ที่ซับซ้อนออกเป็นส่วนย่อยที่สามารถจัดการได้ของการเพิ่มผลิตภัณฑ์ (เรียกว่า Sprints) สิ่งเหล่านี้จะให้โอกาสการรวมระบบระหว่างที่เก็บข้อมูล

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

แม้แต่ทีมเล็กก็ต้องการผู้นำเพื่อเป็นแนวทางในทีมและทบทวนงานของพวกเขาในขณะที่พัฒนาแต่ละองค์ประกอบ พวกเขาควรจะเป็นกระบวนการควบคุมคุณภาพในระดับทีมเช่นกัน

ดังนั้นใช่คุณควรปฏิบัติตามโครงสร้างแบบลำดับชั้นเกี่ยวกับที่เก็บ นี่คือเพื่อให้ตรงกับโครงสร้างลำดับชั้นของโครงการโดยรวม

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

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

นอกจากนี้ยังเป็นสิ่งที่ดีที่ "หากเกิดข้อขัดแย้งในการผสานปัญหาจะเกิดขึ้นกับผู้พัฒนารายอื่น" โดยเฉพาะผู้พัฒนาระดับที่สูงขึ้นควรเป็นผู้ตัดสินใจว่าจะแก้ไขข้อขัดแย้งอย่างไร

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

มีหลายขั้นตอนที่จะช่วยให้คุณรักษาทีมและโครงการได้ดีขึ้น:

1. แบ่งการทำงานออกเป็นโมดูล ฟังก์ชั่นควรแบ่งออกเป็นโมดูลสูงสุดอิสระโดยใช้หลักการทำงานร่วมกันสูง, การมีเพศสัมพันธ์ต่ำและหลักการผกผันของการพึ่งพา หลักการแรกจะช่วยให้คุณสร้างโมดูลที่มีเหตุผลเชิงตรรกะ ส่วนที่สองจะช่วยให้โมดูลเหล่านี้เป็นอิสระที่สุด อันที่สามจะช่วยพัฒนาโมดูลที่ขึ้นต่อกันพร้อมกัน (ถ้าโมดูล A ขึ้นอยู่กับโมดูล B, B ควรจัดเตรียมอินเตอร์เฟสที่ A สามารถใช้แม้ในขณะที่ B ไม่พร้อมใช้งานอย่างสมบูรณ์)

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

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

4. ระบบที่ชัดเจนของงาน นักพัฒนาซอฟต์แวร์ 200 คนแต่ละคนควรรู้อย่างชัดเจนว่าควรทำอะไร สิ่งนี้จะช่วยให้คุณติดตามสิ่งที่ทำไปแล้วสิ่งที่แต่ละคนกำลังทำอยู่และจำนวนงานที่เหลืออยู่

5. การควบคุมแหล่งที่มา (ฉันคิดว่านี่เป็นคำตอบที่ระบุไว้ในคำตอบอื่น ๆ ได้ค่อนข้างดี)))

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

นอกเหนือจากคำตอบอื่น ๆ ที่แนะนำโครงสร้างแบบลำดับชั้น: นั่นหมายความว่าคุณจะต้องกำหนดเวลา 'การรวม' ในจุดที่จุดเน้นทั้งหมดในการย้ายรหัสขึ้นมาในลำดับชั้นและ 'รวมทั้งหมดเข้าด้วยกัน' สิ่งนี้ไม่แตกต่างจากโครงการขนาดเล็กที่มีเฟสสุดท้ายที่ไม่มีงานอื่นทำนอกเหนือจากการทดสอบและการแก้ไขข้อผิดพลาดบ่อยขึ้นเท่านั้น เนื่องจากคุณกำลังทำงานในกลุ่มใหญ่ที่พยายามสร้างมาตรฐานระดับสูงส่วนใหญ่ (กรอบความคิด) อาจจะเข้ามาแทนที่แล้ว

นอกเหนือจากคำตอบของ hotpotato (ซึ่งอยู่ที่เครื่องหมาย IMHO โดยตรง) ฉันขอแนะนำให้ติดตั้งเกตควบคุมแหล่งข้อมูลตามที่คุณแนะนำ เมื่อเราย้ายทีมขนาดใหญ่และฐานรหัสเป็น git สำหรับ SCM เราตัดสินใจใช้สิ่งที่เรียกว่า "เผด็จการใจดี" ซึ่งคล้ายกับแบบจำลองที่คุณอธิบาย

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

ฉันทำงานบนระบบที่ใหญ่โตซึ่งมีนักพัฒนาหลายร้อยคนทำงานพร้อมกันด้วย 150M SLOC นี่เป็นบนเมนเฟรมดังนั้นเราไม่ได้พูดถึง Visual Studio แต่ยังสามารถนำหลักการมาใช้ได้

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

เนื่องจากคุณไม่ได้ถามคำถามโดยตรง แต่ขอวิธีการฉันจะบอกคุณว่านายจ้างคนก่อนของฉันจัดการกับมันอย่างไร

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

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

ฉันหวังว่านี่จะช่วยได้.