技術債

技術債是為了短期加快開發速度而採取的權宜設計，日後需要額外時間與成本償還，才能維持系統的可維護性。

技術債不只是「程式碼比較亂」的抽象說法，而是有具體代價的：根據 McKinsey 針對 CIO 的調查，企業投入新產品開發的科技預算中，平均有 10-20% 被挪去處理技術債相關問題，CIO 們估計技術債占整體科技資產價值的 20-40%，六成的 CIO 認為過去三年技術債有明顯上升。常見來源包含缺乏測試、架構設計倉促、文件不完整，尤其容易發生在單一接案者交付、後續又換過幾手不同工程師維護的專案。判斷該修補還是該重建，有一個簡單的參考基準：當某個部門的技術債超過其技術資產價值的 50%，重建的效益才會開始超過持續修補的成本，多數情況下這個門檻還沒到，優先修補其實比整套重寫更划算。以一家使用超過八年舊系統的貿易公司為例，與其花大錢全面重寫，不如先盤點哪些模組真正拖慢新功能開發，針對性地還債即可。常見誤解是以為技術債只影響工程團隊的心情——實際上它會直接拖慢後續功能開發速度，並在系統擴充或人力交接時放大風險，是會反映在報價單和上線時程上的實際成本。