技術債務是必然存在的，關鍵是如何管理。

什麼是技術債務？#

技術債務和金融債務一樣，不是絕對的壞事。適度的債務可以加速業務發展，但過多的債務會讓系統難以維護。

寶玉對技術債務的定義：

技術債務是為了短期目標而做出的、會在未來增加成本的技術決策。

技術債務的類型#

flowchart TD
    subgraph A [🎯 有意識的債務]
        A1[為了趕上市場窗口，先用簡單方案]
        A2[知道問題在哪，計劃以後修復]
        A3[這是「借貸」，需要還]
    end

    subgraph B [😵 無意識的債務]
        B1[不知道自己在製造債務]
        B2[缺乏經驗或知識]
        B3[這是「無知稅」，代價更高]
    end

    subgraph C [📅 過時的債務]
        C1[技術選型過時]
        C2[設計不再適合當前需求]
        C3[這是自然演進，難以避免]
    end

    style A fill:#e8f5e9
    style B fill:#ffebee
    style C fill:#fff3e0

技術債務的表現#

技術債務的成因#

業務壓力#

業務說「先上線再說」，這是技術債務最常見的來源。

喬新亮的觀點：

有時候快速上線是對的決策。問題不在於產生債務，而在於不記錄、不還債。

其他常見原因#

人員問題：
├── 經驗不足
├── 缺乏代碼規範
├── 溝通不暢
└── 人員流動

流程問題：
├── 缺乏設計評審
├── 缺乏代碼評審
├── 沒有重構時間
└── 測試不充分

技術問題：
├── 技術選型錯誤
├── 過度設計或設計不足
├── 複製粘貼
└── 文檔缺失

管理技術債務#

識別和記錄#

第一步是識別和記錄技術債務：

mindmap
  root((技術債務管理))
    🔍 識別方法
      代碼審查中發現
      開發過程中標記（TODO、FIXME）
      Bug 分析中發現
      團隊討論中提出
      技術審計
    📝 記錄內容
      債務描述：問題是什麼
      影響範圍：影響哪些功能
      產生原因：為什麼會這樣
      修復成本：需要多少資源
      不修的代價：不修會怎樣
      優先級：什麼時候修

把技術債務當成 Issue 來管理。定期回顧，決定什麼時候修復。

優先級評估#

評估技術債務優先級的框架：

還債策略#

寶玉介紹的還債方式：

持續小改進：

• 每個迭代安排一定比例的重構時間（如 20%）
• 修改功能時順便改進相關代碼
• 不追求一次性解決，持續改進

專項重構：

• 對於大的技術債務，安排專項修復
• 需要和業務溝通，獲得支援
• 有明確的目標和計劃

重寫：

• 最後的選擇，風險和成本都很高
• 確保真的無法通過重構解決
• 需要詳細的遷移計劃

「讓我重寫一遍，這次肯定會更好」是危險的想法。重寫往往會製造新的問題，而且會丟失原有代碼中的隱含知識。

預防技術債務#

編碼規範#

規範的作用：
├── 保持代碼一致性
├── 減少低級錯誤
├── 便於代碼審查
└── 降低溝通成本

規範的內容：
├── 命名規範
├── 格式規範
├── 註釋規範
├── 目錄結構
└── 設計模式

設計評審#

在動手之前評審設計：

• 大的功能變更需要設計評審
• 邀請相關人員參與
• 記錄決策和原因
• 識別潛在的問題

代碼審查#

嚴格的代碼審查：

• 所有代碼都要經過審查
• 審查不只是找 Bug，也關注設計和可維護性
• 不符合標準的代碼不允許合入

適度重構#

童子軍規則——離開時比來時更乾淨。

何時重構：

• 修改功能時，順便改進相關代碼
• 代碼審查中發現的問題
• 遇到難以理解的代碼時

何時不重構：

• 沒有測試覆蓋，風險太大
• 不需要改動的代碼
• 時間緊急，先完成功能

與業務溝通技術債務#

為什麼溝通很重要？#

技術債務往往對非技術人員不可見，但它會影響業務：

• 開發速度變慢
• Bug 變多
• 創新能力下降
• 安全風險增加

如何溝通？#

喬新亮的建議：

mindmap
  root((與業務溝通))
    🗣️ 用業務語言
      不說「代碼耦合」，說「改一個功能要三天」
      不說「技術債務」，說「歷史遺留問題」
      不說「重構」，說「為新功能做準備」
      用數據說話：Bug 數量、開發時間
    💪 爭取資源
      說明不還債的後果
      提出具體的計劃
      承諾可見的收益
      分階段進行

平衡業務壓力#

業務壓力是真實存在的，技術團隊需要在質量和速度之間取得平衡。

平衡的方法：

• 接受有些債務是必要的
• 但要記錄並計劃修復
• 為重大技術債務設置紅線
• 持續和業務溝通

案例：阿里的技術債務#

畢玄分享了阿里處理技術債務的經驗：

淘寶早期為了快速發展，積累了大量技術債務。後來花了很大力氣進行重構和升級。

教訓：

• 債務越積越多，最後不得不付出巨大代價
• 有些債務在當時是必要的（業務優先）
• 還債需要自上而下的支援
• 一邊還債一邊還要支撐業務，很難

本章要點#

1. 債務不是壞事：適度債務可以加速發展，關鍵是管理
2. 識別和記錄：把債務當 Issue 管理，定期回顧
3. 評估優先級：影響範圍、頻繁程度、修復成本
4. 多種還債方式：持續小改進、專項重構、（最後）重寫
5. 預防勝於治療：規範、評審、審查、持續重構
6. 與業務溝通：用業務語言，用數據說話