軟體系統是容易的積聚一些累贅cruft  : 內部質量不高，導致其比預想更難進行修改和進一步擴充套件系統。技術債務是沃德坎寧安（Ward Cunningham）創造的一個比喻，它描述瞭如何考慮處理這種問題，將其視為金融債務，增加新功能所需的額外成本是債務利息。

想象一下，我的程式碼庫中有一個令人困惑的模組結構。我需要新增一個新功能。如果模組結構清晰，那麼我需要四天時間才能新增這個功能，但是這需要六天時間。兩天的差額就是你要付出的債務利息。

關於債務比喻最吸引我的是它如何促使我如何處理這個問題。我可能需要五天時間來清理模組化結構，移除那個殘骸，暗地了其實支付了利息。如果我只為這一個功能就進行重構，那就沒有多大收穫，因為我需要9天而不是6天。但是，如果我有兩個更相似的功能出現，那麼我將通過首先刪除累贅cruft來加快速度。

這樣說，這聽起來像是處理數字的簡單問題，任何有電子表格的經理都應該找出選擇。遺憾的是，由於我們保持了生產力，因此這些成本都不是客觀可衡量的。我們可以估計完成一個功能需要多長時間，估計如果移除這個功能可能會是什麼樣的，並 估計移除這個功能的成本。但這種估計的準確性非常低。

鑑於此，通常最好的方法是做我們通常做的金融債務，逐步還債。碰到第一個功能時，我將花費額外的幾天來刪除一些殘餘累贅。這可能足以將未來重構時間降低一天，重構仍然需要花費額外的時間，但是通過刪除這個問題我將使這個程式碼的未來更改變得更便宜。

像這樣逐步改進的巨大好處是，它自然意味著我們花費更多的時間來消除我們經常修改的那些區域中的累贅，這正是程式碼庫中我們最需要刪除的累贅部分。

將此視為支付利息與支付本金可以幫助決定解決哪個問題：如果我有一個可怕的程式碼庫區域，這是一個改變的噩夢，如果我不必修改它就不是問題。當我必須使用軟體的那一部分時，我才會觸發利息支付（這是一個比喻崩潰的地方，因為經濟利息支付是由時間推移引發的），這樣苛刻但穩定的程式碼區域可以獨自存在。相比之下，程式碼中高活躍區域需要對累贅態度必須採取零容忍態度，因為支付的利息非常高。這一點尤為重要，因為在開發人員進行更改而不關注內部質量的情況下，不可避免地會積累起來 - 更多的變化，更大的風險。

債務的隱喻有時被用來證明忽視內部質量反而是正當的。爭論的焦點是，需要時間和精力才能阻止累贅的累積，如果迫切需要新的功能，那麼也許最好承擔債務，接受支付利息以便將來必須管理這筆債務。

這裡的危險是大多數時候這種分析做得不好！累贅Cruft具有快速影響，會快速降低所需的新功能的開發效率。

如果團隊為了加快交付時間，而忽略首先將內部質量提高到更高的水平，這樣做的團隊最終會把他們所有的信用卡都用掉（爆卡，債務危機），

在這裡，債務比喻往往會讓人誤入歧途，因為軟體質量的動態與金融貸款的動態並不完全相符。承擔債務以加速交付只有在您停留在DesignStaminaHypothesis的設計支付線以下時才有效，並且團隊達到這條紅線只是幾周時間而不是幾個月。

進一步閱讀

• 據我所知，沃德首先在1992年OOPSLA的經驗報告中介紹了這個概念。它也在維基上討論過。
• 沃德坎寧安有一個視訊談話，他討論了他創造的這個比喻。
• Dave Nicolette通過對我稱之為 謹慎故意債務的精細案例研究擴充套件了Ward對技術債務的看法
• 一些讀者發來了一些同樣好的名字。David Panariti將醜陋的程式設計稱為赤字程式設計。顯然，他最初在幾年前開始使用它符合政府政策; 我想現在再次自然了。
• 斯科特伍德建議“ 當技術水平超過產品基礎時，技術通脹可能會被視為失去的基礎，以至於它開始失去與行業的相容性。這種情況的例子將落後於版本的語言到你的程式碼不再與主流編譯器相容的程度。“
• 史蒂夫麥康奈爾在這個比喻中提出了幾個好點，特別是如果保持你的意外債務，你會有更多的空間在有意義的情況下有意承擔債務。我也喜歡他的最低支付概念（這對於修復嵌入式系統而不是網站的問題非常高）。
• Aaron Erickson談到安然融資。
• Henrik Kniberg認為，較舊的技術債務導致了最大的問題，而且定性債務上限有助於管理它。
• Erik Dietrich討論了技術債務的人力成本：團隊內inf，萎縮技能和自然減員。

相關：

吐槽“技術債務”