ชุมชนนักพัฒนาซอฟต์แวร์กำลังอยู่ในการถกเถียงอย่างเข้มข้นเกี่ยวกับขนาดและโครงสร้างที่เหมาะสมของ pull requests ( PRs ) ซึ่งเกิดขึ้นจากคำแนะนำในการบรรยายในงานประชุมเมื่อเร็วๆ นี้ที่สนับสนุนให้มีการตรวจสอบโค้ดแบบขนาดเล็กและขับเคลื่อนด้วยเรื่องราว
 |
|---|
| วิทยากรที่กำลังมีส่วนร่วมกับผู้ฟังในงานประชุมเกี่ยวกับกลยุทธ์ pull request |
มาตรฐานการตรวจสอบ 5-10 นาที
การเคลื่อนไหวที่เติบโตขึ้นแนะนำว่า pull requests ควรสามารถตรวจสอบได้ในเวลาเพียง 5-10 นาที โดยการเปลี่ยนแปลงจำกัดอยู่ที่ประมาณ 300 บรรทัดของโค้ด ผู้สนับสนุนโต้แย้งว่าแนวทางนี้นำไปสู่การตรวจสอบที่มีคุณภาพสูงกว่าและรอบการพัฒนาที่เร็วกว่า พวกเขาเชื่อว่าเมื่อการเปลี่ยนแปลงมีขนาดเล็กและมีจุดเน้นชัดเจน ผู้ตรวจสอบสามารถให้ข้อเสนอแนะที่รอบคอบมากกว่าแทนที่จะประทับตราอนุมัติการส่งงานขนาดใหญ่และซับซ้อนด้วย Looks Good To Me ( LGTM ) อย่างง่ายๆ
อย่างไรก็ตาม นักพัฒนาที่มีประสบการณ์หลายคนต่อต้านแนวทางที่เข้มงวดนี้ พวกเขาโต้แย้งว่าการแบ่งฟีเจอร์ออกเป็นชิ้นเล็กๆ อย่างเทียมจริงแล้วอาจทำให้การตรวจสอบยากขึ้นโดยบดบังภาพรวมใหญ่และสร้างความซับซ้อนที่ไม่จำเป็นในการจัดการการเปลี่ยนแปลงหลายอย่างที่พึ่งพาซึ่งกันและกัน
แนวทางที่แนะนำสำหรับ PR:
- ขนาด: 300 บรรทัดของโค้ด (500+ บรรทัดถือว่าไม่สามารถตรวจสอบได้)
- เวลาในการตรวจสอบ: 5-10 นาทีสำหรับผู้ตรวจสอบทั่วไป
- โครงสร้างการ commit: 13 commits สำหรับการเปลี่ยนแปลงโค้ด 152 บรรทัด (กรณีตัวอย่าง)
- จุดเน้น: การเปลี่ยนแปลงที่ก่อให้เกิดความขัดแย้งได้ต่อ PR ไม่เกิน 1 รายการ
ความขัดแย้งเรื่อง Commit Story
ประเด็นที่ถกเถียงกันอีกประการหนึ่งเกี่ยวข้องกับการสร้าง commits ที่เล่าเรื่องราวที่สอดคล้องกันของวิธีการพัฒนาโค้ด ผู้สนับสนุนแนะนำว่าแต่ละ commit ควรแสดงถึงขั้นตอนเชิงตรรกะในกระบวนการพัฒนา ทำให้ผู้ตรวจสอบติดตามกระบวนการคิดของนักพัฒนาได้ง่ายขึ้น แนวทางนี้ถือว่า commits เป็นบทในหนังสือ แต่ละบทสร้างต่อจากบทก่อนหน้า
นักวิจารณ์พบว่าแนวปฏิบัตินี้ใช้เวลานานและตั้งคำถามถึงคุณค่าในโลกแห่งความเป็นจริง นักพัฒนาหลายคนรายงานว่าผู้ตรวจสอบไม่ค่อยอ่านข้อความ commit แต่ละรายการในระหว่างการตรวจสอบ PR ทำให้ความพยายามในการสร้าง commit stories ที่สมบูรณ์แบบรู้สึกเหมือนเป็นการเสียเวลา
ไม่มีใครอ่านข้อความ commit ระหว่างกลางทีละข้อความใน PR เลย ฉันทำงานในทีมที่หัวหน้าดื้อรั้นเรื่องนี้และเริ่มเขียนข้อความในแนว 'ถ้าคุณกำลังอ่านข้อความนี้ ฉันจะให้เงินคุณ 5 ดอลลาร์' ฉันไม่เคยจ่ายเงินใครเลยแม้แต่ดอลลาร์เดียว
เครื่องมือพัฒนาทางเลือก:
- Jujutsu (jj): ระบบควบคุมเวอร์ชันที่ออกแบบมาสำหรับ stacked branches
- Graphite: เครื่องมือสำหรับจัดการ stacked PRs บน Git
- Git-branchless: ส่วนขยายสำหรับการจัดการ branch ที่ดีขึ้น
- Sapling: ระบบควบคุมเวอร์ชันของ Meta ที่รองรับ stack
การตรวจสอบตนเองเป็นทางออก
พื้นที่หนึ่งที่นักพัฒนาดูเหมือนจะเห็นพ้องกันมากขึ้นคือแนวปฏิบัติการตรวจสอบ pull requests ด้วยตนเองก่อนส่ง หลายคนรายงานว่าการเพิ่มความคิดเห็นและคำอธิบายของตนเองใน PRs ช่วยปรับปรุงประสบการณ์การตรวจสอบสำหรับเพื่อนร่วมงานอย่างมีนัยสำคัญ แนวทางนี้ช่วยจับข้อผิดพลาดได้ตั้งแต่เนิ่นๆ และให้บริบทที่สำคัญซึ่งอาจไม่ชัดเจนจากโค้ดเพียงอย่างเดียว
การตรวจสอบตนเองยังช่วยแก้ไขความกังวลที่เพิ่มขึ้นเกี่ยวกับการส่งโค้ดที่สร้างด้วย AI ซึ่งนักพัฒนาอาจไม่เข้าใจการเปลี่ยนแปลงที่พวกเขาเสนออย่างเต็มที่ โดยการบังคับให้ผู้เขียนตรวจสอบงานของตนเองอย่างมีวิจารณญาณ ทีมสามารถรักษาคุณภาพโค้ดได้แม้ในขณะที่แนวปฏิบัติการพัฒนาเปลี่ยนแปลงไป
แนวทางปฏิบัติที่ดีสำหรับการตรวจสอบด้วยตนเอง:
- เพิ่มความคิดเห็นอธิบายก่อนขอให้ตรวจสอบ
- ใช้ระบบความคิดเห็นของ GitHub / GitLab เพื่อให้บริบท
- อธิบายการตัดสินใจเกี่ยวกับโค้ดที่ไม่ชัดเจนแบบ inline
- รวมหลักฐานการทดสอบและเหตุผลของแนวทาง
- จัดการกับคำถามที่อาจเกิดขึ้นจากผู้ตรวจสอบล่วงหน้า
ความท้าทายด้านเครื่องมือ
การถกเถียงเผยให้เห็นแรงเสียดทานที่สำคัญกับเครื่องมือพัฒนาปัจจุบัน โดยเฉพาะ Git และอินเทอร์เฟซของ GitHub สำหรับการตรวจสอบ commits แต่ละรายการ นักพัฒนาหลายคนที่ต้องการสร้างประวัติ commit ที่ดีกว่าพบว่าตนเองต่อสู้กับเครื่องมือที่ไม่ได้ออกแบบมาสำหรับเวิร์กโฟลว์นี้ ระบบควบคุมเวอร์ชันทางเลือกอย่าง Jujutsu และเครื่องมือเฉพาะทางอย่าง Graphite กำลังเกิดขึ้นเพื่อแก้ไขข้อจำกัดเหล่านี้
การอภิปรายเน้นย้ำความตึงเครียดพื้นฐานในการพัฒนาซอฟต์แวร์สมัยใหม่ระหว่างการเคลื่อนไหวอย่างรวดเร็วและการรักษาคุณภาพ แม้ว่าจะไม่มีทางออกสากล แต่ชุมชนดูเหมือนจะเห็นพ้องกันว่าสิ่งสำคัญอยู่ที่การปรับแนวปฏิบัติให้เหมาะสมกับความต้องการของทีมมากกว่าการปฏิบัติตามแนวทางใดแนวทางหนึ่งอย่างเข้มงวด ทีมที่ประสบความสำเร็จมากที่สุดดูเหมือนจะเป็นทีมที่ให้ความสำคัญกับการสื่อสารที่ชัดเจนและความเคารพซึ่งกันและกันมากกว่าการยึดมั่นอย่างเคร่งครัดต่อขีดจำกัดขนาด PR หรือรูปแบบข้อความ commit ที่เฉพาะเจาะจง