技術債 - 到底花你多少錢？

技術債的比喻背後的思想是抄近路（有意識的技術債）或者犯錯誤（無意的技術債）是有成本的，並且忽視這些捷徑和錯誤的成本會與時俱增。

這個比喻的問題是，對於財務上的債務，我們知道今天付和將來付分別花多少錢，而對於技術債則不然。我們並不知道到底欠了多少 —— 也許你已經欠了很多的無意的技術債 —— 你也許正在不知不覺中欠下更多的債。我們不能定量的說成本到底有多大——到目前為止我們已經付了多少利息，以及如果今天我們不管的話將來的總成本是多少。

一些人已經嘗試著把技術債表達成確切的財務公式。例如，根據CAST Software的CRASH報告，“一個應用平均每行程式碼負債3.61美元”。

出於某些原因，Java應用的平均成本更高一些：每行程式碼5.42美元。這些數字是通過對客戶程式碼執行靜態結構分析計算出來的。

Sonar，一個開源的管理程式碼質量的報告軟體，同樣試圖計算一個程式碼庫的技術債成本，方法是通過靜態分析如自動化測試的程式碼覆蓋率、程式碼複雜度、重複程式碼、程式設計規範的違背、註釋密度等。

象這樣考慮技術債很有趣，但是讓我們停止假裝這些都是可以用來做權衡決策的確切數字吧。雖然這些數字看起來很精確，但實際上是隨意的估計的結果。他們假設技術債可以用一種分析程式碼結構的工具計算出來。不幸的是，處理技術債不是那麼簡單的。

然而，如果債務太模糊以至於不能用詳細的成本項來衡量，你怎麼能知道何種債務導致的問題最大呢？你怎麼知道你何時負債過多了呢？

讓我們用一種比較模糊的方式來審視一下不同型別的技術債，以及它們的成本。

$$$ 在架構或者平臺技術上犯根本性的錯誤 - 等你發現時已經太晚了：已經有客戶在使用系統了，一個關鍵技術（如資料庫或者訊息架構）難以擴充套件或者不可靠，你的架構由於核心以來問題而無法擴充套件，你在關於系統如何工作或客戶如何使用上犯了根本性的錯誤等。現在你除了重新開始，或者至少重寫大塊的系統以外毫無選擇，而你並沒有時間去這樣做。

$$-$$$ 易錯程式碼 - 20%的程式碼對80%的bug負責。Capers Jones說所有大型系統都有少數的例程集中了大量的bug，這些程式碼超難理解、改寫起來非常昂貴和危險。原因可能是一開始就搞砸了，或者隨著短視的修復和變化的長時間積累變壞了。不重寫這樣的程式碼是開發人員犯的最昂貴的錯誤之一。

$-$$ 系統難以測試 - 因為你沒有好的自動化測試例，或者測試例很脆弱、緩慢、總是趕不上程式碼變化。測試成本可達程式碼變更或者修復成本的一半 ——有時測試所花的時間甚至超過了修復本身所花的時間——測試成本傾向於隨著時間和更多的程式碼、更多的介面和選項而攀升。

$-$$ 那些神祕工作著但無人肯定如何工作以及為什麼工作的程式碼 - 通常效能或安全關鍵的低層程式碼是由一個奇才寫就的，而他已經離開了公司。可能程式碼本身很漂亮，但是沒人理解它，這就會成為程式碼炸彈 - 總有一天，會有人去改變或者修復它的，也許只是嘗試著這麼做。

$-$$ 向前和向後相容介面卡和妥協。這是必要的短期債務，但是成本會因為你要長期維護這些妥協而提升。

$-$$ 過時的庫和中介軟體棧 - 你被補丁和升級包拉在後面了。即使你現在的程式碼是穩定的，不打補丁帶來的安全風險是避免不了的。拖的時間越長，你落後的越遠，風險也就越高——當在某一天軟體不再被支援的時候，你就措手不及了。

$-$$ 重複程式碼,拷貝-貼上程式碼。這是技術債和靜態分析工具眼中的怪物之一。幾乎每個人都有它，但是究竟有多壞呢？成本取決於開發人員搞了幾份拷貝、它們有多經常被修改、不同的拷貝之間有多少微妙的差異，以及發現這些並跟蹤這些拷貝的難度。如果做這些拷貝的開發人員還在並且能很好的跟蹤它們，那不會有什麼大的成本。

$-$$ 程式碼中已知的未修復bug, 有些是靜態分析工具發現的。成本和風險取決於bug和告警的數量，以及它們有多討厭。然而，如果這些是真正的問題，它們應該立刻修復，而那些留到現在並不那麼明確的bug真的是bug嗎？

$-$$ 低效的設計或實現，使用太多的記憶體或者網路頻寬或者CPU。硬體是便宜的，但是成本會隨著規模變大而劇增。

$ 不一致的使用程式設計模式 - 開發人員或者是不理解現存的模式，或者是不喜歡它們而引入新的模式，或者無所謂而只是完成變更。結果是非常的醜陋，把開發人員搞的很鬱悶。然而，這種情形存在的成本並不比試圖修復它們要高。

$ 丟失的或者糟糕的錯誤處理。它們會經常的在生產環境裡出現羞辱你，但是修復這些問題並不會花費太多成本。

0.01$ 硬編碼，魔術數字，不符合標準的程式碼，糟糕的元素命名，丟失的註釋，需要變得更整齊的程式碼。這令人不舒服，但是很容易作為標準重構的一部分修復。

0.01$ 過時的文件 - 另外一個技術債通常考慮的問題。然而，誠實的說，大多數程式設計師並不讀文件。如果沒人使用的話，消滅它吧。如果人們在用，為什麼不更新呢？

0.00$ 本來可以用內部語言特性或庫或現成的框架或通用服務實現的但卻手工編寫的程式碼。看到的人會失望，但是除非有很多bug，還是把它看作沉沒成本吧，因為它不會隨著時間增加。

不同種類的債務，不同的成本。搞清楚你真正的成本、以及如何處理，並不是一件容易的事情。

原文：Technical Debt - How much is it Really Costing you?

歡迎參加iTran樂譯4期