- แนวคิดของหนี้ทางเทคนิค
- ต้นทุนแฝงของการต้องกลับมาทำงานซ้ำในอนาคต ซึ่งเกิดขึ้นเมื่อเลือกโซลูชันที่ง่ายแต่มีข้อจำกัด แทนที่จะเลือกแนวทางที่ดีกว่าซึ่งอาจใช้เวลามากกว่า
- ต้นทุนงานเพิ่มเติมที่เกิดจากการเลือกโซลูชันที่เร็วที่สุด แทนที่จะเป็นโซลูชันที่มีประสิทธิภาพที่สุด
- ประเภทของหนี้ทางเทคนิคตามการจำแนกของวิศวกรซอฟต์แวร์ Martin Fowler
- หนี้ทางเทคนิคแบบรอบคอบและตั้งใจ (Prudent & Deliberate)
- ทีมรู้ว่ากำลังก่อหนี้ แต่พิจารณาว่า ‘ผลตอบแทนจากการปล่อยออกสู่ตลาดให้เร็วขึ้นมากกว่าต้นทุนในการชำระหนี้หรือไม่’
- หนี้ทางเทคนิคแบบไม่รอบคอบแต่ตั้งใจ (Reckless & Deliberate)
- รู้หลักการออกแบบที่ดีและสามารถปฏิบัติได้ แต่ไม่มีเวลาพอจะเขียนโค้ดให้สะอาด จึงเลือกเดินหน้าแบบ ‘เร็วและเละ’
- หนี้ทางเทคนิคแบบรอบคอบแต่ไม่ตั้งใจ (Prudent & Inadvertent)
- พัฒนาซอฟต์แวร์ที่ดีและโค้ดก็สะอาด แต่เพิ่งมารู้ภายหลังเมื่อเวลาผ่านไปว่า ‘การออกแบบควรจะเป็นอย่างไร’
- หนี้ทางเทคนิคแบบไม่รอบคอบและไม่ตั้งใจ (Reckless & Inadvertent)
- เป็นผลที่เกิดจากการไม่รู้
- วิธีจัดการหนี้ทางเทคนิค
- จัดการรายการหนี้ทางเทคนิค
- ทบทวนย้อนหลังโครงการเพื่อจัดทำรายการหนี้ทางเทคนิคและแชร์ร่วมกัน
- ทุกครั้งที่เกิดหนี้ทางเทคนิค ให้บันทึกงานที่ต้องใช้ในการแก้ไขหนี้นั้น พร้อมทั้งความพยายามและกำหนดการที่คาดไว้
- ให้ทีมอภิปรายว่าจะจัดการหนี้ทางเทคนิคหรือไม่ และเมื่อใดจะจัดการ พร้อมวางแนวทางแก้ไข
- แยกความต่างระหว่างหนี้ทางเทคนิคที่ดีกับหนี้ทางเทคนิคที่ไม่ดี
- การจำแนกหนี้ทางเทคนิคแบบนี้ช่วยในการจัดลำดับความสำคัญของปัญหาที่ใหญ่ที่สุด
- การรีแฟกเตอร์
- ระหว่างทำงานให้จัดระเบียบส่วนที่จำเป็น และค่อย ๆ รีแฟกเตอร์ไปทีละน้อย
- เมื่อต้องรีแฟกเตอร์ครั้งใหญ่ ให้แชร์สถานการณ์กับทีม และแจ้งความเสี่ยงกับต้นทุนของหนี้ทางเทคนิค
- เขียนโค้ดทดสอบ
- ยิ่งโค้ดซับซ้อนมากขึ้น และยิ่งขนาดของการรีแฟกเตอร์ใหญ่ขึ้น ก็ยิ่งยากที่จะแก้โค้ดทีเดียวให้เสร็จโดยไม่มีบั๊ก
- หากต้องการป้องกันผลข้างเคียง ควรเขียนโค้ดทดสอบ
- กำหนดและปฏิบัติตามมาตรฐานคุณภาพ
- กำหนดมาตรฐานคุณภาพเพื่อไม่ให้นักเขียนโค้ดปล่อยโค้ดที่หยาบหรือไม่เรียบร้อยออกไป
- ไม่มีการเปลี่ยนกฎหรือกำหนดการแบบกะทันหัน
- หากมีการเปลี่ยนกฎที่เกี่ยวข้องกับนักพัฒนาอย่างต่อเนื่อง หรือเปลี่ยนเดดไลน์ จะหลีกเลี่ยงหนี้ทางเทคนิคได้ยาก
- ควรให้กำหนดการ วิธีการ และปริมาณงานที่สมจริงเพื่อให้สามารถจัดการหนี้ทางเทคนิคได้
- หนี้ทางเทคนิคเลวร้ายเสมอไปหรือไม่?
- ในหนังสือของ Chris Riccomini และ Dmitriy Ryaboy 『ต้องอ่าน! คู่มือ Onboarding สำหรับนักพัฒนา: การเติบโตเป็นนักพัฒนามืออาชีพที่เข้าใจซอฟต์แวร์ที่ยั่งยืนและวัฒนธรรมการทำงานร่วมกันที่ราบรื่น』 ระบุว่า “ถ้าเป็นหนี้ที่ถูกฝึกให้ทีมสามารถจัดการได้ในภายหลัง ก็อาจเรียกได้ว่าเป็น ‘หนี้ที่ดี’”
- But หนี้ทางเทคนิคอาจส่งผลกระทบเชิงลบต่อธุรกิจ จึงต้องได้รับการแก้ไข
- สิ่งนี้อาจปรากฏในรูปของบั๊กและทำให้ประสบการณ์ผู้ใช้แย่ลง
- หากหนี้ทางเทคนิคแย่ลง นักพัฒนาจะทำงานภายในโค้ดเบสเดิมได้ยากขึ้น
- ต้องแบ่งเวลาไปกับการพัฒนาฟีเจอร์ใหม่และแก้ไขฟีเจอร์เดิม ทำให้วงจรการพัฒนาซอฟต์แวร์ช้าลง และการออกสู่ตลาดล่าช้าออกไป
ยังไม่มีความคิดเห็น