อ่านไปเจอเรื่อง Test-Driven Bugfixing (TDB)
จากหนังสือ Test Driven Development for Embedded C
เป็นแนวทางที่น่าสนใจ
สำหรับการเขียนชุดการทดสอบแบบอัตโนมัติขึ้นมา
นักพัฒนาน่าจะลองนำไปใช้กันดูนะ
ปล. ผมชอบเรียกว่า Bug-Driven Development
ในหนังสืออธิบายว่า
เมื่อเกิด bug ขึ้นมา แน่นอนว่าต้องแก้ไขให้ถูกต้อง หลังจากนั้นทำการทดสอบเพื่อทำให้แน่ใจ มั่นใจว่ามันทำงานได้อย่างถูกต้องจริงอีกอย่างหนึ่งคือ bug มันกำลังบอกหรือสะท้อนให้เห็นว่า การพัฒนาและทดสอบมันแย่ขนาดไหนดังนั้นน่าจะเริ่มกลับมาพิจารณา เพื่อหาแนวทางในการแก้ไขและปรับปรุงได้แล้วนะ
ดังนั้นเมื่อพบเจอ bug แล้วสิ่งที่ควรทำคือ
- ทำการเขียนชุดการทดสอบเพื่อทำให้เห็น bug
- ถ้ายังเขียนไม่ได้ ก็ทำการ debug หรือเรียนรู้ จากนั้นนำสิ่งที่เรียนรู้ในแต่ละขั้นตอนมาเขียนไว้
- เมื่อเข้าใจแล้ว ก็เริ่มเขียนชุดการทดสอบที่ต้องการ เพื่อทำให้เห็น bug
- ทำการแก้ไข code
- ทำการทดสอบซ้ำอีกครั้ง ต้องผ่าน
- เพียงเท่านี้ก็ได้ชุดการทดสอบเพิ่มมาแล้ว
ต่อมา ถ้าชุดการทดสอบที่เขียนขึ้นมาเพื่อแสดงให้เกิด bug มันทำงานช้า
สิ่งที่ควรต้องทำคือ แก้ไข bug ก่อน เมื่อผ่านแล้ว ให้ทำการแก้ไข test และ code เพื่อให้ทำการทดสอบได้รวดเร็วขึ้น แน่นอนว่า มันก็คือหนังชีวิตเช่นกันแต่ถ้าคุณไม่ทำ
ลองคิดเอาเองว่า ค่าใช้จ่ายในการแก้ไข bug แบบนี้ กับแบบที่คุณทำอยู่นั้น แบบไหนมันเปลืองกว่ากัน ทั้งเวลาการหา ทั้งเวลาการแก้ไข ทั้งเวลาการทดสอบ ทั้งเวลาการ deploy ทั้งสิ่งที่ business เสียหายไปวันนี้คุณแก้ไข bug ด้วยวการแก้ไขที่ต้นเหตุจริง ๆ หรือยัง ? หรือแค่ทำการ patch หรือ workaround หรือพูดตรง ๆ คือ แก้ให้ผ่าน ๆ ไปก่อน เท่านั้นเอง