Skip to content
返回维护与 LTS

技术债优先级

按利率（复合多快）和本金（偿还成本）排序债，而非按谁喊得响。

为什么

并非所有债相等，先还错债和不还一样糟。重复工具函数（低利率 — 不增长）可等，而未测支付路径（高利率 — 每个新功能加未测分支）日日复合。经济框架 — 本金（修几小时）和利率（多快阻塞新工作）— 让你客观排序而非按谁最后抱怨。高利率低本金债是最佳先还：小努力大解锁。高本金低利率债可无限延。这与金融债同理：先还高 APR 信用卡再还低 APR 房贷。

何时使用

债清单 >10 项时。每季度或出现新高利率债时重排。

如何做

1. 每项债估本金（修几小时）和利率（多阻塞下个功能，1-5）
2. 算优先级 = 利率 / 本金（高利率低本金 = 先还）
3. 分桶：立即还（高比）| 下季度还（中）| 接受（低比、旧）
4. 立即还内按爆炸半径排：支付/认证/数据丢失债先于 UI 债
5. 把立即还项排进下 2 个 sprint 作显式工单，而非"有空时"
6. 每次还后重评：利率降了吗？有时还一项暴露更高的一项

示例

# 债优先级矩阵
| ID  | 本金   | 利率 | 比值  | 桶         |
|-----|--------|------|-------|------------|
| D2  | 4h     | 5    | 1.25  | 立即还     | # 未测支付
| D7  | 2h     | 4    | 2.00  | 立即还     | # 认证绕过风险
| D1  | 2h     | 2    | 1.00  | 下季度     | # 重复校验
| D3  | 16h    | 2    | 0.13  | 接受       | # react 大版本（延）
| D5  | 8h     | 1    | 0.13  | 接受       | # 旧 CSS 框架

# 把立即还排进 sprint（非"空闲时"）
Sprint 42: D7（认证绕过，2h）— 安全，先做
Sprint 43: D2（支付测试覆盖，4h）

# 在 DEBT.md 显式接受 D3/D5：
# "D3 react@16：2024-03-15 接受，Q3 升级窗口 revisit"

常见问题

  • ⚠还最响的债（资深开发抱怨的）而非最高利率 — 感觉有产出实则不然。
  • ⚠先还高本金低利率债（大重写）— 占一 sprint 且解锁效果最小。
  • ⚠无接受桶 — 每项债永远"待做"，清单失可信且人们不再用。

最佳实践

  • ✓按利率/本金比值排 — 这是个人理财中先还高 APR 债的偿债类比。
  • ✓始终有显式"接受"桶 — 带 revisit 日期接受债是决策；留模糊不是。
  • ✓把立即还债排成带工时估的 sprint 工单而非愿望清单 — 不排的债不还。