發(fā)行軟件就像抵押。您要保持不變的債務(wù)，必須在測試，維護(hù)和代碼行中償還債務(wù)。如果您無法繼續(xù)支付，您可能會失去全部。

技術(shù)債務(wù)的隱喻越來越受到關(guān)注。最初，沃德·坎寧安（Ward Cunningham）在1992年首次使用該詞，其描述如下：“首次交付代碼就像負(fù)債累累。只要通過重寫及時償還債務(wù)，債務(wù)就可以加快發(fā)展速度。如果不償還債務(wù)，就會發(fā)生危險。花在不完全正確的代碼上的每一分鐘都算作該債務(wù)的利息。整個工程組織可能會因為未合并的實施，面向?qū)ο蠡蚱渌虻膫鶆?wù)負(fù)擔(dān)而停滯不前。”

有趣的是，許多敏捷開發(fā)方法的發(fā)起者現(xiàn)在都認(rèn)為對技術(shù)債務(wù)的持續(xù)管理對于開發(fā)高質(zhì)量和可維護(hù)的軟件至關(guān)重要。

這挑戰(zhàn)了開發(fā)決策幾乎應(yīng)完全由業(yè)務(wù)價值驅(qū)動的想法，因為很難評估償還技術(shù)債務(wù)或?qū)r間投入到可靠的軟件體系結(jié)構(gòu)中的價值。在我看來，管理技術(shù)債務(wù)和扎實的架構(gòu)基礎(chǔ)的價值與項目規(guī)模的線性增長相比，增長的幅度更大。

如果您的項目只有幾千行代碼，而團(tuán)隊只有2到3個人，則通過連續(xù)重構(gòu)按需添加體系結(jié)構(gòu)相對容易。但是，一旦我們擁有成千上萬的代碼行，不斷開發(fā)新功能以及擴(kuò)大團(tuán)隊規(guī)模，事情就會變得復(fù)雜得多。在這種情況下，如本研究報告中所述，技術(shù)債務(wù)的管理和對堅實的建筑基礎(chǔ)的投資將帶來巨大的收益。

問題是如何衡量技術(shù)債務(wù)并關(guān)注正確類型的技術(shù)債務(wù)。我將首先討論技術(shù)債務(wù)的衡量，然后深入探討技術(shù)債務(wù)的不同類別及其對項目成果的影響。

衡量技術(shù)債務(wù)

要衡量技術(shù)債務(wù)，我們需要一個更精確的定義。您如何用更多技術(shù)術(shù)語來定義“不太正確”？好吧，您可以根據(jù)編程規(guī)則，體系結(jié)構(gòu)規(guī)則和其他規(guī)則定義“正確”。然后，您可以計算違反規(guī)則的次數(shù)，以估算出軟件系統(tǒng)中技術(shù)債務(wù)的金額。該技術(shù)債券插件的 SonarQube使用的正是這種做法拿出的金額為系統(tǒng)中的技術(shù)債務(wù)。

不幸的是，細(xì)節(jié)在于魔鬼。您如何權(quán)衡各種違規(guī)行為？您的費用依據(jù)是什么？首先檢查哪些規(guī)則？這些規(guī)則真的相關(guān)嗎？如果使用默認(rèn)配置，則會發(fā)現(xiàn)許多內(nèi)置規(guī)則并不完全相關(guān)，因為它們對軟件質(zhì)量或可維護(hù)性缺乏可測量的影響。

另一方面，通常根本不考慮重要因素，例如系統(tǒng)與體系結(jié)構(gòu)藍(lán)圖的一致性，耦合度量和結(jié)構(gòu)健全性。這意味著您可能正在尋找誤導(dǎo)性的數(shù)字，并花費大量精力解決不相關(guān)的問題。

因此，重要的是要拿出自己的規(guī)則集并相應(yīng)地配置測量平臺。經(jīng)驗法則是少即是多。從一些有意義的規(guī)則開始，然后如果發(fā)現(xiàn)規(guī)則沒有檢測到重要的缺陷，則隨著時間的推移擴(kuò)展您的規(guī)則集。要確定某個規(guī)則是否將其納入您的規(guī)則集中，請始終問自己，違反此特定規(guī)則將對系統(tǒng)的質(zhì)量和可維護(hù)性產(chǎn)生多大影響，以及在以后解決違反問題的難度如何。

顯然，我們應(yīng)該關(guān)注具有相對較高影響力和/或較高維修成本的規(guī)則。在本文的結(jié)尾，我們將介紹一個示例規(guī)則集，該規(guī)則集在我自己的公司和許多客戶中都非常有效。

技術(shù)債務(wù)類別

對規(guī)則進(jìn)行分類很有意義，這樣可以更輕松地查看全局，而不會迷失在非常具體的技術(shù)規(guī)則的細(xì)節(jié)中。以下是一些明顯的規(guī)則類別：

• 本地編程規(guī)則，例如“無空catch語句”等

• 基于自動測試和測試范圍的規(guī)則

• 基于軟件指標(biāo)（即指標(biāo)閾值）的規(guī)則

• 基于架構(gòu)和依賴結(jié)構(gòu)的規(guī)則

現(xiàn)在讓我們考慮這些類別對維修成本的總體影響以及對可見質(zhì)量和代碼可維護(hù)性的影響。術(shù)語“可見（質(zhì)量）影響”用于描述軟件系統(tǒng)用戶可直接檢測到的事物，即錯誤和不良程序行為。術(shù)語“可維護(hù)性”用于涵蓋代碼可理解性和代碼可更改性等方面，即對更改成本的影響。

在測試和測試范圍方面，如果必須在開發(fā)后創(chuàng)建測試，則維修成本可能會很高。理想情況下，將創(chuàng)建自動測試以及應(yīng)該測試的代碼。對可見質(zhì)量的影響也很大，因為缺少測試會增加可見錯誤的可能性。另一方面，缺少測試對可維護(hù)性沒有很大的影響–除了良好的測試覆蓋范圍使全局重構(gòu)變得更加容易之外。違反編程規(guī)則的問題很容易修復(fù)，因為修復(fù)程序通常只需要更改單個文件即可。有時違反編程規(guī)則也會導(dǎo)致可見錯誤，因此我將對可見質(zhì)量的影響分類為中等?？梢院雎钥删S護(hù)性影響，因為違反本地編程規(guī)則不會影響整體代碼可維護(hù)性。

基于度量的規(guī)則通常具有較低的修復(fù)成本，但涵蓋全局方面的度量（例如系統(tǒng)內(nèi)的整體耦合）除外。流氓指標(biāo)值也很少會產(chǎn)生可見的問題，但是對可維護(hù)性肯定會有很大影響。

我們的最后一類涉及架構(gòu)和依賴項結(jié)構(gòu)。對于度量標(biāo)準(zhǔn)，很容易看出，不良或丟失的體系結(jié)構(gòu)不一定會造成明顯的問題，因此對可見質(zhì)量的影響非常低。但是事后修復(fù)損壞的架構(gòu)或添加架構(gòu)非常困難且昂貴。更改沒有清晰體系結(jié)構(gòu)的系統(tǒng)也非常困難。此類別下的所有技術(shù)債務(wù)也稱為建筑債務(wù)。

毫不奇怪，大多數(shù)嘗試跟蹤其技術(shù)債務(wù)的人都將注意力集中在具有明顯可見影響的規(guī)則類別上。但是，當(dāng)直接問到這四個類別中的哪一個對項目的生命周期成本影響最大時，大多數(shù)人憑直覺就同意這將是“架構(gòu)和依賴關(guān)系結(jié)構(gòu)”。彌合這種明顯的差距將提供非常好的投資回報。

結(jié)論是，這可能不是以相同方式處理所有技術(shù)債務(wù)的最佳方法。根據(jù)您的戰(zhàn)略目標(biāo)確定規(guī)則的優(yōu)先級很重要。對于較小的項目，僅關(guān)注影響可見質(zhì)量的事物才有意義。您的項目規(guī)模越大，壽命就越長，建筑債務(wù)的毒性就越大。因此，大型項目應(yīng)重點關(guān)注控制建筑債務(wù)。

管理技術(shù)債務(wù)

既然您實際上可以量化技術(shù)債務(wù)，則可以就何時累積債務(wù)以及何時還清債務(wù)做出明智的決定。積累技術(shù)債務(wù)以應(yīng)付由重要業(yè)務(wù)限制所定義的關(guān)鍵期限是完全合理的。只需確保您確實制定了一項計劃，可以進(jìn)一步償還債務(wù)。

跟蹤技術(shù)債務(wù)的另一個好處是，您可以與利益相關(guān)者進(jìn)行更有意義的討論。如果他們知道過分地要求截止日期會自動導(dǎo)致更多債務(wù)的積累，那么就容易達(dá)成一致的平衡方法，該方法總是為代碼衛(wèi)生和體系結(jié)構(gòu)分配時間。

隨著時間的推移，我了解到，平均而言，您應(yīng)該在此領(lǐng)域中花費大約20％的總開發(fā)工作量，在項目的早期階段可能會花費更多，而在后期階段則可能會花費更少。從項目一開始就這樣做，將在項目的整個生命周期內(nèi)節(jié)省大量成本。

規(guī)則集示例

設(shè)計規(guī)則集時，您首先要確?？梢宰詣訖z查所有規(guī)則，理想情況下是在連續(xù)集成版本中進(jìn)行檢查，或者每天晚上至少進(jìn)行一次檢查。需要人工干預(yù)進(jìn)行檢查的規(guī)則不應(yīng)用于技術(shù)債務(wù)評估。因此，您將需要投資于工具和相關(guān)的基礎(chǔ)架構(gòu)。由于某些必需的工具是免費的，并且大多數(shù)敏捷團(tuán)隊都已經(jīng)擁有構(gòu)建服務(wù)器，因此這并不是一個大障礙，尤其是在考慮到潛在節(jié)省成本的情況下。

您的規(guī)則集還應(yīng)根據(jù)項目的規(guī)模反映出您的戰(zhàn)略重點。如上所述，較小的項目與較大的項目需要不同的優(yōu)先級。

此示例規(guī)則集適用于較大的Java項目，但可以輕松適用于其他語言。我們假設(shè)將SonarQube用作綜合性工具，以合并用于衡量技術(shù)債務(wù)的各種工具的結(jié)果。在每條規(guī)則的后面，我們列出了實現(xiàn)該特定規(guī)則的潛在工具：

1. 定義一個架構(gòu)藍(lán)圖，并確保代碼能夠反映該藍(lán)圖（Sonargraph，Structure101）

2. 避免包之間的循環(huán)依賴關(guān)系（Sonargraph，Structure101，SonarQube）

3. 測試覆蓋率應(yīng)高于50％（SonarQube與Cobertura或Emma）

4. 保持較低的整體耦合（示例度量：平均組件相關(guān)性低于70）（聲納圖）

5. SonarQube中沒有嚴(yán)重或阻止違反的行為（帶有FindBugs，CheckStyle和PMD的SonarQube）

6. 重復(fù)的代碼行不應(yīng)超過代碼行的10％（SonarQube，Sonargraph）

7. 源文件的代碼行數(shù)不得超過700行（聲納圖）

8. 改良的McCabe環(huán)復(fù)雜度方法不應(yīng)高于15（聲納圖）

9. 包中最多不能包含50種類型（聲納圖）

規(guī)則1和2專注于體系結(jié)構(gòu)和依賴關(guān)系結(jié)構(gòu)。7、8和9中的度量標(biāo)準(zhǔn)閾值是軟閾值，即，如果有記錄的原因，可能會違反該閾值。對于規(guī)則5，花一些初始時間來配置CheckStyle，PMD和Cobertura的活動規(guī)則非常重要，這樣可以避免檢查規(guī)則而沒有太多實際意義。規(guī)則5可以視為元規(guī)則，因為它總結(jié)了類別1的所有小規(guī)則。根據(jù)您的配置，規(guī)則可能是幾十個，甚至數(shù)百個。

規(guī)則集在上述不同規(guī)則類別之間具有良好的平衡。在我的公司中，違反規(guī)則1和2將破壞構(gòu)建，而其他違反將創(chuàng)建警告。