ใช้ AI อ่านโค้ดเก่า (Legacy) ให้เข้าใจเร็วขึ้น

งานที่นักพัฒนาหลายคนกลัวที่สุดไม่ใช่การเขียนระบบใหม่ แต่คือการรับช่วงระบบเก่าที่ไม่มีเอกสาร คนเขียนลาออกไปแล้ว controller ยาวหลายพันบรรทัด และไม่มีใครกล้าแตะ AI ช่วยงานนี้ได้มาก เพราะมันอ่านโค้ดได้เร็วและอธิบายได้ไม่เบื่อ แต่ก็มีกับดักสำคัญคือ AI อาจ "อธิบายมั่ว" อย่างมั่นใจ บทความนี้จะแนะนำวิธีใช้ AI สร้างแผนที่ระบบ ไล่ flow ทีละ request และยืนยันความเข้าใจด้วยการรันจริงและใส่ log พร้อมตัวอย่างกับโปรเจกต์ Yii2

เริ่มจากแผนที่ระบบ ไม่ใช่รายละเอียด

ความผิดพลาดที่พบบ่อยคือเปิดไฟล์แรกที่เจอแล้วถาม AI ว่า "โค้ดนี้ทำอะไร" ซึ่งได้คำอธิบายเป็นท่อน ๆ ที่ต่อกันไม่ติด วิธีที่ดีกว่าคือขอ "แผนที่" ของทั้งระบบก่อน

สำหรับ Yii2 ให้รวบรวมไฟล์เหล่านี้ให้ AI ดู (หรือให้ agent อ่าน)

• composer.json เพื่อดูเวอร์ชันและ extension ที่ใช้
• โครงสร้างโฟลเดอร์ เช่น ผลจาก tree -L 2 -I vendor
• ไฟล์ config หลัก (config/web.php หรือ frontend/config/main.php) โดยตัดค่า secret ออก
• รายชื่อ migration หรือ schema ฐานข้อมูลแบบไม่มีข้อมูล

ตัวอย่าง prompt

นี่คือโปรเจกต์ Yii2 ที่ฉันเพิ่งรับมาดูแล ช่วยสร้างแผนที่ระบบจากไฟล์ที่แนบ

1. เป็น basic หรือ advanced template มี application อะไรบ้าง
2. module และ component สำคัญที่ลงทะเบียนไว้ใน config
3. URL rules ที่สำคัญ และ controller ที่น่าจะเป็นแกนของระบบ
4. ตารางหลักและความสัมพันธ์ที่เดาได้จาก schema
5. จุดที่ดูผิดปกติหรือเสี่ยง

แยกให้ชัดว่าข้อไหน "เห็นจากโค้ด" และข้อไหน "สันนิษฐาน" และบอกชื่อไฟล์ที่ใช้อ้างอิงทุกข้อ

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

ไล่ flow ทีละ request

เมื่อมีภาพรวมแล้ว ให้เลือก request จริงหนึ่งตัวที่สำคัญต่อธุรกิจ เช่น "ลูกค้ากดยืนยันคำสั่งซื้อ" แล้วไล่ทีละขั้น ใน Yii2 เส้นทางของ request โดยทั่วไปคือ

1. web/index.php สร้าง application จาก config
2. urlManager แปลง URL เป็น route ตาม rules
3. สร้าง controller และรัน behaviors() เช่น AccessControl, VerbFilter
4. beforeAction() ของ controller และ module (ถ้ามี)
5. action ทำงาน เรียก model, service, component
6. model ทำ validate(), event beforeSave/afterSave, behaviors ของ model
7. render view หรือ redirect

prompt สำหรับขั้นนี้

ไล่ flow ของ POST /order/confirm ทีละขั้นตั้งแต่ URL rule จนถึง response ระบุไฟล์และ method ทุกขั้น รวมถึง behaviors, event handler และ afterSave ที่อาจทำงานแอบแฝง ถ้าขั้นไหนต้องดูไฟล์ที่ยังไม่ได้แนบ ให้บอกชื่อไฟล์ที่ต้องการแทนการเดา

ใน Yii2 จุดที่มักซ่อนตรรกะสำคัญและคนอ่านมองข้ามคือ behaviors() ของ model (เช่น TimestampBehavior หรือ behavior ที่ทีมเขียนเอง), afterSave(), event handler ที่ผูกใน bootstrap และ component ที่ override คลาสมาตรฐาน ให้ถาม AI ถึงจุดเหล่านี้โดยตรง

ระวังคำอธิบายมั่ว

AI อธิบายโค้ดได้คล่องมาก จนบางครั้งเราลืมว่ามันอาจผิด สัญญาณที่ควรสงสัย

• อธิบาย method ที่เราหาในโค้ดไม่เจอ
• บอกว่า "framework จะทำ X ให้อัตโนมัติ" โดยไม่ระบุว่าอยู่ใน config หรือ behavior ไหน
• คำอธิบายเรียบร้อยเกินไปสำหรับโค้ดที่ดูยุ่งเหยิง ระบบเก่ามักมีทางแยกแปลก ๆ ที่ AI อาจ "ทำให้สวย" ในคำอธิบาย
• สรุปพฤติกรรมจากชื่อฟังก์ชัน เช่น เห็น sendEmail() แล้วบอกว่าส่งอีเมล ทั้งที่จริงแค่ใส่คิว หรือถูกปิดไว้ด้วย flag
• ใช้ความรู้ของ Yii2 เวอร์ชันอื่นหรือ framework อื่นมาอธิบาย

หลักคือ ถือคำอธิบายของ AI เป็น สมมติฐาน ที่ต้องยืนยัน ไม่ใช่ข้อเท็จจริง

ยืนยันด้วยการรันและใส่ log

วิธีที่เชื่อถือได้ที่สุดคือดูว่าโค้ดทำงานจริงอย่างไร ใน Yii2 มีเครื่องมือพร้อมอยู่แล้ว

1. Debug toolbar ใน environment dev

extension yii2-debug แสดง route ที่ถูกเรียก query SQL ทั้งหมด log และเวลาที่ใช้ของแต่ละ request เปิดเฉพาะเครื่อง dev เท่านั้น ห้ามเปิดบน production

2. ใส่ log ชั่วคราวด้วย category ของเราเอง

// ใน OrderController::actionConfirm()
Yii::info([
    'step' => 'confirm:start',
    'orderId' => $id,
    'status' => $order->status,
], 'legacy-trace');

// ใน Order::afterSave()
Yii::info([
    'step' => 'order:afterSave',
    'insert' => $insert,
    'changed' => array_keys($changedAttributes),
], 'legacy-trace');

แล้วตั้ง log target ให้แยกไฟล์เฉพาะ category นี้ใน config ของ dev

'log' => [
    'targets' => [
        [
            'class' => \yii\log\FileTarget::class,
            'categories' => ['legacy-trace'],
            'levels' => ['info'],
            'logFile' => '@runtime/logs/legacy-trace.log',
            'logVars' => [],
        ],
    ],
],

ข้อควรระวัง: อย่า log ข้อมูลส่วนบุคคล รหัสผ่าน หรือ token ให้ log แค่ id และสถานะ และลบ log ชั่วคราวออกก่อน merge

3. เทียบผลกับคำอธิบายของ AI

กดใช้งานจริงหนึ่งรอบ แล้วนำลำดับใน log ไปเทียบกับ flow ที่ AI อธิบาย ถ้าไม่ตรง ให้แปะ log กลับไปให้ AI ดูและถามว่าทำไม รอบนี้ AI จะมีหลักฐานจริงประกอบ คำอธิบายจะแม่นขึ้นมาก

4. ใช้ SQL log ตรวจ query

ถ้า AI บอกว่า action นี้ "อัปเดตแค่ตาราง order" ให้ดูใน debug toolbar ว่ามี query ไปตารางอื่นด้วยหรือไม่ ระบบเก่ามักมี side effect ที่ไม่มีใครจำได้

เปลี่ยนความเข้าใจเป็นเอกสารและเทสต์

เมื่อยืนยันแล้ว อย่าปล่อยให้ความรู้หายไปกับประวัติแชต

• ให้ AI ร่างเอกสาร flow ของ request ที่ยืนยันแล้ว เก็บใน docs/flows/ ของ repository
• เขียน characterization test ที่บันทึกพฤติกรรมปัจจุบันไว้ ก่อนเริ่มแก้หรือ refactor (รายละเอียดในบทความ "Refactor ด้วย AI โดยไม่พังของเดิม")
• เพิ่มสิ่งที่เรียนรู้ลงไฟล์แนวทางโปรเจกต์ เช่น "การเปลี่ยนสถานะ order ต้องผ่าน OrderStatusService เท่านั้น"
• จดจุดเสี่ยงที่พบ เช่น query ที่ต่อ string หรือ action ที่ไม่มีการตรวจสิทธิ์ แยกเป็น issue

เช็กลิสต์อ่านโค้ดเก่ากับ AI

1. ขอแผนที่ระบบก่อน โดยให้แยก "เห็นจากโค้ด" กับ "สันนิษฐาน"
2. เลือก request สำคัญทีละตัว ไล่ตั้งแต่ URL ถึง response
3. ถามถึง behaviors, event และ afterSave โดยตรง
4. ตรวจทุกชื่อไฟล์และ method ที่ AI อ้างว่ามีอยู่จริง
5. ยืนยันด้วย debug toolbar และ log ชั่วคราว
6. บันทึกผลเป็นเอกสารและเทสต์ใน repository
7. ไม่ส่ง secret และข้อมูลลูกค้าจริงให้ AI

สรุป

• เริ่มจากแผนที่ระบบ แล้วค่อยลงรายละเอียดทีละ request
• บังคับให้ AI อ้างชื่อไฟล์และแยกข้อเท็จจริงกับการเดา
• คำอธิบายของ AI คือสมมติฐาน ต้องยืนยันด้วยการรันจริง log และ SQL ที่เกิดขึ้น
• ใน Yii2 ให้สนใจ behaviors, event และ afterSave ซึ่งมักซ่อนตรรกะสำคัญ
• เปลี่ยนความเข้าใจที่ยืนยันแล้วเป็นเอกสารและเทสต์ เพื่อไม่ต้องเริ่มใหม่ทุกครั้ง

ลองทำ

เลือก action หนึ่งตัวในโปรเจกต์ Yii2 ที่คุณยังไม่เข้าใจดี

1. ให้ AI อธิบาย flow ของ action นั้นตั้งแต่ URL ถึง response พร้อมชื่อไฟล์และ method ทุกขั้น
2. ใส่ Yii::info() ด้วย category legacy-trace ที่จุดเริ่ม action, ก่อน save และใน afterSave()
3. กดใช้งานจริงบนเครื่อง dev แล้วเทียบลำดับใน log และ SQL ใน debug toolbar กับคำอธิบายของ AI
4. นับว่าคำอธิบายผิดหรือขาดกี่จุด แล้วเขียนเอกสาร flow ฉบับที่ยืนยันแล้วเก็บไว้ในโปรเจกต์