“Technical Debt” คืออะไร
“Technical Debt” ถ้าแปลตรงตัวก็คือ “หนี้ทางเทคนิค” โดยถูกใช้ครั้งแรกจากลุง Ward Cunningham ในขณะที่ลุงทำ Software ทางด้านการเงิน ชื่อ WyCash แล้วลุงต้องการสื่อสารให้เจ้านายที่รู้เรื่องทางด้านการเงินเข้าใจว่า ถ้าไม่แก้ปัญหาทางด้านเทคนิคหรือไม่ทำมันให้ดี แล้วปล่อยมันทิ้งไว้ ก็อุปมาเหมือนเป็นหนี้สะสมไปเรื่อยๆ แถมยังต้องชดใช้ดอกเบี้ยในอนาคตด้วยอีกนะ!
แกเป็น 1 ใน 17 ที่แถลงการ Agile Manifesto, เป็นหนึ่งในผู้คิด Design Pattern และ Extreme Programming
ดังนั้นถ้าถามว่า “หนี้ทางเทคนิค” (Technical Debt) คืออะไร คือเป็นคำอุปมาที่เทียบกับ “หนี้ทางการเงิน” (Monetary Debt) นั่นเอง
ลองเทียบตัวอย่างง่ายๆ ถ้า ด้านซ้ายคือเรื่องทางเทคนิค และ ด้านขวาเรื่องการเงิน
- การไม่ออกแบบหรือละเลยคุณภาพของงาน = การกู้เงิน
- การ Refactoring Code = การคืนเงินต้น
- การพัฒนางานได้ช้าลง ด้วยความซับซ้อนที่มากขึ้น = การจ่ายดอกเบี้ยที่จะมีมากขึ้นเรื่อยๆ
ดูแล้ว “Technical Debt” จะเป็นสิ่งที่ไม่ดีต่างๆ ในด้านเทคนิค ทั้งนี้เกิดได้จากหลายปัจจัย เช่น การออกแบบระบบที่ไม่ดี การเขียนโค้ดที่ไม่ดี เป็นต้น
พอเกิดหนี้แล้ว ยังต้องมาใช้ดอกเบี้ยตามทีหลัง เช่น ต้องใช้เวลาเพื่อแกะโค้ดแก้ไขหรือเพิ่มฟีเจอร์ใหม่ ไปจนถึงเรื่องการใช้เงินหรือคนมากขึ้นเพื่อปรับปรุงโค้ดเก่าให้มันดี
“Debt” เกิดได้ทุกที่ ไม่เฉพาะ “Technical” เท่านั้น
เมื่อเริ่มทำโปรเจ็ค สิ่งที่เรียกว่า “Debt” หรือ “หนี้” ก็จะเริ่มเกิดขึ้นทันที เหมือนที่ลุง Ward Cunningham ได้บอกไว้เมื่อปี 1992 ว่า
“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. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.”
การส่งมอบโค้ดออกไปครั้งแรกก็เปรียบเหมือนการเริ่มสร้างหนี้แล้ว ..
แต่ทั้งนี้ก็ได้มีการไปขยายความเพิ่มเติมขึ้นว่า “หนี้” ไม่เฉพาะกับโค้ดเท่านั้น แต่มันคือจุดไหนก็ได้ที่ทำให้เกิดผลกระทบไม่ดีต่องาน เช่น
- Architecture Debt (หนี้ทางสถาปัตยกรรม) – การใช้สถาปัตยกรรมที่ไม่มีคุณภาพ หรือไม่เหมาะสมกับตัวงาน
- Design Debt (หนี้ทางการออกแบบ) – การละเลยที่จะทำตามหลักการ การออกแบบซอร์ฟแวร์ต่างๆ
- Code Debt (หนี้ทางโค้ด) – โค้ดที่เขียนไม่ดี ซับซ้อน อ่านยากง
- Test Automation Debt (หนี้ทางการทดสอบอัตโนมัติ) – ไม่ทำ Automate Test เพื่อรองรับการส่งมอบงานให้ไว
- Maintenance Debt (หนี้ทางด้านบำรุงรักษา) – มีการปรับปรุงซอร์ฟแวร์ล่าช้า
- Defect Debt (หนี้ทาง Defect) – รู้ว่ามีข้อบกพร่องของซอร์ฟแวร์ตรงไหน แต่ไม่แก้ไข
- Documentation Debt (หนี้ทางเอกสาร) – ลืมทำเอกสาร ทำแล้วไม่พอใช้ ทำไม่เสร็จ
- People Debt (หนี้ทางบุคคล) – คนที่มาชะลอหรือขัดขวางการพัฒนาของงาน
Reference: Southern Methodist University
จะรู้ได้อย่างไรว่าเรากำลังเป็น “หนี้ทางเทคนิค” (Technical Debt)
ถ้าอยากลองสังเกตว่าทีมหรือในบริษัทของเรา มีอาการเป็นหนี้ทางเทคนิคหรือไม่ ลองดูได้ เช่น
- Productivity ลดลง, ขาดแรงจูงใจ
- ใช้เวลาทดสอบระบบเยอะขึ้นเรื่อยๆ (เพราะเป็น manual test นี่นะ)
- ส่งมอบงานได้ช้า
- มีโค้ดซ้ำกันหลายๆ จุด
- ไม่รู้ว่าซอร์ฟแวร์ทำงานอย่างไร
- มี Code Coverage ต่ำ
- มีบั๊กเพิ่มขึ้นเรื่อยๆ
- คนทำงานจะเครียดและกดดัน เมื่อใกล้ถึงเวลาส่งมอบงาน
- คนกลัวที่จะแก้ไขโค้ด
- ทำการ Hack ระบบตัวเอง เพราะออกแบบผิดพลาด และไม่อยากแก้ไข
- เลือกใช้เทคโนโลยีไม่เหมาะสมกับงาน
- โค้ดอ่านไม่รู้เรื่อง
- ความเร็วในการทำงานของคนหรือทีมลดลง
- ใช้ Library หรือเทคโนโลยีเก่า
หากเจอตามข้อต่างๆเหล่านี้ ต้องลองหาทางปรับปรุงดูครับ เพื่อไม่ให้เกิดหนี้สะสม และดอกเบี้ยในอนาคต
สาเหตุของการทำให้เกิด “หนี้ทางเทคนิค” (Technical Debt)
หนี้ต่างๆ เกิดขึ้นได้จากหลายสาเหตุ ตั้งแต่เริ่มโปรเจ็ค ขณะทำ หรือแม้แต่โปรเจ็คจบแล้ว และต้องดูแลต่อ เช่น
- การขาดกระบวนการทำงาน ต่างคนต่างทำ
- ไม่วางแผนการทำงานก่อน
- แรงกดดันทางธุรกิจ
- ไม่เข้าใจและขาดเครื่องมือสำหรับ Test
- ไม่ทำ Refactoring Code หรือทิ้งแย่ๆไว้นานๆ
- ไม่ทำตามมาตรฐาน
- ขาดเอกสารที่เหมาะสม เช่น คู่มือใช้งาน, สเป็กระบบ ฯลฯ
- ขาดความร่วมมือการทำงาน
- ทีมไม่มีความเข้าใจในสิ่งที่จะทำ
- ทีมขาดความรู้ในเทคโนโลยีที่จะใช้
- ทีมไม่มีความรู้สึกเป็นเจ้าข้าวเจ้าของ
ผลกระทบ เมื่อเกิด “หนี้ทางเทคนิค” (Technical Debt)
หรือจะเรียกว่ามันเป็น “ดอกเบี้ย” (Interest) ก็ได้ เพราะแม้ว่าจะชดใช้เงินต้นคืนไปบ้างแล้ว เช่น Refactoring Code ทำตาม Standard หรืออื่นๆ แต่ยังคงมีผลกระทบทางอ้อมอยู่ ไม่ว่าจะเป็นเรื่องของ คน, เงิน, เวลา, ความเสี่ยงต่อธุรกิจ, ความเสี่ยงต่อความปลอดภัยของระบบ, ขวัญกำลังใจของคนตกลงเรื่อยๆ, ลูกค้าไม่พอใจ เป็นต้น
Reference: Southern Methodist University
แล้วจะลด “หนี้ทางเทคนิค” (Technical Debt) ได้อย่างไร
วิธีการลดหนี้ หรือป้องกันหนี้ทางเทคนิค สามารถทำได้หลายวิธี
อย่าก่อหนี้
- ไปหาความรู้และนำ engineering practice ต่างๆ มาใช้ เช่น
- Clean Code
- Pair programming
- นำ Test-Drivent Development (TDD) มาใช้
- ทำ Unit Testing และ Code Coverage
- Refactoring Code สม่ำเสมอ
- การจัดการกระบวนการทำงาน เช่น
- มี Review Code
- วางแผนก่อนทำงานร่วมกัน
- ออกแบบสถาปัตยกรรมก่อนทำงาน
- เลือกใช้ Technology ให้เหมาะสม
แล้วถ้าเป็นหนี้ จะทำอย่างไร?
- หาจุดที่แย่ (หนี้) ให้เจอซะก่อน เช่น ใช้ซอร์ฟแวร์ SonarQube ตรวจสอบคุณภาพโค้ด
- หาความรู้และนำ Engineering Practice ต่างๆ มาใช้
- ให้เวลากับมัน ค่อยๆ ปรับปรุงโค้ดแย่ๆ (ลดหนี้) ไปเรื่อยๆ
- ถ้าเจอโค้ดแย่ๆ ให้ปรับปรุงทันที
- จัดลำดับการปรับปรุงโค้ด ว่าอะไรสำคัญ ต้องทำก่อน-หลัง
- ทำ Automate Testing
สรุป
หลังจากรู้จัก Technical Debt กันแล้ว รู้ว่ามันเป็นผลเสียมากกว่าผลดี ดังนั้น ทางเลือกก็มีแค่ 2 ทาง คือ จะยอมใช้เวลาเพื่อทำของให้มันดี หรือ จะรีบร้อนแล้วได้ของไม่ดีกลับไป ข้อนี้เป็นหน้าที่ของทีม ที่จะต้องทำและป้องกันอย่าให้เกิด และจะต้องไปขายไอเดียให้กับผู้หลักผู้ใหญ่ต่อไป ว่าทำไม เราไม่ควรเป็นหนี้…
Reference
- Ward Cunningham – https://en.wikipedia.org/wiki/Ward_Cunningham
- http://wiki.c2.com/?ComplexityAsDebt
- https://www.agilealliance.org/introduction-to-the-technical-debt-concept/
- https://en.wikipedia.org/wiki/Technical_debt
- http://slideplayer.com/slide/9275126/
- https://www.slideshare.net/slideshare4tushar/technical-debt-info-graphic
- http://www.slideshare.net/lemiorhan/technical-debt-do-not-underestimate-the-danger
- http://www.somkiat.cc/technical-debt/
- header image – https://www.illinoispolicy.org/chicagos-63-billion-debt-burden/