เรื่องที่ 28 ที่นักพัฒนาควรรู้ และ เข้าใจก็คือ How to Use a Bug Tracker
Bug, defect, incident หรือ ผลกระทบต่างที่ส่งผลต่อระบบงาน
สิ่งเหล่านี้คือสิ่งที่ developer ไม่มีวันที่จะหนีห่างจากมันได้เลย
ดังนั้น developer ควรเรียนรู้วิธีการจัดการ
และอยู่กับมันอย่างมีความสุข
สิ่งแรก คุณควรเรียนรู้วิธีการส่งและเขียน bug report ที่ดี
คำว่าดี มันต้องประกอบไปด้วย
- ต้องสามารถ reproduce bug นั้นได้ นั่นคือมีขั้นตอนการทำงานหรือทดสอบระบบ
- ต้องบอกได้ว่า bug นั้นเกิดขึ้นบ่อยหรือไม่ อย่างไร
- ต้องรู้ว่าสิ่งที่ระบบควรจะทำงานได้เป็นอย่างไร
- ต้องรู้ว่าสิ่งที่เกิดขึ้นจริงๆ นั้นมันเกิดขึ้นอย่างไร เช่นการบันทึก VDO การทำงาน หรือ ทดสอบไว้
ข้อมูลต่างๆ ของ bug report นั้นควรมีจำนวนที่มากพอ ละเอียด และ มีคุณภาพเพียงพอ
ที่จะบอก หรือ อธิบาย สิ่งเล็กๆ ที่เรียกว่า Bug
ไม่ใช่เขียน bug report ในทำนอง
- การทำงานส่วนนี้มันแย่มากๆ
- ทดสอบกี่ครั้ง ก็ error ทุกครั้ง
ลองคิดดูสิว่า คนมาอ่าน หรือ developer อ่านแล้วมีความรู้สึกอยากจะแก้ไขหรือไม่ ?
ดังนั้น เราควรเพื่ออธิบายให้ชัดเจนว่า Bug มันคืออะไร อย่างไร
ทำให้สามารถ reproduce bug ได้ง่าย
เขียนเพื่อให้คนอื่นๆ เข้าใจ ดังนั้นควรเคารพในสิ่งที่เขียนขึ้นมาเสมอ
Bug มันคือ การพูดคุย
ดังนั้นอย่าโยนความผิด หรือ ไปโทษใคร ว่าทำให้เกิด bug
แต่ให้พูดคุยกันเกี่ยวกับข้อมูล การทำงาน ที่ก่อให้เกิด bug
เนื่องจากบ่อยครั้ง bug เหล่านั้น มันอาจจะมาจากความเข้าใจผิด
ทั้งจากเข้าใจ requirement ผิด
ทั้งจากเข้าใจขั้นตอนการทำงานผิด
ดังนั้น bug มันคือ สิ่งที่ทำให้เราเข้าใจในสิ่งที่กำลังสร้างได้ดี
ดังนั้น feedback loop ของ bug ก็ควรจะรวดเร็วเช่นกันนะ
การเปลี่ยนสถานะของ Bug มันคือ สิ่งที่บอกว่า คุณคิดอย่างไรต่อ bug
ในการเปลี่ยนสถานะของ bug จาก Open ไปยัง Closed
มันคือ สิ่งที่บอกให้คนอื่นๆ รู้ว่าคุณคิดเห็นอย่างไรต่อ bug นั้นๆ
ดังนั้น คุณควรใช้เวลาพอสมควรในการอธิบายว่า
ทำไมคุณจึงทำการเปลี่ยนสถานะของ bug นั้นๆ เช่น
ทำไมถึงต้องเปลี่ยนสถานะเป็น closed ด้วย
หรือแม้แต่การเปลี่ยนระดับความสำคัญของ bug ก็เช่นกัน
ลดการจำนวนของ field ในการกรอกข้อมูลเกี่ยวกับ Bug ลงบ้าง
ยิ่งมี field ในการเขียน bug report ยิ่งมาก ก็ยิ่งเสียเวลา
ดังนั้น เขียนให้มันน้อยๆ แต่สามารถเข้าใจได้ง่ายดีกว่าไหม เช่น
การใช้ prefix ไปข้างหน้าชื่อของ bug เช่น XXX : …..
มันทำให้คุยง่ายต่อการค้นหา
มันทำให้คุณง่ายต่อการจัดกลุ่ม
มันทำให้คุณง่ายต่อการเรียงลำดับ
มันทำให้คุณง่ายต่อการลบสิ่งที่มันซ้ำๆ
ต้องทำให้มั่นใจว่า
ทุกคนในทีมรู้ว่า bug อยู่ตรงไหน และ หามันอย่างไร
ทุกคนรู้ว่าจะค้นหา bug อย่างไร
ทุกคนสามารถใช้งานได้เหมือนๆ กัน
ทุกคนสามารถเรียนรู้ และ ปรับปรุงจาก bug
นั่นคือ เหตุผลที่ คุณควรมีระบบ Bug Tracker
สุดท้ายให้จำไว้ว่า
Bug มันไม่ใช่งานทั่วไป
Bug มันไม่ได้ก่อให้เกิด productivity อะไรเลย
Bug มันไม่ใช่การเขียน code
Bug มันต้องใช้ความพยายามเพื่อทำความเข้าใจ
Bug มันต้องใช้ความพยายามในการแก้ไข
ดังนั้นคุณควรใช้เวลาหา เข้าใจ แก้ไขมัน ให้น้อยที่สุดเท่าที่จะทำได้
หรือป้องกันไม่ให้เกิด bug
หรือ เกิดให้น้อยที่สุด
หรือ ทำให้รู้อย่างรวดเร็วว่า bug เกิดขึ้นตรงไหน
