SA-Me.life

ผลกระทบจากการตัดสินใจเขียนโค้ดหรือออกแบบระบบอย่างรวดเร็ว เพื่อให้ทันเวลา แต่ไม่ได้ทำให้ “ดีที่สุดในเชิงวิศวกรรม” ณ เวลานั้น

เปรียบเทียบเหมือน “การยืมเวลา” แต่ต้อง “จ่ายดอกเบี้ย” ในรูปแบบของ ค่าใช้จ่ายในอนาคต เช่น ความซับซ้อน, บั๊ก, เวลา refactor, และความลำบากในการ scale

สิ่งที่เกิดขึ้น	Technical Debt
Hardcode ค่าไว้ในโค้ด	ถ้าต้องเปลี่ยน ต้องค้นหาและแก้หลายที่
Copy-Paste โค้ด	ถ้าแก้ logic ต้องตามไปแก้ทุกที่
ข้าม test / ไม่มี unit test	เสี่ยงเจอ regression และ debug ยาก
ไม่จัดโครงสร้างให้ดี	โค้ดอ่านยาก → onboard dev ใหม่ลำบาก
ใช้ lib/version เก่า	จะ upgrade ยากในอนาคต

ประเภทของ Technical Debt

ประเภท	คำอธิบาย
Deliberate (ตั้งใจ)	“รู้ว่าไม่ดี แต่ต้องรีบส่ง MVP ไปก่อน”
Accidental (ไม่ตั้งใจ)	“เพราะยังไม่เข้าใจระบบดีพอ ณ เวลานั้น”
Bit Rot	โค้ดดีในอดีต → แต่ปัจจุบันไม่เข้ากับ system ใหม่
Tooling/Dependency Debt	ใช้ framework/version ที่ล้าสมัย

ผลเสียจาก Technical Debt

• แก้ฟีเจอร์ใหม่ยากมาก
• เพิ่ม bug และ regression บ่อย
• Dev ใหม่ onboard แล้วงง
• ความเร็วทีมลดลงเรื่อย ๆ
• ทำให้ระบบ “ล่ม” ได้ถ้าสะสมเยอะ

ควรจัดการยังไง?

✅ จดไว้ใน ticket (เช่น Jira tag: tech-debt)
✅ ประเมิน impact → ทำ roadmap แก้แบบมีแผน
✅ ทำ refactor ทีละ module (ไม่ใช่ rewrite ทั้งระบบ)
✅ มี sprint สำหรับ “Refactoring / Code Health”
✅ ให้ความรู้ junior ว่า “หนี้ไม่ได้หายไปเอง