ปูนักสืบต้นฉบับส่องกองเฟืองบนโต๊ะสว่าง โดยมีเฟืองหนึ่งชิ้นเยื้องจากแนว
rustdebuggingdeveloper-experiencesurvey

ผลสำรวจ Debugging Rust 2026: ปัญหาไม่ใช่แค่เครื่องมือ แต่คือข้อมูลที่ดีบักเกอร์มองไม่เห็น

พี่โชว์Engineering

ทีมที่บอกว่า “Rust ดีบักยาก” อาจกำลังรวมปัญหาหลายชั้นไว้ในประโยคเดียว ตั้งแต่ตั้ง breakpoint ไม่ตรง ไปจนถึงเห็นค่าตัวแปรเป็นโครงสร้างที่อ่านไม่ได้ ผลสำรวจ State of Rust Debugging 2026 จากผู้ตอบมากกว่า 2,300 คนช่วยแยกชั้นเหล่านี้ได้ชัดขึ้น และทำให้เราแก้ workflow ได้ตรงจุดกว่าเปลี่ยนดีบักเกอร์แบบสุ่มๆ

ตัวเลขที่ควรหยุดอ่านสักครู่

  • มากกว่าครึ่งไม่ได้ใช้ดีบักเกอร์เป็นกิจวัตร และยังพึ่ง println! / dbg! มาก
  • 87% ของผู้ตอบที่ใช้ดีบักเกอร์ใช้การ step ผ่านโค้ด แต่ราวครึ่งหนึ่งเคยเจอปัญหากับการ step
  • 74% เคยเห็นค่าถูกแสดงในรูปแบบที่ไม่มีประโยชน์ และ 55% เคยพิมพ์ค่าตัวแปรไม่ได้
  • โค้ด async และ macro เป็นพื้นที่ที่ mapping ระหว่าง source กับ machine code ทำให้ประสบการณ์สะดุดบ่อย

ตัวเลขเหล่านี้ไม่ได้แปลว่า print debugging ผิด การพิมพ์ค่ารวดเร็ว ทำซ้ำง่าย และอยู่ในบันทึก CI ได้ แต่ถ้าทีมใช้เพราะ breakpoint, stepping หรือ data view เชื่อถือไม่ได้ นั่นคือหนี้ด้าน developer experience ที่ทำให้ bug ซับซ้อนใช้เวลานานขึ้น

แปลงผลสำรวจเป็นงานของทีม

เริ่มจากทำ “debugging smoke test” เล็กๆ ในทุก target หลัก: วาง breakpoint ก่อนและหลัง async boundary, เปิดดู enum ที่ซ้อนกัน, inspect collection และลองย้อน stack frame จากนั้นบันทึกเวอร์ชัน Rust, debugger adapter, IDE และ optimization level ไว้ด้วย เพราะ debug build กับ release build ให้ประสบการณ์ต่างกันมาก

ถ้า library ของทีมมีชนิดข้อมูลเฉพาะ ให้ตรวจว่ามี debugger visualization หรือ pretty-printer ที่ผู้ใช้จริงได้ประโยชน์หรือไม่ ผลสำรวจยังชี้ว่าผู้เขียนไลบรารีจำนวนมากไม่รู้จักกลไก debugger_visualizer ดังนั้นการเพิ่มเอกสารและตัวอย่างใน crate อาจคุ้มกว่าบังคับทุกคนจำ layout ภายใน

สุดท้าย แยก incident ว่าเป็นปัญหา source mapping, stepping, representation หรือ evaluation แล้วส่ง repro ที่เล็กที่สุดไปยังโปรเจกต์ที่เกี่ยวข้อง ข้อมูลแบบนี้ช่วย ecosystem ได้มากกว่า ticket กว้างๆ ว่า “debugger ใช้ไม่ได้”

Recap

  • อย่าลบ dbg! ทิ้งเพียงเพื่อความสวย ถ้ามันยังเป็นทางที่เชื่อถือได้ที่สุด
  • ทำ smoke test กับ async, macro และชนิดข้อมูลของทีม
  • บันทึก toolchain, adapter และ optimization level ทุกครั้งที่รายงานปัญหา
  • แยกอาการ stepping ออกจากอาการแสดงค่าผิดรูป