วัฒนธรรมการรีวิวโค้ดและแนวปฏิบัติที่ดีของ PR

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

1) ทำให้เล็ก (ถ้าเป็นไปได้ควรมีไม่เกิน 400 บรรทัด) 2) เขียนคำอธิบายให้ชัดเจน: เหตุผล สิ่งที่เปลี่ยน และวิธีทดสอบ 3) เชื่อมโยงตั๋วงาน 4) เพิ่มภาพหน้าจอหรือวิดีโอสำหรับการเปลี่ยนแปลงส่วนติดต่อผู้ใช้ 5) ทบทวนส่วนต่างของตนเองก่อนขอให้ผู้อื่นทบทวน

ใช้คำนำหน้าตามแบบแผนเดียวกับคอมมิต: feat: add user profile page, fix: handle 404 in fetch wrapper, refactor: extract Avatar component หลายทีมสร้างบันทึกการเปลี่ยนแปลงจากข้อมูลเหล่านี้

ทีมส่วนใหญ่ใช้แม่แบบ PR — ติดตั้งไว้ที่ .github/pull_request_template.md

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

PR ที่มี 2,000 บรรทัดแทบไม่เคยได้รับการทบทวนอย่างละเอียด ควรแยกเป็น: 1) การปรับโครงสร้าง (ไม่เปลี่ยนพฤติกรรม) 2) พฤติกรรมใหม่ 3) การขัดเกลาส่วนติดต่อผู้ใช้ แต่ละส่วนจะทบทวนและย้อนกลับได้ง่ายกว่า

เขียนในรูปคำถาม ไม่ใช่คำสั่ง: ‘คุณคิดอย่างไรกับการแยกส่วนนี้เป็นฮุก’ ดีกว่า ‘แยกส่วนนี้’ แยกสิ่งที่ต้องแก้ไขออกจากสิ่งที่มีก็ดีไม่มีก็ได้ ใช้คำนำหน้า: nit:, question:, blocker:

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

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

Prettier จัดการการจัดรูปแบบ ส่วน ESLint จัดการรูปแบบการเขียน อย่าเสียรอบการทบทวนไปกับเรื่องแท็บกับช่องว่าง หากกฎรูปแบบใดถูกหยิบยกขึ้นมาซ้ำ ๆ ให้กำหนดกฎนั้นไว้ในเครื่องมือตรวจสอบรูปแบบ

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

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

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

ฟีเจอร์คำแนะนำของ GitHub ช่วยให้ผู้เขียนยอมรับการแก้ไขได้ด้วยการคลิกเพียงครั้งเดียว เร็วกว่าการเขียนเป็นข้อความว่า ‘เปลี่ยนบรรทัดนี้เป็น X’ มาก

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

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