技术债的度量：量化指标与TDR计算方法
聊完了技术债的分类和成因，咱们得面对一个更现实的问题——怎么量化它？
说实话，我见过不少团队，一提到技术债就头疼。大家心里都清楚代码烂，但到底烂到什么程度？没人说得清。没有量化，就没有管理。这是我做架构治理这些年最深的一个体会。
今天咱们就聊聊三个最核心的量化指标：代码复杂度、测试覆盖率、模块耦合度。最后再讲一个综合指标——技术债比率（TDR）。
代码复杂度：最直观的“坏味道”
代码复杂度，说白了就是一段代码有多难理解、多难改。我个人习惯用圈复杂度（Cyclomatic Complexity）来衡量。
圈复杂度的计算其实很简单：它等于代码中独立路径的数量。一个函数里if-else越多、循环越多、case分支越多，圈复杂度就越高。
我记得有一次接手一个遗留系统，有个函数叫processOrder()，光if-else嵌套了8层，圈复杂度算出来是47。我当时就倒吸一口凉气——这种代码，改一个地方，你根本不知道会炸到哪里。
圈复杂度的参考标准，我一般这么看：
| 圈复杂度 | 风险等级 | 建议 |
|---|---|---|
| 1-10 | 低风险 | 代码清晰，容易维护 |
| 11-20 | 中风险 | 需要关注，考虑重构 |
| 21-40 | 高风险 | 强烈建议重构 |
| 40以上 | 极高风险 | 必须重写，不可维护 |
你想想看，一个圈复杂度超过40的函数，测试用例得写多少个才能覆盖全路径？基本不可能。这就是技术债的典型表现。
测试覆盖率：你的“安全网”有多密？
测试覆盖率，这个指标大家应该不陌生。但我想说的是——别只看数字。
我曾经见过一个项目，测试覆盖率报告显示85%，团队上下都很满意。结果上线后出了个大Bug，一查才发现，那85%覆盖的都是getter/setter和工具类，核心业务逻辑几乎没测。
所以，我建议关注两个维度：
- 行覆盖率（Line Coverage）： 代码中有多少行被执行过。这个指标比较粗，但能反映整体情况。
- 分支覆盖率（Branch Coverage）： 每个if-else、switch-case分支是否都被覆盖到。这个更严格，也更有价值。
我个人对测试覆盖率的底线是这样的：
- 核心业务逻辑：分支覆盖率不低于80%
- 普通模块：行覆盖率不低于60%
- 工具类、配置类：不低于30%就行，别浪费精力
模块耦合度：牵一发而动全身
模块耦合度，衡量的是你的代码模块之间有多“粘”。耦合度越高，改一个地方就越容易影响到其他地方。
常用的量化指标有：
- 扇入（Fan-in）： 有多少个模块依赖当前模块。扇入高说明这个模块被广泛使用，改动要格外小心。
- 扇出（Fan-out）： 当前模块依赖了多少个其他模块。扇出高说明这个模块职责不清晰，什么都依赖。
- 不稳定度（Instability）： 计算公式是 I = Fan-out / (Fan-in + Fan-out)。值越接近1，说明模块越不稳定，越容易被影响。
我记得在一个微服务项目里，有个“订单服务”的扇出高达30多，几乎依赖了所有其他服务。每次其他服务接口一改，订单服务就得跟着改。这就是典型的耦合度过高。
怎么解？说白了就是“依赖倒置”——让高层模块依赖抽象，而不是依赖具体实现。这个咱们后面讲架构治理的时候再细聊。
技术债比率（TDR）：一个综合的“体检报告”
前面三个指标都是单点指标，各有侧重。但作为技术产品经理，你更需要一个综合指标来向老板汇报、跟业务方沟通。这时候，技术债比率（Technical Debt Ratio, TDR）就派上用场了。
TDR的计算公式其实不复杂：
TDR = 修复技术债所需的工作量 / 重新开发整个系统所需的工作量 × 100%嗯，这里要注意，这个“工作量”不是精确的工时，而是一个估算值。实践中，我们通常用代码行数或功能点来近似。
举个例子：
- 当前系统总代码量：100,000行
- 其中“坏代码”（需要重构的）约：15,000行
- 修复这些坏代码的预估工作量：约3人月
- 重新开发整个系统的工作量：约20人月
那么 TDR = 3 / 20 = 15%。
TDR的参考标准，我一般这么看：
| TDR值 | 健康状态 | 建议行动 |
|---|---|---|
| < 5% | 健康 | 正常维护即可 |
| 5% - 15% | 可控 | 需要关注，制定改进计划 |
| 15% - 30% | 高风险 | 必须投入专项资源治理 |
| > 30% | 危险 | 考虑系统重写或重大重构 |
怎么把这些指标落地？
指标再好，落不了地也是白搭。我建议分三步走：
- 工具化： 用SonarQube、CodeClimate等工具自动采集这些指标，别靠人工统计。
- 可视化： 做成看板，每周更新。让团队和老板都能看到趋势。
- 设红线： 比如圈复杂度超过20的代码不能合入主干，TDR超过15%要触发专项治理。
嗯，最后说一句。这些指标不是用来“考核”开发同学的，而是用来帮团队做决策的。你想想看，如果TDR已经到25%了，你还催着团队赶新功能，那不是逼着他们继续借债吗？
作为技术产品经理，你的职责就是把这些数据翻译成业务语言，告诉老板：“咱们现在欠了这么多技术债，如果不还，明年新功能的上线速度会下降30%。” 这才是量化指标真正的价值。