技術債（technical debt）是指軟件在開發或修改時，為了今天做得快而採用的做法，令日後的修改變得更慢、風險更高或成本更貴。這個說法把走捷徑比喻為借錢：你較早得到成果，但之後每次有人要繞過這個捷徑工作，就要付出「利息」，直至根本問題得到處理為止。
對委託開發網站、App 或內部系統的企業來說，技術債會影響回應客戶的速度、每次修改的成本，以及系統能否安全地保持更新。
技術債從哪裡來
大部分系統都有一定程度的技術債。它往往來自日常的決定，例如：
- 趕上線期：功能先用臨時方法推出，原本打算之後再整理，但「之後」一直沒有來。
- 沒有自動化測試：每次修改都要靠人手檢查，開發人員自然不願碰脆弱的部分。
- 框架和相依元件過時：程式庫、框架和伺服器軟件不斷更新，每跳過一次，下一次升級的幅度就更大。
- 複製貼上的程式碼：同一段邏輯在多處重複，改一條規則便要在幾個地方修改和測試。
- 缺乏文件：系統如何運作，只有某一位同事或前供應商知道。
- 不再支援的外掛和佈景主題：網站上相當常見。作者停止維護後，外掛便不再有修正，包括保安修正。
非技術背景的負責人會察覺的跡象
即使不懂程式，也可以從以下情況看出技術債：
- 小修改，例如在表格加一個欄位或改一條價錢規則，所需時間遠超預期；
- 修正一個問題後，另一處功能卻出錯；
- 新加入的開發人員要很長時間才能安全地修改系統；
- 保安修補和版本升級一再延後，理由是「怕會弄壞其他東西」。
刻意與無意的技術債
技術債不一定是錯誤。刻意的技術債是有意識的取捨，例如先以較簡單的設計推出 MVP 測試市場反應，並清楚知道若概念可行，這部分便要重建。只要有記錄、有計劃，這可以是合理的商業決定。
無意的技術債則是在沒有人選擇的情況下累積：團隊當時不知道更好的做法、設計定案後需求有變，或者軟件隨時間老化。由於沒有人記下它在哪裡，這類技術債通常較難管理。
如何管理技術債
目標不是完全沒有技術債，而是讓它清楚可見、範圍有限，並按計劃償還。實際做法包括：
- 建立清單：簡單列出已知的捷徑、過時元件和脆弱部分，並註明各自對業務的影響。
- 每次發布預留時間：在每個開發週期撥出部分時間整理，而不是等一個大型項目才處理。
- 加入自動化測試：為關鍵流程進行回歸測試，修改和重構程式碼時會更安全。
- 定期更新相依元件：小而頻密的更新，比相隔多年後一次過大幅升級更容易測試。
- 重構：在不改變功能的前提下改善現有程式碼的結構，最好與新功能開發一同小步進行。
- 撰寫文件：記錄系統如何設定、部署，以及與哪些服務連接。
- 程式碼審查與自動化：由另一位開發人員審查修改，再配合自動執行測試的 CI/CD 流程，有助防止新的技術債混入。
償還、暫時保留，還是重建？
並非每一項技術債都需要處理。可以這樣判斷：
- 償還：技術債位於經常修改的部分，或者妨礙保安更新。
- 暫時保留：受影響的部分穩定、很少修改，而且風險低。把它記在清單上，之後再檢討。
- 重建：核心平台已不再獲支援，大部分修改都慢而且有風險，修補成本接近重新開發。重建本身也有風險，通常較穩妥的做法是分階段替換，並讓舊系統繼續運作，直至每部分都證實可用。
如何與供應商討論技術債
請開發商或支援服務供應商以業務角度解釋技術債。可以問：
- 系統哪些部分最難修改或風險最高？原因是甚麼？
- 哪些框架、外掛或伺服器元件已經過時或不再獲支援？
- 你會先處理哪一項？處理後哪些工作會更快或更安全？
- 每次發布建議預留多少時間做維護和整理？
- 目前測試、文件和程式碼審查是如何處理的？
如果你有持續的支援協議，最好寫明誰負責更新相依元件和安裝保安修補。我們的軟件支援 SLA 文章介紹這類協議通常包括甚麼，而我們的託管支援及 SLA 服務亦負責這類持續維護工作。
常見問題
技術債一定是壞事嗎？
不一定。為了更早推出、測試構思而刻意承擔技術債，可以是正確的選擇。問題在於技術債沒有被記錄，也從未償還。
非技術背景的負責人可以衡量技術債嗎？
無法精確衡量，但可以留意一些跡象：小修改要花多少時間、發布後多常出現新問題，以及有多少元件已超出支援版本。可以要求供應商定期匯報這些情況。
重建系統可以消除技術債嗎？
只能維持一段時間。新系統起步時技術債較少，但如果沒有測試、文件、更新和審查，技術債會再次累積。
技術債會影響保安嗎？
有可能。過時的相依元件和不再支援的外掛可能不再收到保安修正，脆弱的程式碼亦會令團隊更遲才能安裝修補。