技術(shù)債務(wù)背后的隱含的意思是，走捷徑（有意的技術(shù)債務(wù)）或者犯錯（無(wú)意的技術(shù)債務(wù)）都會(huì )有開(kāi)銷(xiāo)，而且不處理這些捷徑或者錯誤的話(huà)，開(kāi)銷(xiāo)會(huì )隨著(zhù)時(shí)間而增加。
如果我們有一個(gè)財務(wù)債務(wù)，我們知道我們今天需要還掉多少錢(qián)，我們也可以計算出我們將來(lái)需要付多少利息。而技術(shù)債務(wù)卻是模糊不清的，我們不知道我們已經(jīng)欠了多少債了 – 你可能已經(jīng)欠了許多無(wú)意的技術(shù)債務(wù)了 – 你也可能在不知情的狀況下欠了許多債。我們沒(méi)辦法具體測量出我們已經(jīng)花了多少了 – 我們已經(jīng)付了多少利息了，如果我們今天不注意的話(huà)，我們將來(lái)也不會(huì )知道我們總共花了多少了。
一些人試圖將技術(shù)債務(wù)用具體的金融術(shù)語(yǔ)來(lái)表述。例如，根據CAST的軟件報告，“對于應用程序，一行代碼平均要花$3.61”（詳見(jiàn)此文）。由于某種原因，java的程序平均花銷(xiāo)要高些: 每行$5.42。這些數據來(lái)自于他們的客戶(hù)代碼的統計分析。
Sonar，一個(gè)管理代碼質(zhì)量的開(kāi)源項目，也試著(zhù)對一個(gè)代碼庫的技術(shù)成本進(jìn)行了計算。他們也用了統計分析的方法，對自動(dòng)測試用例的代碼覆蓋率，代碼覆蓋性，重復率，不遵循代碼慣例的代碼以及注釋的密度等進(jìn)行了分析。
這種方法來(lái)急速技術(shù)債務(wù)很有意思，但我們不能認為這些能作為真正的數據來(lái)幫我們做出業(yè)務(wù)決策。盡管這些數字是精確的，但它們僅僅是主觀(guān)的猜測。他們假設技術(shù)賬單可以靠分析代碼的結構來(lái)計算。但是計算技術(shù)債務(wù)并沒(méi)有那么簡(jiǎn)單。
但是這個(gè)賬單太模糊了，不能用來(lái)評估具體的價(jià)格。你覺(jué)得哪個(gè)類(lèi)型的開(kāi)銷(xiāo)對你的損害最大，你如何知道何時(shí)你花了太多了？讓我們來(lái)看看不同的技術(shù)賬單，采用模糊的方法來(lái)計算你花了多少。
$$$ 在架構或是平臺技術(shù)方面犯了一個(gè)基礎的錯誤 – 你發(fā)現的時(shí)候已經(jīng)來(lái)不及了，用戶(hù)已經(jīng)在使用系統了；或者是數據庫或消息構造不能擴展，可靠性低；或者是由于核心的依賴(lài)問(wèn)題，你沒(méi)辦法按照需要擴展架構；或者是你對系統如何工作或是用戶(hù)如何使用系統進(jìn)行了一些不正確的預測?，F在沒(méi)有選擇了，只能重新開(kāi)始或者重寫(xiě)系統的很大部分，能讓系統能繼續運作，通常你沒(méi)有足夠的時(shí)間來(lái)正確重寫(xiě)。
$$-$$$ 容易出錯的代碼 – 80%的錯誤出現在20%的代碼中。Capers Jones說(shuō)過(guò)所有的大系統中，有很少的一部分函數是錯誤的集中處，代碼很難理解，要修改它們是很危險的而且代價(jià)昂貴的，因為它們一開(kāi)始就寫(xiě)得很爛，或者是因為一些短視的錯誤修正的積累，使得代碼隨著(zhù)時(shí)間而腐爛。沒(méi)有重寫(xiě)這些代碼是程序員犯的最昂貴的錯誤。
$-$$ 系統測試不易 – 因為你沒(méi)有好的自動(dòng)測試用例，或者當你改變代碼的時(shí)候，測試用例變得支離破碎。測試的開(kāi)銷(xiāo)占更改代碼帶來(lái)的開(kāi)銷(xiāo)的一半以上 – 當你寫(xiě)了更多的代碼，當系統增加了更多的接口和功能的時(shí)候，測試的開(kāi)銷(xiāo)會(huì )隨之增加。
$-$$ 不注意打包，發(fā)布和部署。太過(guò)依賴(lài)人手檢測，很容易在代碼上線(xiàn)的時(shí)候造成錯誤。就像測試一樣，發(fā)布和部署帶來(lái)的開(kāi)銷(xiāo)不會(huì )消失，會(huì )逐漸的增加。
$-$$ 代碼很神秘的工作，而沒(méi)有人知道為什么 – 通常涉及到關(guān)鍵性能或關(guān)鍵安全的底層代碼是由已經(jīng)離開(kāi)公司很久的一個(gè)奇才所寫(xiě)的?？赡苁呛芷恋拇a，但團隊里沒(méi)有人能理解它。它就是個(gè)定時(shí)炸彈，某一天，某個(gè)人可能會(huì )試著(zhù)更改它，或修改它。
$-$$ 向前向后的兼容性。這是必須的，短期的債務(wù)。但當你需要維護這些兼容版本的時(shí)間越長(cháng)，代價(jià)會(huì )越大。
$-$$ 庫和中間件過(guò)期 – 你可能沒(méi)有來(lái)得及打補丁和升級了。盡管現在的代碼還很穩定，但你可能遭受沒(méi)打補丁的安全性危險。這個(gè)過(guò)程越久，你拉下的補丁越多，危險越大 – 如果你不再作技術(shù)支持了，可能某一天又會(huì )有人找到你。
$-$$ 重復的，復制粘貼的代碼。這是最令人討厭的技術(shù)債務(wù)之一。幾乎每一個(gè)都會(huì )寫(xiě)它們。但是到底有多糟糕？這個(gè)開(kāi)銷(xiāo)取決于開(kāi)發(fā)者寫(xiě)了多少重復的代碼，他們多長(cháng)時(shí)間要更改它們一次，在不同的復制部分有多少細小的不同，你能否很輕易的找到重復的代碼并追蹤它們。如果寫(xiě)重復代碼的程序員還在團隊里，并且能很好的追蹤代碼，這就不會(huì )有太大的開(kāi)銷(xiāo)。
$-$$ 大家都知道的，很明顯的錯誤，并且沒(méi)有被修復的。這個(gè)開(kāi)銷(xiāo)取決于你有多少錯誤和警告，它們到底有多么的糟糕。如果它們是這種的問(wèn)題的話(huà)，它們應該已經(jīng)被修復了。如果一個(gè)錯誤沒(méi)有造成問(wèn)題的話(huà)，它還是錯誤嗎？
$-$$ 低效的設計或構建，過(guò)度消耗硬件，使用過(guò)多的內存，網(wǎng)絡(luò )帶寬或cpu。硬件是很便宜的，但當你要進(jìn)行擴展的時(shí)候還是要花掉很多的。
$ 使用編程習慣和模式不一致 – 程序員不理解已經(jīng)存在的模式，或是不喜歡它們，而引進(jìn)新的模式，或者僅僅是想改變它們。這樣做會(huì )很糟糕，對程序員來(lái)說(shuō)會(huì )很挫敗。但讓程序就這么存活下去的開(kāi)銷(xiāo)往往要比全部清理干凈的開(kāi)銷(xiāo)要小。
$ 沒(méi)有錯誤處理和異常處理，或者方法不對。在上線(xiàn)階段會(huì )讓你很受傷，但通常開(kāi)銷(xiāo)不會(huì )很大，至少你讓大部分都正常運行。
$0.01 硬編碼，神秘的數字，代碼不遵循規范，混亂的命名，缺失的注釋?zhuān)徽麧嵉拇a。這確實(shí)很糟糕，但這些都很容易經(jīng)過(guò)重構的工作清理干凈。
$0.01 文檔過(guò)期 – 這經(jīng)常被認作是技術(shù)債務(wù)。但老實(shí)講，大部分程序員都不讀文檔。如果沒(méi)有人使用文檔，那么就放棄它們。如果人們在使用它，為什么它們會(huì )過(guò)期呢？
$0.00 應該使用語(yǔ)言自帶的功能，庫，框架來(lái)寫(xiě)的代碼卻用手重寫(xiě)了。當某人意識到的時(shí)候是很失望的，但如果這些代碼沒(méi)有太多的錯誤的時(shí)候，這是個(gè)沉沒(méi)成本，而不是會(huì )隨時(shí)間增長(cháng)的成本。
不同的債務(wù)有不同的開(kāi)銷(xiāo)。找出你的開(kāi)銷(xiāo)主要在什么地方，已經(jīng)如何處理它們，不是一件容易的事情。
聯(lián)系客服
