原文： swreflections.blogspot.hk 編譯： 伯樂線上 – 唐小娟
技術債務背後的隱含的意思是，走捷徑（有意的技術債務）或者犯錯（無意的技術債務）都會有開銷，而且不處理這些捷徑或者錯誤的話，開銷會隨著時間而增加。
如果我們有一個財務債務，我們知道我們今天需要還掉多少錢，我們也可以計算出我們將來需要付多少利息。而技術債務卻是模糊不清的，我們不知道我們已經欠了多少債了 – 你可能已經欠了許多無意的技術債務了 – 你也可能在不知情的狀況下欠了許多債。我們沒辦法具體測量出我們已經花了多少了 – 我們已經付了多少利息了，如果我們今天不注意的話，我們將來也不會知道我們總共花了多少了。
一些人試圖將技術債務用具體的金融術語來表述。例如，根據CAST的軟體報告，“對於應用程式，一行程式碼平均要花$3.61”（詳見此文）。由於某種原因，java的程式平均花銷要高些: 每行$5.42。這些資料來自於他們的客戶程式碼的統計分析。
Sonar，一個管理程式碼質量的開源專案，也試著對一個程式碼庫的技術成本進行了計算。他們也用了統計分析的方法，對自動測試用例的程式碼覆蓋率，程式碼覆蓋性，重複率，不遵循程式碼慣例的程式碼以及註釋的密度等進行了分析。
這種方法來急速技術債務很有意思，但我們不能認為這些能作為真正的資料來幫我們做出業務決策。儘管這些數字是精確的，但它們僅僅是主觀的猜測。他們假設技術賬單可以靠分析程式碼的結構來計算。但是計算技術債務並沒有那麼簡單。
但是這個賬單太模糊了，不能用來評估具體的價格。你覺得哪個型別的開銷對你的損害最大，你如何知道何時你花了太多了？讓我們來看看不同的技術賬單，採用模糊的方法來計算你花了多少。
$ $ $ 在架構或是平臺技術方面犯了一個基礎的錯誤 – 你發現的時候已經來不及了，使用者已經在使用系統了；或者是資料庫或訊息構造不能擴充套件，可靠性低；或者是由於核心的依賴問題，你沒辦法按照需要擴充套件架構；或者是你對系統如何工作或是使用者如何使用系統進行了一些不正確的預測。現在沒有選擇了，只能重新開始或者重寫系統的很大部分，能讓系統能繼續運作，通常你沒有足夠的時間來正確重寫。
$ $-$ $ $ 容易出錯的程式碼 – 80%的錯誤出現在20%的程式碼中。Capers Jones說過所有的大系統中，有很少的一部分函式是錯誤的集中處，程式碼很難理解，要修改它們是很危險的而且代價昂貴的，因為它們一開始就寫得很爛，或者是因為一些短視的錯誤修正的積累，使得程式碼隨著時間而腐爛。沒有重寫這些程式碼是程式設計師犯的最昂貴的錯誤。
$-$ $ 系統測試不易 – 因為你沒有好的自動測試用例，或者當你改變程式碼的時候，測試用例變得支離破碎。測試的開銷佔更改程式碼帶來的開銷的一半以上 – 當你寫了更多的程式碼，當系統增加了更多的介面和功能的時候，測試的開銷會隨之增加。
$-$ $ 不注意打包，釋出和部署。太過依賴人手檢測，很容易在程式碼上線的時候造成錯誤。就像測試一樣，釋出和部署帶來的開銷不會消失，會逐漸的增加。
$-$ $ 程式碼很神祕的工作，而沒有人知道為什麼 – 通常涉及到關鍵效能或關鍵安全的底層程式碼是由已經離開公司很久的一個奇才所寫的。可能是很漂亮的程式碼，但團隊裡沒有人能理解它。它就是個定時炸彈，某一天，某個人可能會試著更改它，或修改它。
$-$ $ 向前向後的相容性。這是必須的，短期的債務。但當你需要維護這些相容版本的時間越長，代價會越大。
$-$ $ 庫和中介軟體過期 – 你可能沒有來得及打補丁和升級了。儘管現在的程式碼還很穩定，但你可能遭受沒打補丁的安全性危險。這個過程越久，你拉下的補丁越多，危險越大 – 如果你不再作技術支援了，可能某一天又會有人找到你。
$-$ $ 重複的，複製貼上的程式碼。這是最令人討厭的技術債務之一。幾乎每一個都會寫它們。但是到底有多糟糕？這個開銷取決於開發者寫了多少重複的程式碼，他們多長時間要更改它們一次，在不同的複製部分有多少細小的不同，你能否很輕易的找到重複的程式碼並追蹤它們。如果寫重複程式碼的程式設計師還在團隊裡，並且能很好的追蹤程式碼，這就不會有太大的開銷。
$-$ $ 大家都知道的，很明顯的錯誤，並且沒有被修復的。這個開銷取決於你有多少錯誤和警告，它們到底有多麼的糟糕。如果它們是這種的問題的話，它們應該已經被修復了。如果一個錯誤沒有造成問題的話，它還是錯誤嗎？
$-$ $ 低效的設計或構建，過度消耗硬體，使用過多的記憶體，網路頻寬或cpu。硬體是很便宜的，但當你要進行擴充套件的時候還是要花掉很多的。
$ 使用程式設計習慣和模式不一致 – 程式設計師不理解已經存在的模式，或是不喜歡它們，而引進新的模式，或者僅僅是想改變它們。這樣做會很糟糕，對程式設計師來說會很挫敗。但讓程式就這麼存活下去的開銷往往要比全部清理乾淨的開銷要小。
$ 沒有錯誤處理和異常處理，或者方法不對。在上線階段會讓你很受傷，但通常開銷不會很大，至少你讓大部分都正常執行。
$0.01 硬編碼，神祕的數字，程式碼不遵循規範，混亂的命名，缺失的註釋，不整潔的程式碼。這確實很糟糕，但這些都很容易經過重構的工作清理乾淨。
$0.01 文件過期 – 這經常被認作是技術債務。但老實講，大部分程式設計師都不讀文件。如果沒有人使用文件，那麼就放棄它們。如果人們在使用它，為什麼它們會過期呢？
$0.00 應該使用語言自帶的功能，庫，框架來寫的程式碼卻用手重寫了。當某人意識到的時候是很失望的，但如果這些程式碼沒有太多的錯誤的時候，這是個沉沒成本，而不是會隨時間增長的成本。
不同的債務有不同的開銷。找出你的開銷主要在什麼地方，已經如何處理它們，不是一件容易的事情。
原文： swreflections.blogspot.hk 編譯： 伯樂線上 – 唐小娟