ตรวจทานโค้ดที่ AI สร้าง

อ่านข้อกำหนดก่อนอ่านสรุป

เริ่มจากพฤติกรรมที่ขอและเกณฑ์การยอมรับ แล้วตรวจดู diff จริง สรุปของ agent ช่วยชี้จุดที่ต้องดูได้ แต่อาจตกหล่นการเปลี่ยนแปลงหรืออธิบายการตรวจสอบไม่ถูกต้อง

ยืนยัน branch และ commit ที่กำลังตรวจทาน ตรวจหาการเปลี่ยน configuration, dependency, โครงสร้างพื้นฐาน และ test นอกเหนือจากโค้ดแอปพลิเคชัน ฟีเจอร์เล็กที่มองเห็นอาจรวมการเปลี่ยนสิทธิ์หรือพฤติกรรม deployment ครั้งใหญ่ไว้

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

ติดตามตัวตนไปถึงทรัพยากร

พิจารณา endpoint สมมติที่ยังไม่ครบนี้ ตัวอย่างแสดงปัญหาในการตรวจทาน ไม่ใช่โค้ดสำหรับ production

async function getInvoice(request) {
  const user = await requireSignedInUser(request);
  return database.invoice.findById(request.params.id);
}

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

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

อย่าสันนิษฐานว่าปุ่มที่ซ่อนปกป้อง API ได้ ผู้เรียกส่งคำขอโดยไม่ใช้หน้าจอได้ อย่าสันนิษฐานว่า ID ระเบียนที่ถูกต้องให้สิทธิ์เข้าถึง

ถามว่าหลักฐานใดอาจทำให้ปฏิเสธการเปลี่ยนแปลง

Test ที่ผ่านอาจใช้ fixture ผู้ดูแลระบบหรือ mock การตรวจสอบสิทธิ์ ตรวจว่าทดสอบขอบเขตที่สำคัญหรือไม่ เพิ่มกรณีจากองค์กรอื่นผ่านเส้นทางตรวจสอบสิทธิ์จริงตามความเหมาะสม

สำหรับการเปลี่ยนหน้าจอ ให้ตรวจดูผลที่ render แล้ว ตรวจการใช้ keyboard สถานะที่ไม่มีข้อมูล พฤติกรรมระหว่างโหลด และข้อผิดพลาด Type check พิสูจน์ไม่ได้ว่า dialog ใช้กับ keyboard ได้

สำหรับการเปลี่ยน dependency ให้ตรวจสอบว่าทำไมต้องเปลี่ยน ตรวจทานเวอร์ชัน license และข้อค้นพบด้านความปลอดภัย อย่ายอมรับการอัปเกรดที่ไม่เกี่ยวข้องเพียงเพราะ agent สร้างขึ้นระหว่างทำงาน

รักษาความเป็นอิสระของการตรวจทาน

โมเดลตัวที่สองอาจพบปัญหาที่มีประโยชน์ แต่ก็อาจใช้สมมติฐานเดียวกับการพัฒนา ให้ข้อกำหนดและ diff แก่ผู้ตรวจทาน หลีกเลี่ยงการบอกว่าการเปลี่ยนแปลงถูกต้องแล้ว

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

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

ปิดการตรวจทานที่ revision สุดท้าย

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

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

ใช้ แบบฝึกหัด code review เพื่อฝึกระบุการตัดสินใจที่ขาด ก่อนตรวจดูการเปลี่ยนแปลงจริง