跳到主要内容

技术债务管理

场景​

项目积累了大量技术债务：过时的依赖、重复代码、缺失的测试、hacky 的临时方案。如何系统性地管理和偿还技术债？

方案设计​

1. 技术债务分类​

类型示例影响
代码债务重复代码、魔法数字、过长函数维护成本高
架构债务职责不清晰、耦合严重新功能开发慢
依赖债务过时的框架/库版本安全风险、兼容问题
测试债务没有测试或覆盖率低改动怕出 bug
文档债务缺少文档或文档过时新人上手困难
工程债务构建慢、没有 CI/CD开发效率低

2. 优先级评估矩阵​

优先级条件处理方式
P0影响大 + 成本低立即修复
P1影响大 + 成本高排入迭代计划
P2影响小 + 成本低日常开发顺手修
P3影响小 + 成本高记录但暂不处理

3. 偿还策略​

## 技术债务偿还策略

### 日常偿还（持续）
- Boy Scout Rule：改到的文件顺手改善
- 新代码必须符合规范
- Bug 修复时同步补测试

### 专项偿还（定期）
- 每个迭代预留 15-20% 时间做技术改进
- 每季度一次集中还债（如依赖升级周）
- 重大债务作为独立项目排期

### 预防增加
- Code Review 拦截新增债务
- 定义 "完成的定义"（Definition of Done）
  - 有类型注解
  - 有单元测试
  - 不引入 ESLint 警告

4. 债务看板​

## 技术债务追踪表

| ID | 描述 | 类型 | 优先级 | 预估工时 | 状态 |
|----|------|------|-------|---------|------|
| TD-001 | 升级 React 17 → 18 | 依赖 | P1 | 5d | 进行中 |
| TD-002 | utils 目录重构 | 代码 | P2 | 2d | 待处理 |
| TD-003 | 补充用户模块测试 | 测试 | P1 | 3d | 待处理 |
| TD-004 | 移除废弃的 API 调用 | 代码 | P0 | 0.5d | 已完成 |

常见面试问题​

Q1: 如何说服领导投入时间还技术债？​

答案：

用业务语言而不是技术语言：

  • "依赖版本过旧有安全漏洞，可能导致用户数据泄露"
  • "构建时间 5 分钟，每天 50 次部署浪费 250 分钟"
  • "现在加一个简单功能需要 3 天，还完债后只要 1 天"
  • "新人入职需要 2 周才能上手，文档完善后缩短到 3 天"

关键是量化：把债务转化为时间和金钱成本。

Q2: 如何避免技术债的积累？​

答案：

  1. Definition of Done：每个需求必须包含代码、测试、类型注解、文档
  2. Code Review：拦截质量不达标的代码
  3. 定期清理：每个迭代预留技术改进时间
  4. 架构治理：定期评审架构合理性，及时调整
  5. 不妥协：拒绝"先这样吧，后面再改"（如果确实要妥协，必须创建债务 record）

相关链接​