สมมติฐาน การทำ logging และการค้นหาแบบทวิภาค

เมื่อ AI เสนอสาเหตุมาแล้ว อย่าเพิ่งยอมรับทันที ทดสอบมันแบบประหยัด วิธีทดสอบที่ประหยัดที่สุดมักจะเป็นบรรทัด log

ขอให้ AI เพิ่ม logging ชั่วคราว:

"ก่อนที่เราจะเปลี่ยนอะไร ให้เพิ่ม console.log (หรือ print) ที่แสดงค่าของ user ก่อนบรรทัด 14 เพื่อดูว่ามันเป็น undefined จริงหรือไม่"

รันมัน แล้ววางผลลัพธ์กลับมา ตอนนี้คุณมี หลักฐาน ไม่ใช่ทฤษฎี บางทีอาจเป็นว่า user เป็น undefined จริง — ยืนยันสมมติฐาน หรือบางทีมันอาจปกติดี และตัวการที่แท้จริงอยู่ในระดับที่สูงกว่าขึ้นไป ไม่ว่าจะทางไหนคุณก็ก้าวหน้าขึ้น เพิ่ม log อย่างเต็มที่ระหว่างที่คุณสืบสวน: ค่าของตัวแปร และ ป้ายกำกับที่บอกว่ามันคือตัวไหน และ log อยู่ตรงไหน console.log(user) เปล่า ๆ ที่พิมพ์ undefined ออกมามีประโยชน์น้อยกว่า console.log("user at validate.js:14 =", user) มาก และอย่าลืมดึง log ชั่วคราวออกเมื่อบั๊กถูกแก้แล้ว — log ดีบักที่หลงเหลืออยู่ก็เป็นความยุ่งเหยิงเล็ก ๆ ของมันเอง

เมื่อบั๊กอยู่ที่ไหนสักแห่งในกระบวนการที่ยาวและคุณบอกไม่ได้ว่าอยู่ตรงไหน ให้ใช้ การค้นหาแบบทวิภาค (binary search) ตัดพื้นที่ต้องสงสัยลงครึ่งหนึ่ง: เพิ่ม log ตรงจุดกึ่งกลาง

แนวคิดคือ: การตรวจสอบแต่ละครั้งทิ้งครึ่งหนึ่งของสิ่งที่เหลืออยู่ไป ดังนั้นพื้นที่ค้นหาขนาดใหญ่จะยุบตัวลงอย่างรวดเร็ว ในที่นี้บั๊กซ่อนอยู่ที่ไหนสักแห่งระหว่างขั้นตอนที่ 1 ถึง 8 — สามครั้งของการตรวจสอบก็จับมันได้:

   step:  1  2  3  4  5  6  7  8      a bug is somewhere in here
          ░░░░░░░░░░░░░░░░░░░░░░

   check 1 ── log at 4 ── OK ──▶  bug is AFTER 4, drop 1–4
                                  ░░░░░░░░░░░  (5 6 7 8 left)

   check 2 ── log at 6 ── BAD ─▶  bug is AT/BEFORE 6, drop 7–8
                                  ░░░░░  (5 6 left)

   check 3 ── log at 5 ── OK ──▶  bug is at step 6   ✔ found

   8 steps → 3 checks.  1000 steps → about 10 checks.

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