* เจ้าของรหัส * ระบบ: มันเป็นวิธีที่มีประสิทธิภาพหรือไม่ [ปิด]

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

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

คุณคิดว่าวิธีนี้ใช้ได้ผลดีกับระบบขนาดกลาง (การพัฒนาเว็บไซต์เครือข่ายสังคม) หรือไม่?

เช่นเดียวกับคำถามเหล่านี้ฉันคิดว่าคำตอบคือ:

มันขึ้นอยู่กับ

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

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

• โปรแกรมเมอร์ A: มีความเข้าใจอย่างลึกซึ้ง
• โปรแกรมเมอร์ B: ไม่มี

ช่วยให้โปรแกรมเมอร์ A ทำงาน 1 หน่วยต่อวัน ใน 4 สัปดาห์ของ 5 วันทำการเขา / เธอสามารถทำงานได้ 20 หน่วย

ดังนั้นโปรแกรมเมอร์ B เริ่มต้นที่ 0.2 หน่วยงานต่อวันและลงท้ายด้วย 0.96 หน่วยของงานในวันที่ 20 ของเขา (ในวันที่ 21 พวกเขาเก่งพอ ๆ กับโปรแกรมเมอร์ A) จะทำงาน 11.6 หน่วยในงานเดียวกัน ระยะเวลา 20 วัน ในช่วงเดือนนั้นโปรแกรมเมอร์ B มีประสิทธิภาพ 58% เมื่อเทียบกับโปรแกรมเมอร์ A อย่างไรก็ตามตอนนี้คุณมีโปรแกรมเมอร์คนอื่นที่รู้จักโมดูลนั้นและเป็นคนแรก

แน่นอนในโครงการขนาดเหมาะสมคุณอาจมี ... 50 โมดูล ดังนั้นการทำความคุ้นเคยกับพวกเขาทั้งหมดจะใช้เวลาประมาณ 4 ปีและนั่นหมายความว่าโดยเฉลี่ยโปรแกรมเมอร์การเรียนรู้ทำงานที่ประสิทธิภาพ 58% เมื่อเทียบกับโปรแกรมเมอร์ A ... hmmm

ลองพิจารณาสถานการณ์นี้: โปรแกรมเมอร์คนเดียวกันโครงการเดียวกัน (A รู้ทุกอย่างและ B ไม่รู้เลย) ให้บอกว่ามี 250 วันทำการในปี สมมติว่าเวิร์กโหลดมีการกระจายแบบสุ่มบนโมดูล 50 โมดูล ถ้าเราแยกโปรแกรมเมอร์ทั้งสองเท่า ๆ กัน A และ B ทั้งคู่จะได้รับ 5 วันทำการในแต่ละโมดูล A สามารถทำงานได้ 5 หน่วยในแต่ละโมดูล แต่ B จะได้รับตามการจำลอง Excel ของฉันเพียงเล็กน้อยเท่านั้น 1.4 งานที่ทำในแต่ละโมดูล รวม (A + B) คือ 6.4 หน่วยงานต่อโมดูล นั่นเป็นเพราะ B ใช้เวลาส่วนใหญ่ของพวกเขาโดยไม่มีทักษะใด ๆ กับโมดูลที่พวกเขากำลังทำงานอยู่

ในสถานการณ์นี้เป็นการดีที่สุดที่จะมุ่งเน้น B ไปที่เซตย่อยของโมดูลที่เล็กลง ถ้า B มุ่งเน้นไปที่เพียง 25 โมดูลพวกเขาจะได้รับ 10 วันในแต่ละคนรวม 3.8 หน่วยงานในแต่ละ โปรแกรมเมอร์ A สามารถใช้เวลา 7 วันต่อวันใน 25 โมดูลที่ B ไม่ทำงานและ 3 วันในการทำงานเดียวกันกับ B. ช่วงผลผลิตรวมอยู่ระหว่าง 6.8 ถึง 7 หน่วยต่อโมดูลเฉลี่ย 6.9 และสูงกว่าอย่างมาก มากกว่า 6.4 หน่วยต่อโมดูลที่เราทำเมื่อ A และ B กระจายการทำงานอย่างสม่ำเสมอ

ในขณะที่เรา จำกัด ขอบเขตของโมดูลที่ B ทำงานอยู่เราก็จะได้ประสิทธิภาพที่มากขึ้น (มากถึงหนึ่งจุด)

การอบรม

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

ทางออกที่ดีที่สุด

นั่นเป็นเหตุผลที่ฉันคิดว่าวิธีแก้ปัญหาที่ดีที่สุดต้องเป็นไปตามคำถามเช่น:

• ทีมของคุณใหญ่แค่ไหน? มันสมเหตุสมผลหรือไม่ที่จะให้ทุกคนได้รับการฝึกฝนในทุกส่วนหรือถ้าเรามีทีม 10 คนเราจะแน่ใจได้หรือไม่ว่าแต่ละโมดูลนั้นเป็นที่รู้จักกันอย่างน้อย 3 คน? (ด้วย 10 โปรแกรมเมอร์และ 50 โมดูลแต่ละโปรแกรมเมอร์จะต้องรู้ 15 โมดูลเพื่อให้ครอบคลุม 3x)
• การหมุนเวียนพนักงานของคุณเป็นอย่างไร หากคุณเปลี่ยนพนักงานโดยเฉลี่ยทุก ๆ 3 ปีและใช้เวลานานกว่านั้นในการรู้ทุกซอกทุกมุมของระบบพวกเขาจะไม่ได้อยู่ที่การฝึกอบรมเพื่อชำระคืน
• คุณต้องการผู้เชี่ยวชาญเพื่อวินิจฉัยปัญหาหรือไม่? ผู้คนจำนวนมากใช้ข้ออ้างว่า "จะเป็นอย่างไรถ้าคน ๆ นั้นไปพักผ่อน" แต่ฉันถูกเรียกมาหลายครั้งเพื่อวินิจฉัยปัญหาในระบบที่ฉันไม่เคยมีประสบการณ์มาก่อน อาจเป็นเรื่องจริงที่คนที่มีประสบการณ์สามารถค้นหาได้เร็วขึ้นมาก แต่ไม่ได้หมายความว่าคุณจะไม่สามารถอยู่ได้โดยปราศจากพวกเขาเป็นเวลาหนึ่งหรือสองสัปดาห์ ระบบซอฟต์แวร์ไม่กี่แห่งจึงมีภารกิจสำคัญที่จะต้องวินิจฉัยปัญหาใน 1 ชั่วโมงแทนที่จะเป็น 5 ชั่วโมงมิเช่นนั้นโลกจะสิ้นสุดลง คุณต้องชั่งน้ำหนักความเสี่ยงเหล่านี้

นั่นเป็นเหตุผลที่ฉันคิดว่า "มันขึ้นอยู่กับ" คุณไม่ต้องการแยก 20 โมดูลระหว่างโปรแกรมเมอร์สองตัวที่อยู่ตรงกลาง (10 หน่วย) เพราะคุณไม่มีความยืดหยุ่น แต่คุณไม่ต้องการที่จะฝึกอบรมโปรแกรมเมอร์ 10 ตัวในโมดูลทั้ง 50 เพราะคุณสูญเสียจำนวนมาก ประสิทธิภาพและคุณไม่ต้องการความซ้ำซ้อนมากนัก

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

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

ขึ้นอยู่กับโดเมนของปัญหา

หากเป็นสิ่งทั่วไป (เช่นการกระทำ CRUD อย่างง่าย ฯลฯ ) ฉันเห็นด้วยกับ Tom Squires (ทุกคนควรสามารถแก้ไขและแก้ไขได้)

อย่างไรก็ตาม ...

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

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

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

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

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

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

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

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

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

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

นั่นไม่ได้หมายความว่าในทีมนักพัฒนา 50 คนทุกคนควรรู้รหัสทั้งหมด แต่ทีม 5-7 ควรเป็นเจ้าของโมดูลที่ใหญ่พอที่จะทำให้คนเหล่านั้นทำงานได้ ไม่มีบุคคลใดควรเป็นเจ้าของอะไร

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

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

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

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

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

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

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

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

สาเหตุที่สิ่งนี้ไม่ดี:

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

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

วิธีที่ดีกว่าคือให้ทุกคนคุ้นเคยกับทุกส่วนของรหัสฐาน (หรือครึ่งโหลหรือมากกว่านั้นถ้ามันใหญ่และหลากหลาย) จนถึงจุดที่พวกเขาสามารถ

• แก้ไขข้อบกพร่องใด ๆ ในพื้นที่นั้น
• เพิ่มคุณสมบัติใหม่หรือปรับปรุงเล็กน้อยหรือปานกลาง

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

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

ดูหมายเลขรถบรรทุกหรือที่รู้จักในนามBus Factor

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

"การโดนรถบัส" อาจมีหลายรูปแบบ นี่อาจเป็นคนที่รับงานใหม่การมีลูกการเปลี่ยนวิถีชีวิตหรือสถานะชีวิตหรือการถูกรถบัสชนอย่างแท้จริง: เอฟเฟกต์จะเหมือนกัน ...

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

ข้อเสียคือรุนแรง "หมายเลขรถบรรทุก" ของทีมคุณกลายเป็น 1

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

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

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

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

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

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

โปรแกรมเมอร์ที่ดีขึ้นอาจสิ้นสุดการแก้ไขรหัสของคนอื่นไม่ว่าคุณจะกำหนดรหัสอย่างไร