การตรวจสอบโค้ด — คืออะไร, การตรวจสอบโค้ดและการตรวจสอบ PR ทำงานอย่างไร

การตรวจสอบโค้ดคืออะไร

การตรวจสอบโค้ด คือการตรวจสอบโค้ดอย่างเป็นระบบโดยเพื่อนร่วมงานก่อนการรวม ในบริบทของ Git หมายความว่า: นักพัฒนาสร้าง pull request พร้อมการเปลี่ยนแปลง กำหนดผู้ตรวจสอบ และพวกเขาศึกษา diff แสดงความคิดเห็น และตัดสิน ผู้ตรวจสอบสามารถขอให้เปลี่ยนแปลง อนุมัติ PR หรือแสดงความคิดเห็นทั่วไป

การตรวจสอบโค้ดมี ห้าเป้าหมาย: การปรับปรุงคุณภาพโค้ด (ค้นหาข้อบกพร่องก่อนถึงโปรดักชัน) การเผยแพร่ความรู้ (ผู้ตรวจสอบเรียนรู้แนวทางใหม่ ผู้ได้รับ feedback) การปฏิบัติตามมาตรฐาน (ตรวจสอบความสอดคล้องกับรูปแบบโค้ดและการตัดสินใจทางสถาปัตยกรรม) การลด bus factor (นักพัฒนามากกว่าหนึ่งคนรู้จักโค้ด) และการสร้างวัฒนธรรมความรับผิดชอบ (ผู้เขียนเขียนอย่างระมัดระวังมากขึ้นเมื่อรู้ว่าโค้ดจะถูกตรวจสอบ)

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

สิ่งที่ต้องตรวจสอบในการตรวจสอบโค้ด

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

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

การทดสอบ: การทดสอบใหม่ครอบคลุมทุกสถานการณ์หรือไม่ — เชิงบวก เชิงลบ กรณีขอบ การทดสอบที่มีอยู่ผ่านหลังการเปลี่ยนแปลงหรือไม่ มีการทดสอบที่ไม่เสถียรซึ่งล้มเหลวอย่างไม่สม่ำเสมอหรือไม่ ความปลอดภัย: ไม่มี SQL injection, XSS, การรั่วไหลของข้อมูลที่ละเอียดอ่อนผ่าน log หรือการตอบสนองของ API ประสิทธิภาพ: ประสิทธิภาพของอัลกอริทึม คำสั่งฐานข้อมูลที่มากเกินไป การรั่วไหลของทรัพยากร

• สถาปัตยกรรม — ความถูกต้องของโซลูชัน การปฏิบัติตาม SOLID ไม่มีการออกแบบเกินความจำเป็น
• ตรรกะ — การจัดการทุกสถานการณ์ รวมถึงข้อผิดพลาดและกรณีขอบ
• การทดสอบ — ความครอบคลุมของการเปลี่ยนแปลงใหม่ ไม่มีการทดสอบเดิมที่เสีย
• ความปลอดภัย — injection, XSS, CSRF, การรั่วไหลของข้อมูลผ่าน log
• ประสิทธิภาพ — ความซับซ้อนของอัลกอริทึม คำสั่ง N+1 การรั่วไหลของหน่วยความจำ

ขนาดการตรวจสอบ: ทำไม 400 บรรทัดจึงเป็นสูงสุด

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

ขนาดที่เหมาะสม: 200–400 บรรทัด ต่อ PR ปริมาณนี้สามารถตรวจสอบได้ใน 30–60 นาทีโดยยังคงสมาธิ Google แนะนำไม่เกิน 200 บรรทัดต่อรอบการตรวจสอบด้วยสมาธิเต็มที่ ถ้าการเปลี่ยนแปลงมีขนาดใหญ่ขึ้น งานควรถูกแบ่งออกเป็น PR ตามลำดับหลายรายการ แต่ละรายการนำเสนอการเปลี่ยนแปลงที่สมบูรณ์ตามตรรกะ

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

วิธีการเขียนความคิดเห็นการตรวจสอบที่ดี

น้ำเสียงของความคิดเห็น มีความสำคัญอย่างยิ่งต่อประสิทธิผลของการตรวจสอบโค้ด ความคิดเห็นเช่น “สิ่งนี้ผิด” ทำให้เกิดปฏิกิริยาตอบโต้และไม่ได้ให้ข้อมูลที่เป็นประโยชน์แก่ผู้เขียน รูปแบบที่ดีกว่าคือคำถาม-ข้อเสนอแนะ: “คุณคิดอย่างไรกับแนวทางนี้?”, “สิ่งนี้อาจทำให้เกิด NPE ถ้า user == nil อาจเพิ่ม guard?” คำถามมีความขัดแย้งน้อยกว่าและกระตุ้นการอภิปราย

ความคิดเห็นที่ดีประกอบด้วย สามส่วน: อะไรผิด ทำไมจึงเป็นปัญหา และวิธีแก้ไข ตัวอย่าง: “ลูปนี้ใช้ O(n²) เนื่องจาก contains ที่ซ้อนกัน ซึ่งอาจช้าด้วย 10k+ เรกคอร์ด ลองแทนที่ด้วย Set สำหรับการค้นหา O(1)” รูปแบบนี้ระบุปัญหา อธิบายความสำคัญ และเสนอวิธีแก้ไขพร้อมกัน — ผู้เขียนไม่ต้องเดา

GitHub และ GitLab รองรับ ข้อเสนอแนะ — ข้อเสนอการเปลี่ยนแปลงโค้ดแบบอินไลน์ ผู้ตรวจสอบสามารถเขียน: “```suggestion Filter empty strings before processing```” และผู้เขียนสามารถใช้การเปลี่ยนแปลงด้วยคลิกเดียว สิ่งนี้ช่วยเร่งการแก้ไขเล็กน้อยและลดจำนวนรอบการตรวจสอบ สำหรับการเปลี่ยนแปลงใหญ่ ควรเขียนความคิดเห็นทั่วไปแทนที่จะฝังบล็อกขนาดใหญ่ในข้อเสนอแนะ

# เทมเพลตสำหรับความคิดเห็นการตรวจสอบโค้ดที่ดี

# ไม่ดี: "This code is wrong"
# ดี: "We may lose data on empty response.
#         If response.data == nil, the guard returns nil,
#         and user sees empty screen without error.
#         Maybe add a fallback error message?"

# ไวยากรณ์ข้อเสนอแนะ GitHub:
# ```suggestion
# let result = try? parse(response, fallback: .defaultValue)
# ```

ขั้นตอนการตรวจสอบโค้ดในทีม

ขั้นตอนการตรวจสอบที่มีประสิทธิภาพสร้างขึ้นจาก สี่ขั้นตอน ขั้นแรก — ผู้เขียนเตรียม PR: เขียนชื่อเรื่องที่ชัดเจน (เช่น “feat: add password reset screen”) เพิ่มคำอธิบายการเปลี่ยนแปลง ลิงก์ไปยังงานในตัวติดตาม และคำแนะนำการทดสอบ ขั้นที่สอง — ผู้เขียนกำหนดผู้ตรวจสอบผ่านการกำหนดอัตโนมัติ (ตาม CODEOWNERS) หรือด้วยตนเอง

ขั้นตอนที่สาม — ผู้ตรวจสอบตรวจสอบโค้ด และแสดงความคิดเห็น ขั้นที่สี่ — ผู้เขียนแก้ไข ตอบกลับความคิดเห็น และขอตรวจสอบซ้ำ วงจรจะทำซ้ำจนกว่าจะได้รับการอนุมัติ หลังการอนุมัติ ผู้เขียนดำเนินการรวม (หรือบอทดำเนินการ) ระบบอัตโนมัติผ่าน Mergify หรือ GitHub Auto-merge ช่วยเร่งขั้นตอนสุดท้าย

องค์ประกอบสำคัญของขั้นตอนคือ การจัดการ PR ที่ค้างอยู่ ถ้า PR ค้างไว้โดยไม่มีการตรวจสอบนานกว่า 3 วัน กระบวนการจะถูกบล็อก วิธีแก้ไข: การหมุนเวียนผู้ตรวจสอบ (ถ้าผู้ตรวจสอบที่กำหนดไม่ว่าง) การแจ้งเตือนผ่าน Slack/Teams การจำกัดเวลาตรวจสอบ (SLA) ในบางทีม PR ที่ไม่มีการตรวจสอบนานกว่า 7 วันจะถูกปิดโดยอัตโนมัติ และผู้เขียนสร้างใหม่หลังจากซิงค์กับ main

• การสร้าง PR — ชื่อเรื่องที่ชัดเจน คำอธิบาย ลิงก์งาน ภาพหน้าจอสำหรับการเปลี่ยนแปลง UI
• การกำหนด — การกำหนดอัตโนมัติผ่าน CODEOWNERS หรือการเลือกด้วยตนเอง 1–2 ผู้ตรวจสอบ
• การตรวจสอบ — ตรวจสอบตามลำดับ: สถาปัตยกรรม → ตรรกะ → การทดสอบ → ความปลอดภัย → รูปแบบ
• การแก้ไข — ผู้เขียนตอบกลับความคิดเห็นทั้งหมด แก้ไขปัญหาที่บล็อก ขอตรวจสอบซ้ำ
• การรวม — หลังการอนุมัติและ CI สีเขียว ผู้เขียนหรือบอดำเนินการรวม

ข้อผิดพลาดทั่วไปในการตรวจสอบโค้ด

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

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

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

• การตรวจสอบผิวเผิน — อนุมัติโดยไม่วิเคราะห์ลึก วิธีแก้ไข: อย่าตรวจสอบถ้าไม่มีเวลา
• Nitpicking — การวิจารณ์รูปแบบที่ linter ควรตรวจสอบ วิธีแก้ไข: ทำให้การตรวจสอบรูปแบบเป็นอัตโนมัติ
• ความชอบส่วนตัว — “ฉันจะเขียนต่างออกไป” วิธีแก้ไข: โค้ดควรทำงาน ไม่ใช่ทำให้ผู้ตรวจสอบพอใจ
• ความล่าช้า — การตรวจสอบนานกว่า 24 ชั่วโมง วิธีแก้ไข: SLA ในการตรวจสอบ การยกระดับเมื่อถูกละเมิด
• การละเลยบริบท — การตรวจสอบโค้ดโดยไม่เข้าใจงาน วิธีแก้ไข: อ่านคำอธิบาย PR ก่อน diff