技术债务治理

核心命题：技术债不是不还——而是要在合适的时间、用合适的节奏还。

---

01. 技术债分类

类型	特征	例子
有意的	明知不完美，为赶时间	先 hardcode，下版本改配置
无意的	不知道可以做得更好	没用设计模式导致后期膨胀
腐烂的	代码老化，环境变了	老框架不再维护
策略性的	故意留着，因为还不需要	MVP 阶段不搞高可用

---

02. 识别与度量

• 圈复杂度：函数分支太多 → 该拆了
• 代码重复率：同一逻辑 3 次以上 → 该抽取了
• 文件行数：单文件 > 1000 行 → 该拆模块了
• 依赖深度：循环依赖 → 该解耦了
• 测试覆盖率：核心路径 < 70% → 风险高

---

03. 偿还策略

紧急债务 → 立即还（不还发不了版）
├── 安全漏洞
├── 数据丢失风险
└── 核心路径崩溃

短期债务 → 本季度还
├── 性能退化 > 20%
├── 重复代码 > 3 处
└── 依赖过期但目前无风险

长期债务 → 列计划、慢慢还
├── 架构不合理但能跑
├── 遗留框架迁移
└── 文档缺失

---

04. 治理节奏

• 每个 Sprint 留 20% 时间清理技术债
• 季度专项：用 1-2 周集中治理
• 年度大修：框架升级、架构演进

---

05. 一句话总结

技术债和房贷一样——不还是不可能的，但要有还款计划。烂摊子是拖出来的。