รหัสตรวจสอบเวิร์กโฟลว์ที่ผู้เขียนคำขอดึงจะต้องผสาน

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

1. ผู้เขียนโค้ดส่งคำขอการดึง
2. ผู้ตรวจสอบตรวจสอบรหัส
3. • หากผู้ตรวจสอบอนุมัติพวกเขาจะแสดงความคิดเห็นตามบรรทัดของ "ดูดีรู้สึกอิสระที่จะผสาน"
   • หากผู้ตรวจสอบมีข้อกังวลพวกเขาแสดงความคิดเห็นเช่น "โปรดแก้ไขปัญหาเล็กน้อย X และ Y จากนั้นรวม" (สำหรับการเปลี่ยนแปลงที่สำคัญกลับไปที่ขั้นตอนที่ 2)
4. ผู้สร้างรหัสทำการเปลี่ยนแปลงหากจำเป็นจากนั้นรวมคำขอดึงของเขาหรือเธอเอง

ฉันมีข้อกังวลดังต่อไปนี้:

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

• ในกรณีที่มีการร้องขอการเปลี่ยนแปลงในขั้นตอนที่ 3 หน่วยงานที่จะรวมคำขอดึงข้อมูลจะอยู่กับผู้แต่งของ PR เท่านั้น ไม่มีใครนอกจากผู้เขียนจะดูการเปลี่ยนแปลงก่อนที่จะรวม

อะไรคือข้อดีหรือข้อเสียของเวิร์กโฟลว์นี้ เวิร์กโฟลว์นี้เป็นเรื่องปกติในทีมวิศวกรรมอื่น ๆ หรือไม่

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

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

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

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

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

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

ในองค์กรของฉันเราค่อนข้างใหม่ในคำขอดึงและคำถามของคุณคือคำถามที่ฉันได้ไตร่ตรองตัวเอง

ข้อสังเกตหนึ่งที่ฉันต้องการเพิ่ม: ในเครื่องมือบางอย่าง (เราใช้ TFS) อาจมีไอเท็มงานที่เกี่ยวข้องกับคำขอดึง

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

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

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