技术债务管理：怎么还、还多少
每个项目都有技术债务，关键是认清它、管理它。
什么是技术债务
| 类型 | 例子 |
|---|---|
| 代码债务 | 重复代码、复杂逻辑 |
| 架构债务 | 不合理的分层、强耦合 |
| 测试债务 | 缺少测试、测试覆盖低 |
| 文档债务 | 文档缺失、过时 |
| 依赖债务 | 旧版本依赖、安全漏洞 |
技术债务的来源
有意为之
"先这样实现，后面再优化"
"为了赶上线，暂时绕过这个问题"这在创业阶段是合理的，但要记录。
无意积累
新人不熟悉代码风格
需求变更导致设计不匹配
技术演进，旧方案过时识别技术债务
代码审查时
建立债务清单：
## 技术债务清单
| 编号 | 描述 | 影响 | 优先级 | 预计工时 |
|------|------|------|--------|----------|
| TD-001 | 用户模块缺少单元测试 | 中 | P2 | 2d |
| TD-002 | 订单服务与支付服务耦合 | 高 | P1 | 3d |
| TD-003 | React 版本过旧 | 低 | P3 | 1d |代码中的标记
// TODO: 临时方案，需要重构
// FIXME: 这里有性能问题
// HACK: 绕过了校验，需要修复统计这些标记：
grep -r "TODO\|FIXME\|HACK" src/ | wc -l度量指标
| 指标 | 说明 |
|---|---|
| 代码复杂度 | 圈复杂度、认知复杂度 |
| 测试覆盖率 | 单元测试覆盖 |
| 依赖健康度 | 过时依赖数量 |
| 代码重复率 | 重复代码占比 |
评估技术债务
影响维度
| 维度 | 问题 |
|---|---|
| 开发效率 | 影响开发速度多少？ |
| 系统稳定 | 会导致故障吗？ |
| 安全风险 | 有安全隐患吗？ |
| 可维护性 | 新人能快速上手吗？ |
量化评分
影响分 (1-5) × 频率分 (1-5) = 优先级分数示例：
| 债务 | 影响 | 频率 | 分数 |
|---|---|---|---|
| 支付服务耦合 | 5 | 5 | 25 (高) |
| 缺少文档 | 2 | 4 | 8 (低) |
| 旧版依赖 | 3 | 3 | 9 (中) |
偿还策略
策略一：童子军规则
每次修改代码，让它比你接手时更好一点
// 改 bug 时顺便加个测试
// 重构时顺便更新注释
// 加功能时顺便简化相关代码策略二：专项偿还
每个迭代留 20% 时间偿还债务：
## Sprint 计划
- 功能开发：80%
- 技术债务：20%
- TD-002：重构订单服务
- TD-003：升级 React 版本策略三：集中偿还
大版本迭代前，集中处理：
v2.0 开发前：
- 清理废弃代码
- 统一代码风格
- 升级核心依赖策略四：不偿还
是的，有些债务不需要偿还：
- 即将废弃的模块
- 影响很低的债务
- 成本高于收益的债务
实战案例
案例：遗留系统重构
问题：一个 5 年的老系统，技术栈过时，维护困难。
策略：
| 阶段 | 行动 | 时间 |
|---|---|---|
| 评估 | 梳理债务清单 | 1 周 |
| 规划 | 制定重构计划 | 1 周 |
| 边界 | 建立新旧边界 | 2 周 |
| 迁移 | 逐步迁移功能 | 持续 |
关键做法：
- 新功能用新技术栈
- 老功能渐进迁移
- 保持系统可用
- 每次迁移都有测试覆盖
案例：依赖升级
问题：React 16，无法享受新特性。
策略：
## React 升级计划
### 阶段 1：评估
- 统计不兼容的 API
- 检查第三方依赖兼容性
- 评估工作量
### 阶段 2：准备
- 添加废弃 API 警告
- 升级兼容的依赖
- 更新测试
### 阶段 3：升级
- 升级 React 版本
- 修复不兼容代码
- 全面测试
### 阶段 4：清理
- 移除废弃代码
- 更新文档防止新债务
代码审查
Review 时关注：
- 代码复杂度
- 测试覆盖
- 是否引入新债务
架构评审
重大变更前：
- 评估架构影响
- 讨论替代方案
- 记录决策
技术分享
定期分享：
- 最佳实践
- 踩坑经验
- 新技术学习
总结
技术债务管理是平衡艺术：
| 过度偿还 | 影响 |
|---|---|
| 偿还不足 | 维护成本持续上升 |
| 过度偿还 | 业务迭代受阻 |
关键原则：
- 承认债务：不假装它不存在
- 记录债务：维护债务清单
- 评估优先级：影响大的先处理
- 持续偿还：不要等积重难返
- 防止新债务：代码审查、架构评审
技术债务不可怕，失控才可怕。