技術負債(英語:Technical debt),又譯技術債,也稱為設計負債design debt)、程式碼負債code debt),是程式設計軟體工程中的一個比喻。指開發人員為了加速軟體開發,在應該採用最佳方案時進行了妥協,改用了短期內能加速軟體開發的方案,從而在未來給自己帶來的額外開發負擔。這種技術上的選擇,就像一筆債務一樣,雖然眼前看起來可以得到好處,但必須在未來償還。軟體工程師必須付出額外的時間和精力持續修復之前的妥協所造成的問題及副作用,或是進行重構,把架構改善為最佳實作方式。

1992年,沃德·坎寧安首次將技術的複雜比作為負債

第一次發布程式碼,就好比借了一筆錢。只要通過不斷重寫來償還債務,小額負債可以加速開發。但久未償還債務會引發危險。復用馬馬虎虎的代碼,類似於負債的利息。整個部門有可能因為鬆散的實作,不完全的物件導向的設計或其他諸如此類的負債而陷入窘境[1]

技術債務的分類

編輯
技術債務的四象限分類
魯莽Reckless 謹慎Prudent

故意Deliberate
 
我們沒有時間做設計 我們必須馬上交付,後果以後再說

疏忽Inadvertent
 
什麼是分層(設計)? 現在我們才知道該如何做了

馬丁·福勒提出了把技術負債分為四個象限[2]

常見的技術債務的原因有:

  • 不充足的事前定義,從而需求仍然在開發過程中被定義,開發在設計之前就已經開始。這種做法的目的是節約時間,但常不得不以後返工。
  • 商務壓力。商務角度需要在必須的改變完成之前就發布產品。因此開發的技術債務包括那些待完成的改變。[3]:4[4]:22
  • 缺少流程或理解,從而商務上對技術債務不了解,不考慮後果就做出決策。
  • 緊耦合組件。功能不是模組化,軟體不夠靈活應對商務上的變化。
  • 缺乏測試套件。這刺激了快速高風險「湊活式」的修復bug。
  • 缺少文件。寫代碼但沒有必要的支撐性文件。[3]
  • 缺乏合作。知識沒有得到共享,對新手缺乏監督輔導。
  • 在兩個或多個分支上平行開發而累積了技術債務。由於工作最終需要合併兩個分支的代碼,拖延越晚,需要工作代價越大。
  • 拖延做重構 – 重構拖延越晚,需要修改的代碼越多。[4]:29
  • 缺少與標準對齊。工業標準的特性、框架、技術被忽視。最終也必將遵從標準,做得越早代價越小。[3]:7
  • 缺少知識。開發者並不知道如何寫精緻的代碼。[4]
  • 缺少所有權。外包的軟體最終要讓自己的工程師去重構或重寫原始碼。
  • 技術領導力差,未深思熟慮的命令通過命令鏈傳達下來,增加了技術債務,而不是減少它。
  • 最後一分鐘規範改變。這有可能滲透到整個專案中,沒有時間或預算通過文件或檢查來發現它們。

參見

編輯

參考資料

編輯
  1. ^ Ward Cunningham. The WyCash Portfolio Management System. 1992-03-26 [2008-09-26]. (原始內容存檔於2008-12-23). 
  2. ^ Fowler, Martin. Technical Debt Quadrant. [20 November 2014]. (原始內容存檔於2013-02-02). 
  3. ^ 3.0 3.1 3.2 Girish Suryanarayana; Ganesh Samarthyam; Tushar Sharma. Refactoring for Software Design Smells: Managing Technical Debt. Elsevier Science. 11 November 2014: 3 [2019-02-19]. ISBN 978-0-12-801646-6. (原始內容存檔於2021-05-26). 
  4. ^ 4.0 4.1 4.2 Chris Sterling. Managing Software Debt: Building for Inevitable Change (Adobe Reader). Addison-Wesley Professional. 10 December 2010: 17. ISBN 978-0-321-70055-1.