譯者 | 仇凱

審校 | 孫淑娟 梁策

技術債務就像持續(xù)上漲的信用卡賬單，非常容易失控。為了避免此類情況出現(xiàn)，你需要對積累的技術債務持續(xù)評估。

技術債務指標旨在幫助你了解所有收集到的數(shù)據(jù)?，F(xiàn)在有大量可以記錄數(shù)據(jù)的工具和指標可以供選擇。

在本文中，我們將了解它們的工作原理，并幫助你選擇合適的指標開展工作。

通過八個指標評估技術債務

技術債務非常普遍，主要原因是許多企業(yè)根本沒有意識到自己有多少技術債務。只有當企業(yè)想要添加新功能時，這些問題才會浮出水面。

為了避免陷入同樣的困境，你需要建立一些技術債務指標。

請注意，我們所說的指標是從多個維度建立的。沒有任何單一指標可以準確反映技術債務的現(xiàn)狀。因此，你需要通過一系列指標為技術債務構建畫像。

那么，哪些指標是優(yōu)先考慮項呢?下面將列舉常見的指標。

1. 新增Bug和修復Bug

這是非常簡單且友好的開始。

每個已知Bug本質(zhì)上都是小的技術債務。統(tǒng)計所有開發(fā)人員的已知Bug是非常重要的，它可以幫助你了解技術債務的總體狀況。

假設開發(fā)人員記錄了修復Bug的時間，你就可以計算出償還技術債務的效率。如果新增Bug的速度超過修復Bug的速度，那么你就需要進行調(diào)整。

2. 可維護指數(shù)

可維護指數(shù)是基于已解決問題數(shù)量與總問題數(shù)量的比率，其中問題的優(yōu)先級越高權重越大。

如果開發(fā)團隊定期跟蹤代碼庫問題，并確定其優(yōu)先級，那么你可以輕松確認有多少已解決和未解決的問題。你可以在問題跟蹤器中跟蹤問題，不過更好的方法是使用Stepsize VSCode或JetBrains的編輯器擴展工具，它們可以幫助你直接在編輯器中跟蹤代碼庫問題，并確定其優(yōu)先級。此外，你還能從儀表盤中看到問題的處理進度，這將激勵開發(fā)團隊解決更多的技術債務。

3. 代碼度量

復雜代碼是技術債務不斷增加的明顯標志。某種情況下，你將不得不處理這個爛攤子。

代碼度量是一些指標的集合，它包含代碼質(zhì)量和復雜度的全局量化：

圈復雜度、類耦合和繼承深度。

你需要盡可能的降低每一個獨立指標的分數(shù)。這同樣適用于代碼度量的整體指標。

4. 時間周期

另一個與代碼質(zhì)量密切相關的是時間周期。

用技術語言來說，這衡量了從第一次提交代碼到上線部署消耗的時間。但是，當你在評估技術債務時，你需要研究現(xiàn)有代碼進行修改的時間，以及在不使用快速修復情況下解決問題的時間。

如果開發(fā)人員花費數(shù)小時修復輕微Bug，那么你就要意識到代碼中潛伏著一些技術債務。

5. 代碼攪動

代碼攪動是衡量特定代碼被刪除、替換或重寫次數(shù)的指標。

當你開發(fā)新特性或處理產(chǎn)品的特定模塊時，代碼攪動的發(fā)生是不可避免的。但是，在你修復了突出問題并發(fā)布新版本之后，代碼攪動問題應該會迅速減少。

如果某些區(qū)域的代碼在很長一段時間內(nèi)高頻率發(fā)生代碼攪動情況，這通常表明每次迭代都引入新的錯誤或快速修復情況。

6. 代碼覆蓋率

某種意義上說，代碼覆蓋率是從相反方向分析同一個問題。

在這種情況下，當運行代碼測試任務時，你需要評估有多少代碼被執(zhí)行了。這可以幫助你了解自己的代碼編寫效率——未被執(zhí)行的代碼行越多，你編寫的代碼越差。

80%的代碼覆蓋率是很好的目標。高于這個值是非常優(yōu)秀的，而低于這個值則表示代碼還有優(yōu)化空間。

7. 代碼所有制

在烹飪界，大家常說：“人多誤事”。

這種說法在軟件工程領域同樣適用。如果許多人完成相同的任務，那么很容易因為產(chǎn)生大量無效代碼而告終。

盡管如此，你也不希望只有一個人承擔整個項目。如果他生病或離職，項目就完蛋了。

出于以上原因，需要分析哪些人參與了哪些項目。作為流程的一部分，你需要計算每個項目有多少開發(fā)人員參與貢獻——這就是你的代碼覆蓋率。

代碼覆蓋率的平均數(shù)據(jù)將揭示你是否建立有效的任務分配機制，或者僅僅是隨意分配。最理想的狀態(tài)是建立完整的團隊來負責每個項目。

8. 技術負債率(TDR)

顧名思義，這是專門評估未來技術債務總成本的指標。它可以是時間或其他資源。

計算方法很簡單：

(修復成本/開發(fā)成本)*100=技術負債率

在這個場景下，修復成本可以依據(jù)前文提到的代碼度量指標計算。

開發(fā)成本可以通過簡單的公式計算，這個公式是構建產(chǎn)品或功能所需代碼行數(shù)除以每行代碼執(zhí)行時的計算資源消耗量。

將兩者的數(shù)據(jù)結果代入技術負債率公式中，最終會得到一個簡單的比率，這個比率將揭示你需要投入多少時間或資源來解決問題。

在理想情況下，你的技術負債率約為5%。如果你的分數(shù)是該數(shù)值的很多倍，那么你的技術負債已早該處理了。

額外建議：前端響應時間

嚴格來說，前端響應能力與技術負債關聯(lián)性不大。然而，這個指標可以起到警示作用。

如果你的前端頁面加載時間過長，這通常代表它使用的技術老舊或代碼復雜。這兩者都是技術債務典型形式。

評估技術債務的最佳工具

希望到現(xiàn)在為止，關于如何開展技術債務的指標評估，你已經(jīng)開始有思路了。其余需要了解的就是使用哪些工具來完成任務。

以下是一些適合大多數(shù)項目的優(yōu)秀工具：

1. Stepsize

Stepsize是專門為代碼庫問題跟蹤而設計的，可以在你喜歡的編輯器中識別和高亮代碼問題。

Stepsize VSCode或JetBrains編輯器擴展工具是完全免費的，可以幫助你跟蹤技術債務并跟進處理進度。

由于Stepsize可以與Jira、Asana、Linear、Azure DevOps以及其他很多工具對接，你無需徹底改變自己的工作流程就可以使用此工具。

• 直接在編輯器中創(chuàng)建和查看代碼問題
• 跟蹤和改進優(yōu)先級高的代碼問題以償還技術債務
• 通過問題跟蹤器添加短期沖刺的關鍵問題

2. SonarQube

相較于跟蹤技術債務的完整解決方案，SonarQube是一個關注范圍狹窄的工具。

該平臺的主要目標是評估和提高代碼質(zhì)量。SonarQube通過自動分析高亮Bug和雜亂代碼，提供依據(jù)時間跟蹤的評分和優(yōu)先級。

3. Teamscale

描述Teamscale的最佳語言是它可以作為產(chǎn)品的系統(tǒng)分析器。該工具評估你的代碼質(zhì)量，并通過可視化方式提供相關信息。

通過配置自定義儀表盤，Teamscale可以處理很多指標。該平臺還提供一些質(zhì)量管理功能，盡管它欠缺注釋問題跟蹤和詳細的技術債務分析(Stepsize提供這些功能)，但它依然是優(yōu)秀的工具。

4. Velocity

Code Climate開發(fā)的Velocity被視為“工程智能”平臺，主要旨在協(xié)助管理人員改進工作流程和分配資源。它并不是專門用來處理技術債務的，但是其中有一些功能覆蓋。

Velocity通過從Jira和其他DevOps工具拉取數(shù)據(jù)來提供建議。你同樣可以用它來執(zhí)行自動代碼分析和收集內(nèi)部問題報告信息。

5. Jira

在你選擇的項目管理流程中創(chuàng)建和監(jiān)控積累的任務，也是評估技術債務的一種方法。

如果你想選擇這種方式來處理技術債務，那么Jira是明智的選擇。它并不提供任何代碼分析功能(前文提到的應用都提供此類功能)，但它是管理任務的優(yōu)秀平臺。

結論

正如我們所發(fā)現(xiàn)的，有很多不同的方式可以評估和管理技術債務。如果你在尋找一體化的解決方案，Stepsize必然在備選清單中。

我們的平臺對開發(fā)人員來說是直觀的，并且功能強大到足以為管理人員提供有價值的見解——通過儀表盤中展示的技術債務信息可以有效評估其對未來路線的影響。

請記住，所有高速增長的軟件公司都需要承擔技術債務。但是對技術債務進行評估并清理代碼是非常重要的，這也將使你的公司保持高速發(fā)展。

譯者介紹

仇凱，51CTO社區(qū)編輯，目前就職于北京宅急送快運股份有限公司，職位為信息安全工程師。主要負責公司信息安全規(guī)劃和建設(等保，ISO27001)，日常主要工作內(nèi)容為安全方案制定和落地、內(nèi)部安全審計和風險評估以及管理。

原文標題：How to Measure Your Technical Debt: 8 Metrics to Consider，作者：Alex Omeyer