如何把技術債給量化出來
四個指標協助建立技術債狀況
前言
在當今快速發展的軟體行業中，技術債（Technical Debt）是一個任何軟體團隊都要面對的問題。為了有效管理技術債，我們最直接的想法就是參考各種指標（Metrics）來量化目前的技術債狀況。指標是有目標性的、能揭露趨勢並提升可預測性的工具，但也要注意它們可能帶來的困惑、誤導和時間浪費。
為了使指標有效且實用，我們應該確保它們在衡量技術債的過程是恆定的，並且因為恆定且重複，我們可以考慮進行自動化，並且這些執行結果是可以被看見的。前面提到的指標可靠且可行也是一個關鍵。這些特性確保我們不會重複無謂的工作，也不會因混亂的 KPI 而分心。把這些指標作為參考，我們可以更好地理解和管理我們的技術債。
時間指標
在量化技術債時，時間指標是一個重要的考量點。這包括我們預計要花費多少時間以及實際上花費了多少時間。速度（Velocity），即工作量除以時間，是衡量這一點的一個常用指標。
程式碼指標
程式碼指標也是衡量技術債的重要工具。程式碼行數（Lines of Code）是一個常見但有爭議的指標。雖然它易於記憶和計算，但並不是一個好的生產力或功能性的衡量標準。然而，在評估技術債的情況下，程式碼行數可能是一個有用的參考，因為通常程式碼的量越大，可能出現的問題也越多。此外，method 和 class 的大小，以及循環的複雜性（Cyclomatic Complexity），即一個函數中循環的數量，也是重要的程式碼指標。它們可以幫助我們識別難以維護和測試的程式碼部分。
Source code 指標
現在我們的軟體產品或專案通常都會運用 git 進行管理，程式碼變更率（Code Churn）可以顯示哪些文件經常被修改，以及哪些文件自建利以來一直在不斷變化。
這些指標可以幫助我們監控，或是提示我們存在一個檔案被過度編輯，或同時過多貢獻者的問題，這可能ㄧ標誌出僅一個功能的責任過於分散，需要多人來進行維護，或或是程式碼的彈性過低導致一直被參照及修改。
測試指標
自動化測試數量、手動測試數量和程式碼的覆蓋率，也是衡量技術債的關鍵。
程式碼的覆蓋率，即被測試覆蓋的程式碼行數除以總程式碼行數，是評估測試品質的一個重要指標。此外，記錄 bug 的資料庫，可以幫助我們跟蹤和分析程式碼中的問題。
總結
透過意義的指標系統，我們可以更好的量化技術債。雖然這篇文章所提供的指標只有四個，範圍最多涵蓋開發跟測試而已，但我想以多數團隊來說是足夠的。
