Technical Debt คือแนวคิดที่อธิบายถึงการเลือกใช้วิธีแก้ปัญหาที่ง่ายและรวดเร็วในปัจจุบัน แต่ส่งผลให้เกิดภาระที่จะต้องกลับมาแก้ไขหรือพัฒนาเพิ่มเติมในอนาคต
Technical Debt มักเกิดขึ้นจากการเลือกทางที่สะดวกเพื่อให้งานเสร็จเร็วที่สุด โดยไม่ได้วางแผนหรือทำอย่างระมัดระวังตั้งแต่แรก หรืออาจจะเกิดจากข้อจำกัดทางด้านเวลาที่บังคับให้ต้องพัฒนาระบบให้เสร็จตามเวลาที่กำหนดไว้
- ทำไมจึงเกิด technical debt
- เร่งพัฒนาผลิตภัณฑ์: เมื่อมีความกดดันเรื่องเวลาหรือทรัพยากร นักพัฒนามักจะเลือกวิธีที่รวดเร็วและหลีกเลี่ยงการทำงานที่ซับซ้อน เช่น เลือกโค้ดที่ไม่สมบูรณ์เพื่อให้งานเสร็จทันกำหนดเวลา
- ขาดการวางแผนระบบ: หากการออกแบบระบบหรือสถาปัตยกรรมไม่ครบถ้วนหรือไม่ยืดหยุ่นพอ การแก้ไขปัญหาในอนาคตจะยากขึ้น
- เปลี่ยนแปลงข้อกำหนด: เมื่อมีการเปลี่ยนข้อกำหนดหรือฟีเจอร์ใหม่ ต้องปรับแก้โค้ดเดิมที่ไม่ได้รองรับการเปลี่ยนแปลง
- ผลกระทบของ technical debt (ในระยะยาว)
- ความเร็วในการพัฒนาช้าลง: เพราะต้องเสียเวลาซ่อมแซมโค้ดเก่า หรือต้องทำความเข้าใจโค้ดที่ไม่เป็นระเบียบ
- ค่าซ่อมบำรุงสูงขึ้น: ต้องใช้ทรัพยากรแก้ไข technical debt ซึ่งอาจมีค่าใช้จ่ายสูงกว่าการวางแผนอย่างระมัดระวังแต่แรก
- ความเสี่ยงในระบบ: โค้ดที่ไม่ได้รับการพัฒนาที่ดีอาจเสี่ยงต่อข้อผิดพลาดที่อาจจะเกิดขึ้นในระบบ
- ประเภทของ technical debt
- Intentional Debt: เป็นหนี้ที่เกิดจากการตั้งใจเลือกวิธีลัดเพื่อให้ระบบเสร็จไวขึ้น รู้ทั้งรู้ว่ามีผลเสียในอนาคต เช่น การใช้โค้ดที่ไม่สมบูรณ์ในช่วงแรก
- Unintentional Debt: เกิดจากความรู้ไม่เพียงพอหรือข้อผิดพลาดที่ไม่ตั้งใจ เช่น การออกแบบโครงสร้างระบบที่ไม่เหมาะสม
- วิธีการลด technical debt
- Refactoring: การปรับปรุงโค้ดเดิมให้มีคุณภาพดีขึ้นและสามารถดูแลได้ง่ายขึ้น
- การเขียนเทสต์ (Testing): เพิ่มการทดสอบเพื่อให้มั่นใจว่าโค้ดที่เปลี่ยนแปลงไม่กระทบระบบหลัก
- Code Review: การตรวจสอบโค้ดโดยทีมเพื่อหาจุดบกพร่องหรือ technical debt ก่อนการปล่อยใช้งาน
- Best Practice: ยึดการปฏิบัติตามแนวทางที่ดีในการพัฒนาโปรแกรมที่มีคนเคยทำไว้อยู่แล้วเป็นแนวปฏิบัติ
Technical Dept เป็นสิ่งที่หลีกเลี่ยงไม่ได้ แต่สามารถทำให้มันน้อยที่สุดเท่าที่จะน้อยได้ ด้วยการวางแผนและการดำเนินการอย่างถูกต้องตามแนวทางที่กล่าวไว้ข้างต้น
Photo by Uyen Nguyen: pexels.com
