Debug ให้เร็วขึ้นด้วยการทำปัญหาให้เกิดซ้ำและลดขอบเขตการค้นหา

ภาพรวม

Debug ให้ไวขึ้น ไม่ใช่เริ่มจากเดาสุ่ม แต่เริ่มจาก “ทำให้ปัญหาเล็กลง” 🐞⚡

หลายคนเสียเวลาทั้งวันเพราะไล่ดูทุกไฟล์ ทุกฟังก์ชัน ทุก log ทั้งที่จริงแล้ว bug ส่วนใหญ่ซ่อนอยู่ใน “จุดเปลี่ยนข้อมูล” ไม่กี่จุดเท่านั้น 👀

เทคนิคที่ช่วยประหยัดเวลาได้มากที่สุดอย่างหนึ่งคือ แยกให้ออกก่อนว่าเป็นปัญหาจาก Input, Logic, State, Environment หรือ Timing 🧠

ถ้าหาต้นทางไม่เจอ อย่าเพิ่งแก้หลายจุดพร้อมกัน เพราะยิ่งแก้พร้อมกันมากเท่าไร ยิ่งไม่รู้ว่าอะไรทำให้หาย หรืออะไรทำให้พังหนักกว่าเดิม 😵‍💫

วิธีคิดที่มืออาชีพใช้บ่อยมาก เริ่มจากทำให้ bug “เกิดซ้ำได้” ก่อน 🔁 ถ้าทำให้มันเกิดซ้ำไม่ได้ การ debug จะกลายเป็นการลุ้นมากกว่าการวิเคราะห์

ตัวอย่างง่ายมาก ถ้าผู้ใช้บอกว่า “กดบันทึกแล้วบางครั้งข้อมูลหาย” อย่าเริ่มจากเปิดโค้ดทั้งโปรเจกต์ ให้เริ่มจด step ว่าต้องกดอะไร ใช้ข้อมูลแบบไหน และเกิดบนเครื่องไหน 💻📱

เมื่อทำให้เกิดซ้ำได้แล้ว ให้ลดพื้นที่ค้นหา จากทั้งระบบ เหลือเฉพาะ flow ที่เกี่ยวข้องเท่านั้น 🎯 เช่น กรอกฟอร์ม กด submit เรียก API แปลงข้อมูล บันทึก database แสดงผลกลับหน้าเว็บ

จากนั้นใส่ log แบบมีเป้าหมาย ไม่ใช่ log ทุกบรรทัด 🪵 log ที่ดีควรตอบได้ว่า ข้อมูลเข้ามาเป็นอะไร ข้อมูลเปลี่ยนตรงไหน ค่าที่คาดหวังกับค่าจริงต่างกันตรงใด

ตัวอย่าง mindset ที่ช่วยมาก ก่อนเข้า function ค่า userId เป็น 42 หลังออก function กลายเป็น null แปลว่าจุดพังอยู่ “ระหว่างทาง” ไม่ใช่ทั้งระบบ 🔍

อีกเทคนิคที่คนมักมองข้าม เช็กของที่ “ไม่ใช่โค้ด” ด้วย 🧩 เช่น env คนละชุด timezone ไม่ตรง cache ค้าง dependency version ไม่เหมือนกัน data ใน staging กับ production คนละรูปแบบ

หลาย bug ไม่ได้เกิดจากเขียนโค้ดผิด แต่เกิดจากสภาพแวดล้อมไม่เหมือนตอนที่เราคิด ☁️

ถ้าเป็น bug แปลกๆ หลัง deploy ให้ลองเช็ก 3 อย่างนี้ก่อนเสมอ 🚀

1. config เปลี่ยนไหม
2. data จริงต่างจาก data ทดสอบไหม
3. service ภายนอก response เปลี่ยนไหม

อีกเครื่องมือที่คุ้มมากคือ breakpoint เพราะบางเรื่องดูจาก log อย่างเดียวไม่พอ โดยเฉพาะ bug ที่เกี่ยวกับ loop, async, closure หรือ state ที่เปลี่ยนหลายรอบ 🛠️

สิ่งสำคัญมากคืออย่าเชื่อ assumption เร็วเกินไป ประโยคที่ทำให้เสียเวลาบ่อยที่สุดคือ “จุดนี้ไม่น่าพังหรอก” 😅

ในโลกจริง จุดที่คิดว่าไม่น่าพัง มักเป็นจุดที่ไม่มีใครเปิดดูมาหลายเดือนพอดี 📦

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

การจดสิ่งที่ลองไปแล้วสำคัญมาก 📝 เพราะเวลางานยาวเกิน 1 ชั่วโมง สมองจะเริ่มวนกลับไปลองวิธีเดิมโดยไม่รู้ตัว

อีกเทคนิคสำหรับทีม เวลาโยนคำว่า “มันพัง” ให้กัน ให้แนบข้อมูล 4 อย่างมาด้วยเสมอ 🤝 step ที่ทำให้เกิดปัญหา ผลลัพธ์ที่เกิดขึ้น ผลลัพธ์ที่ควรจะเป็น ภาพ error หรือ log ที่เกี่ยวข้อง

แค่นี้ก็ลดเวลาคุยไปได้เยอะมาก และทำให้คนที่มารับช่วง debug ต่อ ไม่ต้องเริ่มจากศูนย์ ⏳

ถ้าจำได้แค่ประโยคเดียวจากโพสต์นี้ ให้จำประโยคนี้ไว้เลย 💡 “อย่าเริ่ม debug จากการเดา ให้เริ่มจากการตัดสิ่งที่ไม่เกี่ยวออกทีละชั้น”

คนที่ debug เร็ว ไม่ได้เก่งเพราะจำ syntax เยอะกว่าเสมอไป แต่เก่งเพราะรู้ว่าจะพิสูจน์ความผิดปกติยังไงให้สั้นที่สุด 🧠✨

ยิ่งระบบใหญ่ขึ้น ทักษะนี้ยิ่งมีค่า เพราะเวลาที่ประหยัดได้ ไม่ใช่แค่ของตัวเอง แต่เป็นเวลาของทั้งทีมด้วย 🚀

แนวทางนำไปใช้

• นำแนวคิดจากโพสต์นี้ไปทดลองกับงานจริงของคุณ
• แยกเป็นขั้นตอนเล็ก ๆ แล้วทำทีละส่วน
• บันทึกผลลัพธ์และสิ่งที่เรียนรู้เพื่อต่อยอด

สรุป

ใช้แนวทาง reproduce, isolate, inspect และเปลี่ยนทีละจุด เพื่อแยกปัญหา Input, Logic, State, Environment และ Timing โดยไม่เสียเวลากับการเดาสุ่ม