ในการพัฒนา software นั้นคำว่า Technical Dept
มักถูกพูดกันบ่อยๆ ในการพัฒนา software
ดังนั้นเรามาทำความรู้จักคำนี้หน่อยว่า จริงๆ แล้วมันคืออะไร
มีลักษณะอย่างไร มีข้อดีหรือข้อเสียอะไรบ้าง
Technical Debt คืออะไร
แปลเป็นไทย ก็คือ หนี้ทางเทคนิค … งงเข้าไปใหญ่
คำว่า Technical Debt ถูกเรียกครั้งแรกโดย Ward Cunningham
ในปี 1992 เพื่อใช้อธิบายถึงปัญหาของการพัฒนา software ในแนวทางที่ไม่ถูกต้อง
ให้กับคนที่ไม่รู้เรื่อง technical เข้าใจได้ง่ายๆ
จาก Wikipedia
อาจจะเรียกว่า Design Debt หรือ Code Debt
มันคืออะไรก็ตามมักจะถูกมองในแง่ลบ
ซึ่งเป็นผลมาจาก
- โครงสร้าง software ที่แย่
- ขั้นตอนการพัฒนาที่แย่
- Code ที่แย่
หนี้ต่างๆ ที่เกิดขึ้น มาจากสิ่งที่เราพยายามจะทำให้มันเสร็จๆ ไปก่อน
ก่อนที่จะมาดูในเรื่องอื่นๆ เช่น คุณภาพ เป็นต้น
ส่งผลทำให้เราต้องเสียค่าใช้จ่ายจำนวนมาก มาแก้ไขหนี้เหล่านี้
หลังจากที่ software เสร็จไปแล้ว
และยิ่งนับวันจะต้องจ่ายแพงขึ้นเรื่อยๆ
สาเหตุที่ทำให้เกิด Technical Debt
- ได้รับแรงกดดันมาจากฝ่าย Business นั่นก็คือเรื่องเวลาและจำนวนงานที่ไม่สัมพันธ์กัน
- ไม่เข้าใจขั้นตอนการทำงาน
- ส่วนการทำงานต่างๆ ผูกมัดกันไปหมด ทำให้ยากต่อการเปลี่ยนแปลง
- ขาดเรื่องของชุดการทดสอบ ทำให้หาจุดที่ผิดพลาดได้ยาก และ ใช้เวลานาน
- เอกสารที่แย่ๆ ไม่เปลี่ยนแปลงไปตามการทำงานของระบบ
- การทำงานร่วมกันของส่วนต่างๆ ไม่ดี
- ทำงานมากกว่า 1 งาน ในเวลาพร้อมๆ กัน
- ทำการ Refactoring ระบบทีหลัง หรือช้าไป
- ขาดเรื่องความรู้ในเรื่องของการพัฒนา บางที่อาจจะไม่รู้ตัวเองด้วยซ้ำว่า ไม่รู้
คำพูดที่มักจะก่อให้เกิด Technical Debt
- ทำให้มันเสร็จๆ ไปก่อน
- ไม่ต้องทำ test ก็ได้
- เดี๋ยวค่อยทำ …
- เวลามีน้อย
- งานมันเร่ง
- คนมันน้อย
หนี้ต่างๆ เหล่านี้ มันมีดอกเบี้ยด้วย
ดังนั้น ยิ่งนานไปมันจะยิ่งเพิ่มขึ้นแบบเท่าทวีคูณ
มีคำพูดที่น่าสนใจเกี่ยวกับ Technical Debt เช่น
Ward Cunningham กล่าวไว้ว่า
Shipping first time code is like going into debt.
A little debt speeds development so long as it is paid back promptly with a rewrite.
The danger occurs when the debt is not repaid.
Every minute spent on not-quite-right code counts as interest on that debt.
Dan Rawsthorne กล่าวไว้ว่า
High amount of Technical Debt is #1 impediment to team s being Agile
Aaron Erickson กล่าวไว้ว่า
Most companies have to spend 80% of their software development budget maintaining code
ดังนั้นมาถึงตรงนี้แล้ว Technical Dept ไม่น่าจะเป็นเรื่องที่ดีนะ !!!
แต่ทำไมเรามักยอมให้เกิดขึ้นเสมอล่ะ …
มี 2 เส้นทางให้เลือก อยู่ที่ตัวคุณเองนะ !!!
1. Clean and Smarter way
ใช้เวลาในการสร้างนานขึ้นมากว่าเดิม แต่มันง่ายต่อการเปลี่ยนแปลงในอนาคต
สามารถแสดงด้วยสภาพห้องครัวที่ทำความสะอาดและจัดระเบียบอยู่เสมอ ดังรูป
2. Quick and Dirty way
ใช้เวลาในการสร้างแต่ละ feature ให้เร็วที่สุด แต่ยากต่อการเปลี่ยนแปลงในอนาคต
เหมือนกับการทำอาหารที่ไม่เคยล้างทำความสะอาดเลย คอยทำความสะอาดหลังจากที่ทำอาหารเสร็จแล้ว
ซึ่งยิ่งนานวัน ยิ่งทำความสะอาดยากขึ้นเท่านั้น แสดงดังรูป
กลับมาดู Technical Debt ในการพัฒนา software
สามารถแยกกลุ่มของ TEchnical Debt เป็น 2 กลุ่มใหญ่ๆ ก็คือ
- สามารถมองเห็นได้
- ไม่สามารถมองเห็น
สามารถอธิบายได้ด้วยรูปภาพดังต่อไปนี้
อาการของ Technical Debt เป็นอย่างไร
- ทำให้ productivity ตกลง
- เพิ่มเวลาการทดสอบ
- โรคเลื่อนรับประทาน
- มี code ซ้ำๆ จำนวนมาก
- ค่าของ Code coverage ต่ำ
- จำนวน bug ที่เพิ่มขึ้น
- Code อ่านยากขึ้น
- ความเร็วของการทำงานและระบบงานลดลงไป
- มีการใช้งาน library เก่าๆ
- มีความกดดันจาก deadline
- กลัวการแก้ไขและเปลี่ยนแปลงสิ่งต่างๆ ในระบบงาน
- มักจะทำการ Hack ในสิ่งที่ทำ ซึ่งบ่งบอกถึงการออกแบบที่ผิด
- เลือกใช้ technology ที่ไม่เหมาะสมกับงาน
แล้วมุมมองของ Stakeholder ต่างๆ ล่ะ คิดอย่างไร
ลูกค้า
เจอความผิดพลาดมากๆ ความสามารถต่างๆ ของระบบขาดหายไป
เวลาการพัฒนาและแก้ไขยาวนาน แน่นอนว่าค่าใช้จ่ายก็สูงตามเป็นเงาตามตัว
แล้วลูกค้าจะพอใจหรือไม่ คิดดูเอาเอง
เมื่อมีปัญหาเข้ามามากๆ มักจะเกิด Problem department ขึ้นมา ซึ่งเพิ่มค่าใช้จ่ายเข้าไปอีก เช่น
- Helpdesk สำหรับช่วยเหลือหรือรับปัญหาต่างๆ จากผู้ใช้งาน
- Operation team สำหรับการแก้ไขข้อผิดพลาดต่างๆ
- Management จัดการกับบความผิดพลาดต่างๆ
ถ้าในมุมมองของ developer แล้ว
มีใครบ้างที่อยากจะสร้าง code ห่วยๆ ออกไป ?
มีใครบ้างที่อยากจะสร้าง code ห่วยๆ ซ้ำๆ ออกไป ?
ยังไม่พอ เมื่อไปค้นหาข้อมูลพบว่า
มีการสรุป ความผิดพลาดสุด classic 36 ข้อ ในการพัฒนา software
จากหนังสือ Rapid development :: Taming Wild Software Schedules
แล้วจะแก้ไขอย่างไรดีล่ะ ?
สามารถนำ engineering practice ต่างๆ มาใช้งาน เพื่อลดจำนวนของ Technical debt ลงไป
ยกตัวอย่างเช่น
- Pair programming
- Test-Drivent Development (TDD)
- Continuous Integration
- Automated Unit Testing
- Automated Functional Testing
- Automated Testing อื่นๆ เช่น Regression
- การทำ Refactoring
- แนวคิดของ Clean code
- ทำให้ Definition of Done มันชัดเจน ไม่คลุมเครือ
- Peer review
- Code Review
สามารถใช้เครื่องมือต่างๆ มาช่วยได้เช่น SonarQube สำหรับตรวจสอบคุณภาพของ code ในระบบต่างๆ ดังนี้
- หาส่วนที่อาจทำให้เกิดความผิดพลาด
- ตรวจสอบ Coding standard
- ตรวจสอบ code ที่ซ้ำๆ
- จำนวน Unit testing กับ code coverage
- ความซับซ้อนของ code
- การออกแบบ
- การ comment code ว่าเพียงพอหรือไม่
แนวทางการออกแบบระบบงาน ก็ช่วยลด Technical debt ได้เช่นกัน
เช่นการออกแบบต้องให้ความสำคัญทั้งทาง business และ architecture
ไม่เช่นนั้น จะเอนเอียงไปทางใดทางหนึ่งมากไป ก็จะทำให้เกิดปัญหาตามมา
รวมทั้งในเรื่อง time to market และการลด overhead ส่วนต่างๆลงไป
สุดท้ายแล้ว
มาถึงตรงนี้ คุณน่าจะเริ่มเข้าใจแล้วว่า Technical Debt
นั้นส่งผลต่อคุณ ต่อทีม ต่อ business และ stakeholder อย่างไร
น่าจะช่วยทำให้การตัดสินใจทำอะไรดีขึ้นกว่าเดิมนะครับ
Reference Website
Technical Debt
Technical Debt Clock
Technical Debt Infographic
Slide :: Technical Debt Do Not Underestimate the Danger
