技術(shù)債務(wù)指標(biāo)旨在幫助人們理解其收集的所有數(shù)據(jù)?，F(xiàn)在有許多不同的指標(biāo)可供選擇，并且有大量用于記錄數(shù)據(jù)的工具。
以下將介紹它們是如何工作的，并幫助企業(yè)為其業(yè)務(wù)選擇正確的指標(biāo)。
為什么技術(shù)債務(wù)對企業(yè)的業(yè)務(wù)至關(guān)重要
在深入了解細(xì)節(jié)之前，有必要先從整體的角度進(jìn)行了解。
技術(shù)債務(wù)或代碼債務(wù)是指代碼中的任何缺陷，這些缺陷必須隨著業(yè)務(wù)的增長而得到糾正。企業(yè)欠下的技術(shù)債務(wù)越多，那么在后期需要返工的工作就越多。
當(dāng)然，從頭開始重建關(guān)鍵系統(tǒng)的效率也很低下。除了在原始開發(fā)階段所做的任何投資之外，它還需要耗費(fèi)更多的時(shí)間和費(fèi)用。
解決技術(shù)債務(wù)問題也可能讓工程師士氣低落，并導(dǎo)致員工保留率下降。最終，用戶可能對企業(yè)的劣質(zhì)產(chǎn)品感到沮喪。
太多的技術(shù)債務(wù)是多少?
太多的技術(shù)債務(wù)聽起來很可怕。然而，技術(shù)債務(wù)并不一定代表是一場災(zāi)難。
就像人們的信用卡一樣，少量的技術(shù)債務(wù)是可以接受的。對于初創(chuàng)公司來說，這實(shí)際上是必不可少的一個(gè)舉措。企業(yè)有時(shí)需要推出最小可行性產(chǎn)品(MVP)或基本產(chǎn)品作為概念證明。這可以幫助企業(yè)籌集資金，用于償還技術(shù)債務(wù)。
但是，如果企業(yè)的債務(wù)堆積如山，那么最終可能會(huì)導(dǎo)致工程團(tuán)隊(duì)面臨巨額的賬單。
當(dāng)前主流的支付處理器Stripe平臺(tái)實(shí)際上開始量化技術(shù)債務(wù)的成本。研究發(fā)現(xiàn)，工程師平均花費(fèi)33%的時(shí)間來處理技術(shù)債務(wù)。在全球范圍內(nèi)，這對全球GDP帶來了巨大的影響。
衡量技術(shù)債務(wù)的8個(gè)指標(biāo)
技術(shù)債務(wù)如此普遍的主要原因是許多企業(yè)甚至沒有意識(shí)到他們擁有多少技術(shù)債務(wù)。只有當(dāng)企業(yè)想要添加新功能時(shí)，這個(gè)問題才會(huì)出現(xiàn)。
為確保不會(huì)落入同樣的陷阱，最好設(shè)置一些技術(shù)債務(wù)指標(biāo)。并沒有單一的數(shù)據(jù)點(diǎn)可以讓企業(yè)準(zhǔn)確了解其技術(shù)債務(wù)。與其相反，將需要使用一組指標(biāo)來了解。
那么，應(yīng)該優(yōu)先考慮哪些指標(biāo)?
(1)新錯(cuò)誤與已關(guān)閉的錯(cuò)誤
這里有一個(gè)簡單的開始。每個(gè)已知的錯(cuò)誤(Bug)本質(zhì)上都是一小部分技術(shù)債務(wù)。如果企業(yè)想知道其總體債務(wù)，那么讓工程師進(jìn)行統(tǒng)計(jì)很重要。
假設(shè)工程師對何時(shí)修復(fù)錯(cuò)誤進(jìn)行了記錄，可以計(jì)算出管理技術(shù)債務(wù)的效率。如果新錯(cuò)誤的數(shù)量超過已關(guān)閉的錯(cuò)誤，則需要進(jìn)行一些更改。
(2)債務(wù)指數(shù)
債務(wù)指數(shù)基于已解決的問題與總體問題數(shù)量的比率，其中優(yōu)先級(jí)較高的問題更為重要。
如果企業(yè)的工程團(tuán)隊(duì)定期跟蹤代碼庫問題并確定其優(yōu)先級(jí)，企業(yè)可以輕松查看有多少已解決和未解決的問題?？梢栽趩栴}跟蹤器中跟蹤它，最簡單的方法是使用Stepsize VSCode或JetBrains編輯器擴(kuò)展，它們允許直接從編輯器跟蹤代碼庫問題并確定其優(yōu)先級(jí)。此外，還可以在儀表板上看到進(jìn)度，這將激勵(lì)團(tuán)隊(duì)解決更多的技術(shù)債務(wù)。
(3)代碼質(zhì)量
復(fù)雜的代碼是技術(shù)債務(wù)不斷增長的明確標(biāo)志。在某些時(shí)候，將不得不清理這個(gè)爛攤子。代碼質(zhì)量是量化代碼整體質(zhì)量和復(fù)雜性的幾個(gè)指標(biāo)的集合：
•圈復(fù)雜度
•類耦合
•代碼行
•繼承深度
對于這些單獨(dú)的指標(biāo)中的每一個(gè)指標(biāo)，企業(yè)的目標(biāo)使其分?jǐn)?shù)盡可能低。代碼質(zhì)量的整體指標(biāo)也是如此。
(4)周期時(shí)間
與代碼質(zhì)量密切相關(guān)的另一個(gè)指標(biāo)是周期時(shí)間。
用技術(shù)術(shù)語來說，這衡量了首次提交到部署過程的時(shí)間。但是，當(dāng)衡量技術(shù)債務(wù)時(shí)，需要研究對現(xiàn)有代碼進(jìn)行更改，以及在不使用快速修復(fù)的情況下解決問題所需的時(shí)間。
如果企業(yè)的工程師花費(fèi)一些時(shí)間修復(fù)一些小錯(cuò)誤，就會(huì)知道代碼中潛伏著一些技術(shù)債務(wù)。
(5)代碼流失
代碼流失是一種衡量特定行代碼被刪除、替換或重寫次數(shù)的指標(biāo)。
當(dāng)企業(yè)開發(fā)新功能或處理產(chǎn)品的特定部分時(shí)，不可避免地會(huì)出現(xiàn)一些流失。但是在發(fā)布了一個(gè)新版本并修復(fù)了突出的錯(cuò)誤之后，代碼流失應(yīng)該會(huì)開始迅速減少。
如果在較長時(shí)間內(nèi)看到代碼的任何區(qū)域出現(xiàn)高流失率，則可能意味著每次迭代都會(huì)出現(xiàn)錯(cuò)誤或快速修復(fù)。
(6)代碼覆蓋率
從某種意義上說，衡量代碼覆蓋率是從相反的方向看同一個(gè)問題。
在這種情況下，正在測量運(yùn)行測試套件時(shí)執(zhí)行了多少代碼。這可以讓人們了解編寫代碼的效率——未使用的行越多，代碼編寫得越差。
一個(gè)理想的目標(biāo)數(shù)字是80%。高于這個(gè)數(shù)值值得贊揚(yáng)，而如果數(shù)值較低表示需要完成一些工作。
(7)代碼所有權(quán)
俗話說，“三個(gè)和尚沒水喝”。同樣的想法也可以應(yīng)用于軟件工程。如果讓太多人從事相同的任務(wù)，則很容易以失敗告終。但企業(yè)并不希望某人擁有整個(gè)項(xiàng)目的所有權(quán)。如果他生病或離職，那么項(xiàng)目進(jìn)度將會(huì)受到影響。
出于這個(gè)原因，分析誰參與了哪些項(xiàng)目是一個(gè)好主意。作為流程的一部分，應(yīng)該了解哪些工程師為每個(gè)項(xiàng)目做出了貢獻(xiàn)——這是代碼覆蓋率。
平均數(shù)字將顯示企業(yè)是否有一個(gè)高效的任務(wù)分配系統(tǒng)，還是一個(gè)免費(fèi)的系統(tǒng)。其理想的情況是由一個(gè)完整的團(tuán)隊(duì)負(fù)責(zé)每個(gè)項(xiàng)目。
(8)技術(shù)負(fù)債率(TDR)
顧名思義，這個(gè)指標(biāo)是專門為計(jì)算未來技術(shù)債務(wù)的總體成本而設(shè)計(jì)的。這可以是時(shí)間或其他一些資源。
其計(jì)算方式比較簡單：(修復(fù)成本÷開發(fā)成本)×100=TDR
在這種情況下，可以根據(jù)上述代碼質(zhì)量指標(biāo)計(jì)算修復(fù)成本。
開發(fā)成本是構(gòu)建產(chǎn)品或功能所需的代碼行數(shù)除以每行平均資源消耗的簡單計(jì)算。將兩者放在TDR方程中，最終會(huì)得到一個(gè)簡單的比率，它告訴需要花費(fèi)多少時(shí)間或多少資源來解決問題。在理想情況下的TDR約為5%。如果達(dá)到這個(gè)數(shù)字的倍數(shù)，那么現(xiàn)在就是企業(yè)開始解決技術(shù)債務(wù)的時(shí)候了!
前端的響應(yīng)能力并非嚴(yán)格意義上的技術(shù)債務(wù)。但是該指標(biāo)可以起到警示作用。如果前端加載時(shí)間較長，一般是因?yàn)榇a過于復(fù)雜或技術(shù)過時(shí)。兩者都是技術(shù)債務(wù)的重要形式。
衡量技術(shù)債務(wù)的最佳工具
到現(xiàn)在為止，人們應(yīng)該了解需要衡量什么指標(biāo)來管理其技術(shù)債務(wù)。剩下的就是決定使用哪些工具來完成任務(wù)。
以下是一些適合大多數(shù)項(xiàng)目的出色選項(xiàng)：
(1)Stepsize
Stepsize專為代碼庫問題跟蹤而設(shè)計(jì)，可以幫助企業(yè)在最喜歡的編輯器中識(shí)別和突出顯示問題。
Stepsize VSCode或JetBrains編輯器擴(kuò)展是完全免費(fèi)的，將幫助跟蹤技術(shù)債務(wù)并衡量進(jìn)度。由于Stepsize與Jira、Asana、Linear、Azure DevOps等集成，企業(yè)可以采用這一應(yīng)用程序而無需從根本上改變其工作流程。
•直接從編輯器創(chuàng)建和查看代碼問題。
•跟蹤代碼改進(jìn)并確定優(yōu)先級(jí)，例如技術(shù)債務(wù)。
•通過問題跟蹤器集成為其sprint添加關(guān)鍵問題。
(2)SonarQube
SonarQube并不是跟蹤技術(shù)債務(wù)的完整解決方案，而是一個(gè)關(guān)注范圍狹窄的工具。
該平臺(tái)的主要目的是衡量和提高代碼質(zhì)量。SonarQube通過自動(dòng)分析突出顯示錯(cuò)誤和雜亂的代碼，提供可以隨時(shí)間跟蹤的數(shù)字和等級(jí)。
(3)Teamscale
描述Teamscale的最佳方式是作為產(chǎn)品的系統(tǒng)分析器。該工具評估代碼的質(zhì)量，并通過可視化傳遞信息。
Teamscale可以處理多個(gè)指標(biāo)，并可選擇配置自定義儀表板。該平臺(tái)還提供了一些質(zhì)量管理功能，盡管它缺乏Stepsize提供的帶注釋的問題跟蹤和詳細(xì)的技術(shù)債務(wù)分析。
(4)Velocity by Code Climate
Velocity by Code Climate被稱為一種“工程智能”平臺(tái)，主要旨在幫助管理人員改進(jìn)工作流程和分配資源。它不是專門為處理技術(shù)債務(wù)而設(shè)計(jì)的，但有一些交集。
Velocity從Jira和其他DevOps工具中提取數(shù)據(jù)以提供見解。還可以運(yùn)行自動(dòng)代碼分析，并通過內(nèi)聯(lián)問題報(bào)告收集信息。
(5)Jira
衡量技術(shù)債務(wù)的一種方法是在選擇的項(xiàng)目管理工作流程中創(chuàng)建和監(jiān)控積壓工作。
如果這是想要采用的方法，那么Jira是一個(gè)明顯的選擇。它并不提供上述應(yīng)用程序的任何代碼分析功能，但卻是管理任務(wù)的好平臺(tái)。
結(jié)論
正如人們所發(fā)現(xiàn)的那樣，有許多不同的方法來衡量和管理技術(shù)債務(wù)。如果正在尋找多合一的解決方案，那么上述選項(xiàng)之一應(yīng)該在候選名單中。
需要記住的是，所有高增長的軟件開發(fā)商都會(huì)承擔(dān)一些技術(shù)債務(wù)。重要的是要對其進(jìn)行衡量，并不斷清理代碼，以使其業(yè)務(wù)保持增長。
版權(quán)聲明：本文為企業(yè)網(wǎng)D1Net編譯，轉(zhuǎn)載需注明出處為：企業(yè)網(wǎng)D1Net，如果不注明出處，企業(yè)網(wǎng)D1Net將保留追究其法律責(zé)任的權(quán)利。
京公網(wǎng)安備 11010502049343號(hào)