Code Review โค้ดที่ AI เขียน: เช็กลิสต์ 15 ข้อ

เมื่อ AI เขียนโค้ดได้เร็วขึ้นหลายเท่า คอขวดของทีมจะย้ายไปอยู่ที่การ review ถ้าเรา review แบบเดิม คือกวาดตาดูว่าโค้ดอ่านง่ายไหม ก็มีโอกาสสูงที่จะปล่อยบั๊กและช่องโหว่ผ่านไป เพราะโค้ดจาก AI มักดู "เรียบร้อย" มาก ชื่อตัวแปรดี มี comment ครบ แต่ซ่อนปัญหาไว้ในจุดที่ต้องตั้งใจดูถึงจะเห็น บทความนี้ให้เช็กลิสต์ 15 ข้อสำหรับ review โค้ดที่ AI เขียน แบ่งเป็นหมวด ความถูกต้อง ความปลอดภัย คุณภาพ และการดูแลระยะยาว พร้อมตัวอย่างใน PHP/Yii2 ที่เห็นบ่อย

โค้ดจาก AI ต่างจากโค้ดที่คนเขียนอย่างไรในมุม review

โค้ดที่คนเขียนมักมีร่องรอยของความไม่แน่ใจ เช่น comment ว่า TODO หรือโค้ดที่ดูรีบ ทำให้ reviewer รู้ว่าควรระวังตรงไหน แต่โค้ดจาก AI สม่ำเสมอเท่ากันทั้งไฟล์ ส่วนที่ถูกและส่วนที่ผิดดูมั่นใจเท่ากัน ลักษณะที่พบบ่อยคือ

• ทำงานได้กับ happy path แต่ลืมกรณีข้อมูลว่างหรือผิดรูปแบบ
• เรียก method หรือ option ที่ไม่มีจริงในเวอร์ชันที่เราใช้
• แก้เกินขอบเขต หรือทิ้งโค้ดที่ไม่ได้ใช้ไว้
• จัดการ error แบบกว้างเกินไป เช่น catch ทุกอย่างแล้วเงียบ
• เพิ่ม dependency โดยไม่จำเป็น

ดังนั้นก่อนเริ่มอ่าน ให้ดู git diff --stat ก่อนเสมอว่ามีไฟล์อะไรเปลี่ยนบ้าง ถ้าเห็น composer.json, ไฟล์ config หรือไฟล์ที่ไม่เกี่ยวกับงาน ให้ตั้งคำถามทันที

หมวดที่ 1: ความถูกต้อง (ข้อ 1–4)

1. ทำตาม requirement ครบ และไม่เกิน

เทียบกับ ticket หรือ prompt ทีละข้อ AI อาจทำครบ 4 จาก 5 ข้อ หรือทำเกินโดยเพิ่ม feature ที่ไม่ได้ขอ ซึ่งเป็นภาระดูแลในอนาคต

2. Edge case

ถามตัวเองว่า ถ้า input เป็นค่าว่าง, null, 0, ติดลบ, array ว่าง, string ยาวมาก, ภาษาไทยหรือ emoji หรือ record ไม่มีอยู่ จะเกิดอะไร ตัวอย่างที่พบบ่อยใน Yii2

// AI มักเขียนแบบนี้ ถ้า id ไม่มีอยู่จะได้ error เรียก method บน null
$order = Order::findOne($id);
$order->status = Order::STATUS_PAID;

// ควรเป็น
$order = Order::findOne($id);
if ($order === null) {
    throw new \yii\web\NotFoundHttpException('ไม่พบคำสั่งซื้อ');
}

3. มีเทสต์ที่พิสูจน์ได้

มีเทสต์สำหรับพฤติกรรมใหม่หรือไม่ เทสต์ทดสอบค่าจริงหรือแค่ไม่ error ไฟล์เทสต์เดิมถูกแก้หรือไม่ ถ้าถูกแก้ ต้องมีเหตุผลที่ชัดเจน

4. API และฟังก์ชันที่เรียกมีอยู่จริง

ตรวจ method ที่ไม่คุ้นเคยกับเอกสารของ framework หรือใช้ IDE กระโดดไปดู definition AI อาจผสม API ของ Yii2 กับ framework อื่น หรือใช้ฟังก์ชัน PHP ที่มีในเวอร์ชันใหม่กว่าที่ server รัน

หมวดที่ 2: ความปลอดภัย (ข้อ 5–8)

5. Input ทุกตัวผ่านการ validate และ query ใช้ parameter binding

// อันตราย: ต่อ string เป็น SQL
$rows = Yii::$app->db->createCommand(
    "SELECT * FROM product WHERE name LIKE '%{$q}%'"
)->queryAll();

// ปลอดภัย: ให้ query builder จัดการ escape และ binding
$rows = (new \yii\db\Query())
    ->from('product')
    ->where(['ilike', 'name', $q])
    ->limit(50)
    ->all();

6. Output ถูก encode

ใน view ทุกค่าที่มาจากผู้ใช้ต้องผ่าน Html::encode() ระวังเป็นพิเศษเมื่อเห็น <?= $model->title ?> ตรง ๆ หรือการ render HTML ที่ผู้ใช้กรอก ซึ่งต้องผ่าน HtmlPurifier::process()

7. ตรวจสิทธิ์ครบทุก action

action ใหม่อยู่ใน AccessControl หรือไม่ และตรวจความเป็นเจ้าของ record หรือไม่ เช่น ผู้ใช้ A เปิด order ของผู้ใช้ B ได้ไหมเมื่อเปลี่ยน id ใน URL

8. ไม่มี secret ในโค้ด และไม่ log ข้อมูลส่วนตัว

ค้นหา string ที่หน้าตาเหมือน key, password หรือ token ในโค้ดใหม่ และตรวจทุกบรรทัดที่ log ว่าไม่บันทึกรหัสผ่าน เลขบัตรประชาชน เบอร์โทร หรือข้อมูลบัตร AI ชอบใส่ log แบบ Yii::info($request->post()) เพื่อช่วย debug ซึ่งเท่ากับบันทึกทุกอย่างที่ผู้ใช้กรอกลงไฟล์

// ไม่ควร: log ทั้ง payload
Yii::info(Yii::$app->request->post(), 'register');

// ควร: log เฉพาะสิ่งที่จำเป็นสำหรับติดตามปัญหา
Yii::info(['event' => 'register', 'userId' => $user->id], 'register');

หมวดที่ 3: คุณภาพและประสิทธิภาพ (ข้อ 9–12)

9. Performance: N+1 query และการโหลดข้อมูลทั้งตาราง

// N+1: query customer ทุกรอบของ loop
foreach (Order::find()->all() as $order) {
    echo Html::encode($order->customer->name);
}

// ดีกว่า: eager loading และแบ่งเป็น batch
foreach (Order::find()->with('customer')->each(200) as $order) {
    echo Html::encode($order->customer->name);
}

มองหา ->all() บนตารางที่อาจโตเป็นหลักแสนแถว query ใน loop และการเรียก API ภายนอกใน loop

10. Error handling ที่เหมาะสม

ระวัง catch (\Throwable $e) {} ที่กลืน error เงียบ ๆ หรือ catch แล้วคืนค่า default ที่ทำให้ข้อมูลผิดโดยไม่มีใครรู้ ควร catch เฉพาะ exception ที่จัดการได้จริง log อย่างเหมาะสม และไม่แสดงรายละเอียด error ภายในให้ผู้ใช้เห็น

11. Transaction เมื่อแก้หลายตาราง

ถ้าโค้ดบันทึก order และตัด stock พร้อมกัน ต้องอยู่ใน transaction เดียว AI มักเขียน save ต่อกันหลายครั้งโดยไม่มี transaction ถ้าตัวกลางล้มเหลว ข้อมูลจะไม่สอดคล้องกัน

12. ชื่อสื่อความหมายและสอดคล้องกับโปรเจกต์

AI ตั้งชื่อดีในภาพรวม แต่มักไม่ตรงกับ convention ของทีม เช่น ทีมใช้ OrderService แต่ AI สร้าง OrderManager หรือใช้คำศัพท์ทางธุรกิจคนละคำกับที่ทีมใช้ ความไม่สอดคล้องแบบนี้ทำให้โค้ดเบสอ่านยากขึ้นเรื่อย ๆ

หมวดที่ 4: การดูแลระยะยาว (ข้อ 13–15)

13. ไม่มี dead code

method ที่สร้างแล้วไม่ถูกเรียก, import ที่ไม่ใช้, โค้ดที่ comment ทิ้งไว้, ตัวแปรที่ไม่ได้ใช้ สิ่งเหล่านี้มักเหลือจากการวนแก้หลายรอบกับ AI ใช้ static analysis ช่วยจับได้ส่วนหนึ่ง

14. Dependency ใหม่จำเป็นจริงและตรวจแล้ว

ถ้ามีแพ็กเกจใหม่ใน composer.json หรือ package.json ให้ถามว่าเขียนเองไม่กี่บรรทัดได้ไหม แพ็กเกจมีอยู่จริงและมีผู้ดูแลหรือไม่ ไลเซนส์ใช้ได้ไหม และรัน composer audit หรือ npm audit

15. ผู้เปิด PR อธิบายโค้ดได้

ข้อสุดท้ายเป็นเรื่องของคน ผู้เปิด PR ต้องตอบได้ว่าทำไมเลือกวิธีนี้ และแต่ละส่วนทำอะไร ถ้าคำตอบคือ "AI เขียนมาแบบนี้" แปลว่ายังไม่พร้อม merge

เช็กลิสต์ฉบับย่อสำหรับแปะใน PR template

## AI-assisted code review
- [ ] 1. ครบตาม requirement ไม่เกินขอบเขต
- [ ] 2. จัดการ edge case: null, ว่าง, 0, ติดลบ, ไม่พบ record
- [ ] 3. มีเทสต์ที่ทดสอบค่าจริง ไฟล์เทสต์เดิมไม่ถูกแก้โดยไม่มีเหตุผล
- [ ] 4. method/ฟังก์ชันที่เรียกมีอยู่จริงในเวอร์ชันที่ใช้
- [ ] 5. validate input และใช้ parameter binding/query builder
- [ ] 6. output ผ่าน Html::encode หรือ HtmlPurifier
- [ ] 7. AccessControl และตรวจความเป็นเจ้าของ record
- [ ] 8. ไม่มี secret ในโค้ด ไม่ log ข้อมูลส่วนตัว
- [ ] 9. ไม่มี N+1 หรือโหลดข้อมูลทั้งตาราง
- [ ] 10. error handling ไม่กลืน exception
- [ ] 11. ใช้ transaction เมื่อแก้หลายตาราง
- [ ] 12. ชื่อสอดคล้องกับ convention ทีม
- [ ] 13. ไม่มี dead code
- [ ] 14. dependency ใหม่ผ่านการตรวจและ audit
- [ ] 15. ผู้เปิด PR อธิบายโค้ดได้ทุกส่วน

ใช้ AI ช่วย review ได้ด้วย เช่น ส่ง diff ให้ AI ตรวจตามเช็กลิสต์นี้ แต่ให้ถือผลเป็นความเห็นเพิ่มเติม ไม่ใช่การอนุมัติ ผลที่ AI บอกว่า "ไม่พบปัญหา" ไม่ได้แปลว่าไม่มีปัญหา

สรุป

• โค้ดจาก AI ดูเรียบร้อยสม่ำเสมอ ส่วนที่ผิดจึงสังเกตยากกว่าโค้ดที่คนเขียน
• เริ่ม review จาก git diff --stat เพื่อดูขอบเขตก่อนลงรายละเอียด
• หมวดความปลอดภัย (input, output, สิทธิ์, secret และ log) ต้องตรวจทุก PR ไม่มีข้อยกเว้น
• ระวัง N+1, catch ที่กลืน error, การไม่ใช้ transaction และ dependency ที่ไม่จำเป็น
• เกณฑ์สุดท้ายคือคนเปิด PR ต้องอธิบายโค้ดได้

ลองทำ

นำเช็กลิสต์ไปใช้กับงานจริง

1. เลือก PR หรือ commit ล่าสุดที่ใช้ AI ช่วยเขียน (ของคุณเองหรือของทีม)
2. ไล่ตรวจทีละข้อทั้ง 15 ข้อ จดว่าข้อไหนไม่ผ่านและพบอะไร
3. ส่ง diff เดียวกันให้ AI ตรวจตามเช็กลิสต์ แล้วเทียบผลกับที่คุณตรวจเอง ดูว่าแต่ละฝ่ายพลาดอะไรบ้าง
4. ปรับเช็กลิสต์ให้เหมาะกับทีม แล้วเพิ่มลงใน PR template ของ repository