in Get It

ว่าด้วยเรื่อง “หนี้ทางเทคนิค” (Technical Debt) ทำไมต้องใส่ใจ

“Technical Debt” คืออะไร

“Technical Debt” ถ้าแปลตรงตัวก็คือ “หนี้ทางเทคนิค” โดยถูกใช้ครั้งแรกจากลุง Ward Cunningham ในขณะที่ลุงทำ Software ทางด้านการเงิน ชื่อ WyCash แล้วลุงต้องการสื่อสารให้เจ้านายที่รู้เรื่องทางด้านการเงินเข้าใจว่า ถ้าไม่แก้ปัญหาทางด้านเทคนิคหรือไม่ทำมันให้ดี แล้วปล่อยมันทิ้งไว้ ก็อุปมาเหมือนเป็นหนี้สะสมไปเรื่อยๆ แถมยังต้องชดใช้ดอกเบี้ยในอนาคตด้วยอีกนะ!

ลุง Ward Cunningham ผู้ใช้คำว่า “Technical Debt” คนแรก
แกเป็น 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