วิธีการบังคับใช้วิธีปฏิบัติในการควบคุมซอร์สโค้ดที่ดี / ดีกว่า

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

สถานการณ์ปัจจุบัน: ใน
ปัจจุบันเพื่อนร่วมงานของฉันยอมรับการเปลี่ยนแปลงรหัสของพวกเขาหลังจากช่วงเวลา loooong เป็นระยะเวลานานโดยมีการเปลี่ยนแปลงกระจายไปทั่วทั้งโครงการ นั่นเป็นความคืบหน้าฉันเดาเพราะไม่นานมานี้พวกเขาเพิ่งวางไฟล์. zip ไว้ในเครือข่าย ยังคงการรวมกันเป็นฝันร้าย - และตรงไปตรงมาที่ฉันมีเพียงพอ และฉันก็เบื่อที่จะพูดคุยและอธิบายและขอร้องด้วย สิ่งนี้ต้องหยุด - ถ้าไม่มีฉันก็จะเป็น "คนเลว" ตลอดเวลา

ทางออกของฉัน:
เนื่องจากดูเหมือนว่าจะไม่รับรู้และ / หรือไม่มีความสนใจในปัญหาและฉันไม่สามารถคาดหวังความพยายามใด ๆ ที่จะใช้เวลานานกว่าสองสามวัน ... หยุดงานชั่วคราว, ชั่วโมง, ฉันต้องการเซิร์ฟเวอร์โค่นล้ม ซึ่งจู้จี้

คำถามของฉัน:
ฉันไปทางฐานที่นี่หรือฉันกำลังดูปัญหาที่ผิด? ดูเหมือนว่าฉันขาดอะไรบางอย่างไปและฉันคิดว่าฉันกำลังถามสิ่งที่ผิดโดยดูที่เครื่องมือในการแก้ปัญหาของฉัน

ฉันควรจะมองหาเครื่องมือในการแก้ปัญหานี้หรือฉันควรทำอย่างไรเพื่อแก้ไขปัญหานี้

คุณกำลังมองหาวิธีการแก้ปัญหาด้านเทคนิคสำหรับปัญหามนุษย์ ที่ไม่ค่อยได้ผล

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

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

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

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

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

   บางคนไม่ทราบว่ามีทีมงาน 5-10 คนที่ทำหน้าที่ผลักดันการผลิตมากถึง 50 คนซึ่งแปลเป็นค่าเฉลี่ย 5-10 คอมมิตต่อวันต่อคน พวกเขาอาจไม่เข้าใจว่ามันเป็นไปได้อย่างไรและทำไมไม่มีใครทำ

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

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

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

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

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

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

   • “My ครู / ผู้ให้คำปรึกษาบอกว่าวิธีที่ดีที่สุดคือการทำอย่างใดอย่างหนึ่งกระทำต่อวัน.” มันไม่แปลกใจเลยที่ได้รับในสิ่งที่ผมต้องได้ยินจากครูของฉันในวิทยาลัย

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

   • “ ฉันคิดว่าคำมั่นสัญญาเล็ก ๆ นั้นยากที่จะหาการแก้ไข” จุดที่ใช้ได้แม้ในขณะที่ทีมพยายามเขียนข้อความบันทึกเชิงพรรณนา

   • “ ฉันไม่ต้องการที่จะเสียพื้นที่มากเกินไปในเซิร์ฟเวอร์ควบคุมเวอร์ชันของเรา” คน ๆ นั้นไม่เข้าใจวิธีการจัดเก็บค่าคอมมิชชัน (หรือพื้นที่เก็บข้อมูลราคาถูก)

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

7. ค้นหาสาเหตุที่ทีมไม่ได้ทำผิดบ่อยขึ้น คุณอาจประหลาดใจกับผลลัพธ์ที่ได้

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

   เหตุผลอื่น ๆ อาจรวมถึง:

   • กฎที่ซับซ้อนมากเกินไปในการเขียนข้อความยืนยัน

   • กฎที่บังคับให้นักพัฒนาเชื่อมโยงการกระทำไปยังงานจากระบบติดตามบั๊ก

   • ความกลัวที่จะทำลายการสร้าง

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

   • ความกลัวในการผสาน

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

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

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

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

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