不要把所有舊程式都當成同一種債
技術債常被描述成程式碼品質問題，但真正需要管理的是它對營運造成的風險。一套多年未改、功能單純且幾乎不會故障的內部工具，即使框架老舊，也未必值得立即重寫。相反地，一段只有數百行、卻每天負責同步訂單、庫存與發票的整合程式，只要缺乏重試、監控或冪等設計，就可能是更急迫的債。
因此，排程時不應只問「這段程式有多難維護」，而要問失敗會造成什麼後果，以及團隊能否安全復原。可能的後果包括交易中斷、資料重複寫入、權限外洩、人工補單、客服量增加，或讓下游 ERP、CRM 與 LINE 通知全部收到錯誤資料。技術債的優先級，應由這些營運結果決定，而不是由開發者對舊架構的不滿決定。
用五個問題評估營運風險
建立技術債清單時，不必急著設計精密分數。先讓工程、維運與流程負責人用一致問題討論，通常就能看出排序差異：
- 影響範圍：故障只影響單一內部使用者，還是會阻塞訂單、付款、出貨或客戶服務？
- 可復原性：能否安全重跑、回滾或補償，還是必須人工比對多個系統後逐筆修正？
- 可偵測性：系統會主動告警，還是要等客戶、會計或倉庫發現資料不一致？
- 變更頻率：這個元件是否經常配合新流程、API 或法規調整？每次修改是否容易引發回歸問題？
- 依賴程度：有多少服務、報表或自動化流程依賴它？供應商停用 API 或憑證到期時，是否有替代路徑？
評估時要把技術故障翻譯成營運語言。例如「訊息佇列沒有死信處理」較難取得非工程團隊的共識；「失敗的訂單事件會消失，且無法自動辨識哪些訂單需要補送」則清楚說明了風險。若影響很大但容易偵測、可快速回滾，優先級可能低於影響中等卻會靜默破壞資料的問題。
先降低暴露，再決定是否重寫
高風險技術債不代表一定要全面重寫。重寫本身會引入行為差異、資料搬遷與切換風險，尤其企業整合系統往往包含文件未記載的例外規則。更實際的做法，是先找出最便宜的風險控制：加入可觀測性、輸入驗證、逾時與重試策略、冪等鍵、對帳報表、權限隔離、備份演練或人工降級流程。這些措施不能消除結構性問題，但能縮短故障發現與復原時間。
接著再依問題性質選擇處理方式。若債務集中在清楚邊界內，可以逐步替換模組；若主要風險來自外部 API 不穩定，應先建立轉接層與失敗佇列；若核心資料模型已阻礙所有新需求，才值得規劃較大範圍的重構。對低風險、低變更的舊系統，凍結功能、限制存取並保留可還原環境，往往比翻新更合理。
把還債放進交付節奏，而不是等待空檔
技術債若只能在「有空時」處理，通常不會發生。比較有效的方法，是把償還工作綁定明確觸發條件：某元件即將新增重要流程、供應商準備淘汰介面、值班事件反覆出現、修復時間持續拉長，或某項控制已無法滿足安全與稽核要求。此時改善不是額外的美化工作，而是交付新功能前必要的風險成本。
每個還債項目也應有可驗證的完成條件，而不是「整理程式碼」。例如：失敗事件可以重新處理而不產生重複交易；部署可在不修改資料的情況下回滾；跨系統資料有每日對帳與責任歸屬；告警能指出受影響的流程與識別碼。這些條件讓產品、營運與工程能共同判斷投資是否有效。
維護一份會變動的風險清單
技術債排序不是一次性的架構審查。新客戶流程、流量型態、雲端服務調整與第三方介面變更，都可能改變原本的風險。團隊可以在重大上線後、事故檢討時與季度規劃前重新檢視清單，記錄負責人、依賴關係、現有控制、下一個降低風險的動作，以及不處理的理由。
最成熟的做法不是消滅所有技術債，而是知道哪些債正在承擔、為何可以接受，以及什麼事件會改變決策。當排序圍繞營運影響與復原能力，工程團隊就能保留交付速度，同時避免最脆弱的整合點在關鍵時刻成為事故來源。