技術負債（Technical debt）

技術負債

技術負債（Technical debt）
在開發過程中為了滿足當下需求而採取捷徑、加速完成眼前專案，因而在未來必須付出的代價

就像在會計上承擔負債（debt）去借錢，可以快速投入急需的地方，但之後必須承受財務壓力並連本帶利償還一樣，為了滿足眼前需求而即使有點混亂也先把開發做快，會讓程式碼變得複雜與重複，日後在實作新功能或擴充時就會遇到困難。

企業透過舉債得以及時加大投資、開發新產品並提高市占，或個人透過貸款購屋一樣，承擔技術負債以便快速實作新功能並非絕對壞事；重點在於減少技術負債的堆積，並將其控制在可承受、可管理的範圍內。

為什麼會產生技術負債

即便開發者能力再強，開發過程中技術負債仍然難以避免，想要從源頭徹底杜絕幾乎不可能。 服務演進到某個階段，當原先的設計遇到瓶頸，即使那段程式碼原本可讀性良好、運作正常，也可能不得不調整既有架構。 此外，隨著技術演進，過去主流的函式庫／框架逐漸式微，團隊可能決定更換技術棧到其他函式庫／框架；在這種情況下，既有程式碼也會成為一種技術負債.

除此之外，還可能因為下列原因產生技術負債。

• 專案進行中未及時把設計文檔化，導致他人或事後連自己回頭看程式碼時都難以理解
• 未清理不再使用的變數或資料庫項目
• 未將重複性工作（部署／建置等）自動化，導致每次都需額外時間與人力
• 緊急的規格變更

最小化技術負債的方法

建立開發者之間的規範（Convention）

• 若非單兵開發，為了順暢協作，需要就使用的語言與技術棧、專案目錄結構、開發風格等達成共識
• 應決定哪些部分需要統一規範，哪些部分保留個人裁量
• 透過程式碼審查確認彼此的開發風格並交流意見

撰寫整潔程式碼（Clean Code）與重構（Refactoring）

• 若既有程式碼雜亂而妨礙開發，可透過重構（Refactoring）整理結構，清償技術負債
• 當然，越是凌亂的義大利麵式程式碼，重構難度越高；極端時甚至會放棄重構、直接丟棄舊碼並從零重寫
• 盡量從一開始就撰寫可讀性佳、易於維護的程式碼