Technical debt คือช่องว่างระหว่างโค้ดปัจจุบันกับโค้ดที่ควรจะเป็น ซึ่งเกิดขึ้นโดยจงใจหรือไม่จงใจเพื่อให้เคลื่อนไปข้างหน้าได้เร็วขึ้น หนี้บางส่วนไม่เป็นไร งานของเราคือการจัดการ ไม่ใช่การกำจัดมัน กุญแจคือการจัดลำดับความสำคัญของหนี้ที่เป็นอันตรายต่อการทำงาน
จัดลำดับความสำคัญตามผลกระทบ ไม่ใช่ความรำคาญ
text
For each piece of debt, ask:
- How often does it slow us down or cause bugs? (frequency)
- How bad is it when it bites? (severity)
- How risky/expensive is it to fix? (cost)
High frequency + high severity + low cost → fix now
Low frequency + low severity → leave it, document it
ตัวอย่างที่เป็นรูปธรรม
โมดูลที่เปราะบางและแตกขณะทุกครั้งที่ release ทำให้ทีมติดขัดทุกสัปดาห์ คุ้มค่าที่จะแก้ไข ส่วน utility ที่น่าเกลียดแต่ใช้งานได้ดี ที่ไม่มีใครแตะต้อง ไม่ ควร เถิดว่ามันจะไม่ถูกใจคุณก็ตาม การ refactor เป็นการเห่อหว่าน ไม่ใช่การสร้างคุณค่า