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