概述
代碼寫好就交，意味著欠債的開始。稍微欠點技術債得確可以加快速度，但前提是事后及時重寫代碼，如果只借不還，后果很危險。在不準確的代碼上所花費的每一分鐘，都算是技術債的應付利息。不穩定、脆弱的代碼實現所引發的債務負擔，會使整個工程組織陷入裹足不前的艱難境地。
團隊和組織在深入了解業務領域的同時，還要注意償還技術債;
系統的設計和實現需要跟進以便更好地運用這些認知。
技術債既指我們有意選擇的捷徑，又指許多損害軟件系統的不良實踐。不合適的設計：因為當前所用技術或業務發生重大改變，我們之前有效的設計變得不再適用。
缺陷：我們已知但沒時間解決的軟件中的問題。
測試覆蓋不充分：有些地方我們明明知道該怎么做更多測試但是沒有做
手工測試過多：實際該做自動化測試的時候我們還在做手工測試。
集成和版本管理不善：在做集成和版本管理的時候，采用的方式既費時又容易出錯。
缺乏平臺經驗：例如需要某個技術，但是相關人員卻不多。
技術債的后果
爆發點不可預測
技術債有一個特性就是不可預測的非線性方式增長。在原有債務基礎上增加任何一點技術債，都會產生顯著的危害，遠遠超過新技術債自身的隱含的危害。
交付時間延長
承擔技術債意味著現在向未來申請借用工作時間。今天的債務越多，明天的速率就越慢。
缺陷數量多
技術債務狀況嚴重的產品變得越來越復雜，因而也更難把事情做對。
開發和支持成本上升
技術債一增加，開發和支持成本也會開始增加。過去一直簡單又便宜，現在變得復雜又昂貴。
產品萎縮
如果對老產品停止增加新特性或修復缺陷使其煥發活力，它對當前或潛在客戶就會變得越來越沒有吸引力。最后導致產品開始萎縮，不再是大多數客戶愿意考慮的方案。
可預測性降低
如果產品確實已經債臺高筑，基本上不太可能進行任何形式的預測了。
表現越來越差
技術債越來越多，人們預計工作表現越來越差，進而降低他們對結果的期望。
挫折感四處彌漫
客戶滿意度降低
技術債的起因
如期完成工作
策略性技術債和低級技術債通常都是迫于業務壓力而必須滿足某個迫在眉睫的重大最后期限而造成的。
試圖以錯誤的方式提高速率
如期完工的可能性比較小的情況下，負責干活的團隊就會被要求提高速率，爭取在理想發布日期前完成所有特性。按照這種提高速率工作，團隊必須慎重決策，承擔技術債。
誤區：減少測試可以提高速率
現實的是減少測試即增加債務又減少速率，因為問題潛伏得很深，越晚發現，修復所花的時間越長。
誤區：債累債
舊債如果不還，很快會累計新債。如果一直延續下去，有效速率會趨于零的程度。一旦發現深陷技術債務危機，所有的選擇都是退而求其次的難難選擇。
技術債必須加以管理
技術債和財務債一樣，必須管理。沒有哪個產品能夠做到無債一身輕，認識到這一點也很重要，鑒于此，也不建議努力達到無債狀態。即使如此，達到無債狀態的經濟理由也不夠充分。技術債的管理要求綜合考量技術和業務因素。
管理應計技術債
使用良好的技術實踐
管理技術債務的增長，第一種方法是停止向產品增加低級債務。使用良好的技術實踐是一個非常好的開端。
對于積累下來的技術債，代碼重構是一個非常重要的減輕債務的工具。重構用于改變既有代碼主體的一種技術，在不改變軟件外在前提下調整其內部結構。
使用強完成定義
有些工作本來應該在構建特性的時候就去做，結果卻拖到后期才做，它們是產生技術債的重要根源。我們希望用一個強完成定義來指導團隊在每個沖刺結束時給出一個低負債或零負債的解決方案。
正確理解技術債經濟
為了有計劃地改善技術債，我們必須正確理解它是如何影響決策的經濟考量的。
讓技術債可見
讓技術債在業務層面可見
讓業務人員看見產品的技術債狀態很關鍵。
讓技術債在技術層面可見
- 缺陷跟蹤系統
- 產品列表里
- 技術債列表
償還技術債
并非所有的技術債務都應償還
- 行將就木的產品
- 一次性原型
- 短命產品
