技術債務–您實際要花多少錢？

技術債務隐喻背後的想法是，采取捷徑（故意技術債務）或犯錯誤（非故意技術債務）會産生成本，并且不處理這些捷徑和錯誤的成本會随着時間而增加。

這個比喻的問題在于，對于金融債務，我們知道今天還清債務要花費多少，并且我們可以計算出将來必須支付的利息。 技術債務雖然模糊得多。 我們真的不知道我們承擔了多少債務-您可能承擔了很多無意的技術債務 -您可能仍在不知不覺中繼續承擔下去。 而且，我們無法量化這實際上使我們付出了多少–到目前為止，我們已支付了多少利息，如果今天不注意的話，将來的總成本可能是多少。

有些人試圖将技術債務納入具體的财務條件 。 例如，根據CAST Software的CRASH報告

“應用程式每行代碼平均承擔$ 3.61的技術債務”。

由于某種原因，Java應用程式的平均成本甚至更高：每行代碼$ 5.42。 這些數字是通過對客戶代碼進行靜态結構分析得出的。

Sonar是一個用于管理代碼品質的開源儀表闆，它還嘗試使用靜态分析結果（例如自動測試的代碼覆寫率，代碼複雜性，重複項，違反編碼習慣，注釋密度）來計算代碼庫的技術債務成本 。

以這種方式思考技術債務很有趣，但是我們不要假裝這些是我們可以用來做出折衷決策的硬數字。 盡管數字看起來很準确，但它們是任意的，猜猜。 他們認為技術債務可以通過檢視代碼結構的工具來計算。 不幸的是，處理技術債務并不是那麼簡單。

但是，如果債務過于模糊而無法用詳細的成本術語衡量，那麼您如何知道哪種債務對您的傷害最大，如何知道您的債務過多呢？ 讓我們看一下使用模糊方法處理的各種技術債務，以及這些技術債務可能給您帶來多少費用。

$$$在架構或平台技術上犯了一個根本性的錯誤–您直到發現真正的客戶都在使用該系統之前，才發現為時已晚，例如資料庫或消息傳遞結構等關鍵技術無法擴充或是不可靠的，或者由于核心依賴性問題而無法按需要擴充架構，或者您對系統的工作方式或客戶的使用方式做出了一些根本上不正确的假設。 現在，您别無選擇，隻能重新啟動，或者至少重寫系統的大部分内容，以使其正常運作或保持正常運作，并且您沒有時間正确執行此操作。

$$-$$$容易出錯的代碼–發現80％的錯誤的代碼的20％。 Capers Jones表示，所有大型系統都有少量例程，其中會聚集錯誤和問題，難以了解的代碼，更改成本高昂和危險的代碼，因為這樣做一開始做得不好，或者由于近視修複和更改的積累。 不重寫此代碼是開發人員犯下的最昂貴的錯誤之一。

$-$$無法輕松測試系統-因為您沒有良好的自動化測試，或者測試脆弱而緩慢，并且在更改代碼時會崩潰。 測試成本可能占進行任何更改或修複的成本的一半以上-有時測試可能比進行修複花費更多的時間，且成本要高得多-随着編寫更多代碼，測試成本會随着時間的流逝而增加，例如系統會添加更多界面和選項。

$-$$不注意打包，釋出和部署。 過分地依靠手動步驟和手動檢查，導緻深夜生産中的錯誤和問題。 就像測試一樣，釋出和部署成本不會消失，它們隻會不斷增加。

$-$$該代碼神秘地起作用，但是沒有人知道如何或為什麼-通常是性能關鍵或安全關鍵的低級管道代碼，該代碼由很早就離開公司的向導編寫。 它可能是精美的代碼，但是如果團隊中沒人了解它，那就是定時炸彈–總有一天，有人将不得不對其進行更改，修複或嘗試。

$-$$向前和向後相容性擴充卡和折衷方案。 這是必要的短期債務。 但是，維護這些折衷方案所需的時間越長，成本就會增加。

$-$$過時的庫和中間件堆棧–您在應用更新檔和更新方面落伍了。 即使您現在擁有的代碼是穩定的，也存在未修補安全漏洞的風險。 持續的時間越長，您所處的位置就越遠，風險就越高–在某個時候，如果不再支援該軟體或該軟體不再受支援，您的手就會被召喚。

$-$$複制，複制和粘貼代碼。 這是技術債務和靜态分析工具的缺陷之一。 幾乎每個人都有。 但是真的有多糟嗎？ 成本取決于開發人員制作了多少個克隆，需要多長時間更改一次克隆，不同副本之間有多少細微差别，以及查找副本并跟蹤它們的難易程度。 如果制作副本的開發人員仍在團隊中，并且能夠很好地跟蹤所有副本，那麼花費不多。

$-$$代碼中已知的，突出的錯誤以及未解決的靜态分析結果。 成本和風險取決于您擁有多少錯誤和警告，以及它們是否令人讨厭。 但是，如果它們是真正的問題，那麼現在應該已經解決了。 如果不給任何人打擾，一個錯誤真的是一個錯誤嗎？

$-$$設計或實作效率低下，“将硬體投入其中”，使用了過多的記憶體，網絡帶寬或CPU。 硬體很便宜，但是随着擴充，這些成本可能會增加很多。

$程式設計習慣用法和模式的用法不一緻–開發人員要麼不了解現有模式，要麼不喜歡它們并引入了新的模式，或者不在乎，隻是想完成他們的更改。 這很醜陋，并且可能使開發人員感到沮喪。 但是，與這種情況一起生活的實際成本通常比試圖将其全部清除的成本要少。

$錯誤處理和異常處理的缺失或不良。 它會在生産中不斷咬你，但是至少要花大價錢才能花很多錢。

$ 0.01寫死，魔術數字，不符合标準的代碼，元素命名不正确，缺少注釋以及需要整理的代碼。 這是痛苦的事情，但是作為标準重構工作的一部分，這種事情很容易清理。

$ 0.01過時文檔–技術債務中通常考慮的另一個問題。 但是說實話， 大多數程式員還是不會閱讀文檔 。 如果沒有人使用它，請擺脫它。 如果人們在使用它，為什麼它不是最新的？

$ 0.00可以使用内置語言功能或庫，現有架構或常用服務完成的手工滾動代碼。 當有人意識到它時，這是令人失望的，但是除非這段手工編寫的代碼中包含很多錯誤，否則這是沉沒的成本，而不是随着時間的推移而增加的成本。

債務種類不同，成本也不同。 弄清楚您的實際成本在哪裡以及如何處理，并不容易。

參考： 技術債務–您實際要花多少錢？ 來自我們的JCG合作夥伴   Building Real Software部落格上的Jim Bird。

翻譯自: https://www.javacodegeeks.com/2012/02/technical-debt-how-much-is-it-really.html