技术债比率怎么看
技术债比率（Technical Debt Ratio）的常见口径是：把静态分析识别出的全部问题按内置成本模型折算成修复工时，再除以对该系统做一次全量重写的估计工时。结果以百分比表示，例如百分之三意味着修复全部已识别问题的工作量约等于重写成本的三十分之一。它适合观察宏观趋势与支撑预算讨论，具体该做什么仍要落到模块级分布与变更频率。
口径与用法
| 公式 | 已识别问题的修复工时估计除以全量重写工时估计 |
|---|---|
| 修复工时 | 由工具内置的规则成本模型折算，非人工实测 |
| 适用 | 同一系统版本之间的趋势观察，以及宏观投入讨论 |
| 不适用 | 跨语言、跨工具直接比较数值 |
典型使用场景
- 版本趋势汇报：观察比率随发布周期的变化，判断新增问题与清理速度的相对关系
- 宏观预算讨论：用比率的量级说明债务规模，避免逐个问题争论
- 模块下钻入口：由整体比率倒查贡献最大的模块，再结合变更频率排序
- 质量目标设定：把降低比率作为长期方向，同时配可验证的模块级指标
- 重写决策参考：极端值可作为替换或重写讨论的输入之一
解读示例
解读示例
# 比率读数
TDR 3% → 修复全部已识别问题约等于重写的 3% 工作量
# 不能停在平均数
分布：问题集中在 12 个模块中的 2 个，且都是高频改动模块
结论：优先处理这两个模块，其余按趋势观察
# 交叉验证
高频 + 高债务 = 优先处理；低频 + 高债务 = 可考虑冻结维护读数与对应动作
| 观察 | 含义 | 动作 |
|---|---|---|
| 比率持续上升 | 新增问题速度快于清理速度 | 收紧新代码门禁，先止住增量 |
| 比率下降但事故增多 | 可能只是关闭了问题条目 | 核对条目状态变更与修复提交是否对应 |
| 比率平稳但热点集中 | 平均数掩盖分布问题 | 按模块下钻，优先处理高频模块 |
| 跨版本数值跳变 | 规则集或成本模型变更 | 确认分析配置是否变化，再做趋势比较 |
| 极端高值 | 可能是生成代码未排除 | 先排除生成目录再重新分析 |
成本模型是估计值，不同工具与语言版本的折算系数不同，因此该比率适合看同一系统在同一配置下的趋势，不适合做跨团队横向排名。
把技术债比率当作团队考核指标会诱发关闭问题而非修复问题：条目被标记为误报或延期，数字好看起来而代码没有变化。指标只有作为决策输入时才有意义。
落地检查清单
- 分析配置与规则集在比较期间保持一致
- 生成代码与第三方代码已排除
- 报告同时给出模块级分布，而不只有总数
- 数值变化有归因说明，能对应到具体提交或配置变更