โปรแกรมเมอร์ที่ดีที่สุดของคุณควรตรวจสอบรหัสของคนอื่นในการควบคุมซอร์สหรือไม่?

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

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

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

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

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

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

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

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

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

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

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

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

ไม่ทุกคนควรจะสามารถกระทำได้

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

อีกสิ่งที่ยอดเยี่ยมเรียกว่าการทดสอบหน่วย;)

มีทางเลือกว่า

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

b) ในการโค่นล้มและสิ่งที่คล้ายกันคุณสามารถใช้กิ่งไม้ที่แต่ละ dev ต้องสร้างแพตช์เพื่อนำมันเข้าไปในสาขาหลัก

คุณควรดูโครงการต่าง ๆ เช่นGerritซึ่งช่วยให้นักพัฒนาซอฟต์แวร์ทุกคนใส่รหัสลงใน 'ตรวจสอบ' สาขาและเมื่อคุณอาวุโส / ผู้นำการพัฒนามีความสุขกับการเปลี่ยนแปลงเหล่านี้

หากพวกเขาไม่พอใจพวกเขาสามารถแสดงความคิดเห็นถัดจากบรรทัดของรหัสขอแพทช์ปรับปรุง ฯลฯ

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

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

ควรมีบทวิจารณ์โค้ด แต่นั่นไม่ได้หมายความว่าเป็น Sr. ที่ตรวจสอบรหัสของ jr เสมอ ในที่สุดทุกคนในทีมควรได้รับการคาดหวังให้อยู่ในระดับที่พวกเขาสามารถมีส่วนร่วมในรหัสโดยมีแนวทางน้อย พวกเขาผ่านสามระดับความเชื่อมั่น:

1. ไม่มี - ฉันต้องการเห็นโค้ดทุกบรรทัดก่อนที่คุณจะเช็คอิน
2. บ้าง - ให้ฉันรู้ว่าคุณกำลังทำอะไรและฉันจะให้ข้อเสนอแนะ
3. มากที่สุด - ไปทำงานของคุณและขอความช่วยเหลือเมื่อจำเป็นเท่านั้น

ข้อดีของการเพิ่มความสามารถของคุณ:

• มุ่งเน้นการออกแบบ
• การมีส่วนร่วมในการกำหนดมาตรฐานการเข้ารหัสและกลยุทธ์การบังคับใช้ (โดยไม่ต้องทำเองทั้งหมด)
• แก้ไขปัญหาการเข้ารหัสที่ยากลำบาก
• ให้คำปรึกษา (โดยไม่ต้องอนุมัติรหัสทุกบรรทัด)

มีผู้พัฒนาที่สนใจเส้นทางการจัดการที่อาจไม่ต้องการใช้รหัสตลอดทั้งวัน ปล่อยให้คนอื่นอยู่คนเดียว

การทบทวนคุ้มค่ากับประสิทธิภาพการทำงานหรือไม่

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

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

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

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

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

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

หากการเปลี่ยนแปลงรหัสถูกบล็อคเป็นเวลาหลายวัน ... สัปดาห์จากการไปที่ QA เพื่อทดสอบ "เนื่องจากรีวิว" การเรียนรู้เกี่ยวกับเทคนิค VCS จะเป็นวิธีที่มีโอกาสน้อยที่สุดในการแก้ปัญหานี้ แทนที่จะมุ่งเน้นความพยายามของพวกเขาในการค้นหาปัญหาในวิธีการจัดระเบียบกระบวนการตรวจสอบ

• <sup>- โอ้การรวมตัวกันของการเปลี่ยนแปลงนี้ล่าช้ามากเพราะผู้ตรวจทานป่วยกะทันหันสิ่งที่โชคร้าย
  - สวัสดี! คุณเคยคิดว่าจะมีผู้ตรวจสอบสำรองเพื่อจัดการกับกรณีเช่นนี้หรือไม่?</sup>

ใช่. แต่ถ้าคุณกำลังพูดถึงการควบคุมแหล่งที่มาแบบกระจาย ด้วยการรวมศูนย์ - มันขึ้นอยู่กับ

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

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

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

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

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

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

ตราบใดที่การเปลี่ยนแปลงที่ส่งถูกตรวจสอบโดย 'โปรแกรมเมอร์ที่ดีที่สุด' ทุกคนควรได้รับอนุญาตให้ส่งรหัส บุคคลเดียวที่ควรมีความสามารถในการบังคับใช้การควบคุมในที่เก็บข้อมูลคือ Release Engineer หากบุคคลนั้นมีอยู่

ส่วนตัวฉันจะโกรธถ้าฉันต้องตรวจสอบในรหัสของคนอื่น

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

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

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

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

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

การรวมเข้ากับสาขาที่วางจำหน่ายสามารถทำได้โดยโปรแกรมเมอร์ "ดีที่สุด" หรือมีโอกาสมากขึ้นโดยคนที่มีความสามารถหลังจากมีการตรวจสอบอย่างเพียงพอแล้ว

โปรแกรมเมอร์ที่ดีจะออกจากถ้าส่วนสำคัญของงานของพวกเขาคือการทบทวนรหัสของคนอื่น?

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

โปรแกรมเมอร์ที่ดีที่สุดของคุณควรตรวจสอบรหัสของคนอื่นในการควบคุมซอร์สหรือไม่?

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

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