「反正先 work 就好。」——恭喜你，你剛借了一筆高利貸，而且沒打算還。
先講結論
技術債跟財務債一樣：有計畫地借是槓桿，無意識地借是災難。不是所有爛 code 都叫技術債——偷懶寫的爛 code 叫品質問題，不叫債。
什麼才算技術債
Ward Cunningham 原意：「不夠完善的 code 發布出去就是借債，後來重構還清就好，危險的是不還，利息會壓垮你。」
關鍵區分：
- 有意識地趕時間沒寫測試 → 技術債（記下來，排期還）
- 用不完美架構快速驗證市場 → 策略性技術債（驗證成功立刻還）
- 不知道有更好做法 → 不是債，是認知盲區（透過 review 和學習預防）
- 偷懶或缺乏紀律 →
技術債品質問題（改善工程文化）
利息長什麼樣
你借的「本金」是省下來的開發時間。「利息」是：
- 改動成本增加：改一個欄位 5 分鐘 → 因為耦合嚴重要改 10 個檔案花 2 小時
- Bug 率上升：每次改動都怕壞其他東西，因為沒有測試保護
- 新人上手變慢：「這段 code 為什麼這樣寫？」「不知道，別碰它。」
- 信心下降：團隊害怕改東西，能繞就繞，惡性循環
- 機會成本：想加新功能但架構撐不住，被迫先重構
當利息超過本金，你就開始虧了。
什麼時候該借
| 場景 | 理由 | 前提 |
|---|---|---|
| MVP 市場驗證 | 快速上線比完美架構重要 | 有計畫驗證後重構 |
| Deadline 壓力 | 晚一天有具體商業損失 | 記錄欠的債並排期 |
| 技術探索 | 不確定最好做法，先做一版 | 學到更好做法後願意重寫 |
不該借的情況：「反正沒人看」（三個月後的你會看）、「先 work 就好」但沒有「之後怎麼辦」的計畫、已經在高利息的 code 上繼續疊加。
什麼時候該還
這些訊號代表利息太高了：
- 團隊說「別碰那塊」或「這很危險」
- 同樣的 bug 反覆出現——修了 A 壞了 B
- 新功能開發速度明顯下降
- 新人超過兩週才能做第一個 PR
- 你在 workaround 上面疊 workaround
還債的好時機：做新功能時順手改善（Boy Scout Rule）、修 bug 時處理周圍壞味道、Sprint planning 保留 20% 容量持續小額還款、大版本 feature freeze 空檔做結構性重構。
還債策略
- 持續小額還款：每個 PR 順手改善一點，低風險
- Strangler Fig：新功能用新架構，舊功能逐步遷移，適合大型重構
- Feature Flag 漸進替換：新舊邏輯並行確認沒問題再切換
- 寫測試先行：先補測試再改結構
最常見的錯誤：想一次還清所有債。 大型重構風險極高。
怎麼跟 PM 講
PM 問：「功能不是好好的嗎，為什麼要花時間重構？」
不要說「code 太醜了」（他不在乎）或「架構需要改善」（太抽象）。
要說：「現在加一個功能要 3 天，重構後每個功能只要 1 天」、「這區域每月平均 2 個 bug，重構後接近 0」、「新人上手 2 週 → 重構後 3 天」。
用數字和商業影響說話，不要用技術術語。
延伸閱讀
- Code Review 方法論 — Review 時識別技術債的好時機
- 取捨決策框架 — 借還債的決策方法
- 功能從需求到上線 — 哪些階段容易產生技術債
你的專案裡，哪三塊 code 改動時你最害怕？那就是利息最高的技術債。你有記錄它們嗎？還是都存在腦子裡，等你離職就沒人知道了？