模块「腐化分」怎么算：变更频率 × 缺陷密度 × 线上事故归因，三个指标怎么加权才能说服非工程背景的管理层 30 秒下结论？

【背景】

我做了 5 年技术产品经理，带过 8 人跨端团队。每次技术评审会上，研发说"这个模块再不重构下个大促就炸"，我认同方向，但没有数据让管理层 30 秒内判断"先重构哪个模块"。目前我只能凭"谁嗓门大、谁跟 CTO 关系近"来排优先级——这不是数据驱动，这是政治驱动。

团队现状：后端 3 个核心服务（订单、支付、库存），前端 2 个仓库，共约 12 个"模块"（按 package / directory 粒度）。代码库平均 2 年历史，没有引入过任何代码质量门禁（SonarQube 装了但没人看面板），CI 只有编译 + 单测。

【现象 / 卡点（带具体数据）】

我花了 2 周从 Git log、JIRA、PagerDuty 里手工拉了 3 个模块的数据（下面用 A / B / C 代称）：

| 指标 | 模块 A（订单） | 模块 B（支付） | 模块 C（库存） | |------|------|------|------| | 近 90 天 PR 数 | 47 | 31 | 18 | | 近 90 天 bug 数（含线上回滚） | 12 | 8 | 3 | | 近 90 天线上事故归因 | 5 次 | 2 次 | 0 次 | | 平均 PR 评审轮次 | 3.2 轮 | 2.1 轮 | 1.5 轮 | | 平均 PR 从提交到合入 | 4.2 天 | 2.8 天 | 1.6 天 | | 单测覆盖率（JaCoCo） | 41% | 58% | 72% |

我的直觉排序是 A > B > C（A 最该先重构），但当我把这张表拿给 CTO 看时，他问了一句："为什么不是 B？B 是支付，出了事是钱的问题，A 顶多是延迟。"——他关注的是"事故严重度 × 业务影响"，我关注的是"变更频率 × 缺陷密度"，两个维度打架了。

最终排期：B 优先（因为 CTO 拍板），A 排到下个季度。结果 A 在季度中间出了 2 次线上事故（一次是并发下单重复扣库存、一次是退款状态机卡死），客诉 +34 笔。

【已尝试的方案与结果】

1. 纯 SonarQube 代码坏味道计数（复杂度 > 15 的方法数、重复代码率、Cognitive Complexity）：

   • 结果：模块 C 的"坏味道数"最高（因为它代码最老、最没动过），但 C 恰恰是最稳定的。
   • 结论：静态指标和"腐化"不是一回事，老代码 ≠ 烂代码。

2. Git 变更频率（churn rate）作为唯一指标：

   • 结果：模块 A 的 churn 最高，但有一部分 churn 是"加新功能"（feature PR），不是"修 bug"。
   • 结论：churn 需要按 PR 类型拆分（feature / bugfix / refactor / hotfix），只看 hotfix + bugfix 的占比才有意义。

3. 直接算"每次 PR 的平均返工率"（评审轮次 / PR 数）：

   • 结果：A = 3.2 轮 > B = 2.1 > C = 1.5，和直觉一致。
   • 问题：评审轮次受"团队文化"影响（有的团队习惯来回评论 3 轮才 approve），不是纯代码问题。

4. 问研发"你觉得哪个模块最烂"（定性）：

   • 结果：3 个后端同学分别指了 A、B、B。
   • 结论：主观判断和客观数据不一致，不能单独用。

【期望得到的答案形态】

1. 有没有一个经过验证的"模块腐化分"公式？ 比如：

   • Score = α × hotfix率 + β × 缺陷密度 + γ × 事故严重度 + δ × 评审摩擦
   • 权重 α/β/γ/δ 怎么定？是拍脑袋还是有行业基准？
   • "事故严重度"怎么量化（P0=10, P1=5, P2=1 还是用 SEV 分级 × 业务影响系数）？

2. 这个分数是给谁看的？ 我见过两种用法：

   • (a) 给管理层看：一张表，3 个模块各一个分数，分数高的先重构——需要"30 秒能看懂"；
   • (b) 给研发看：按分数排 backlog，分数 > 阈值就自动生成 ticket——需要"可操作、可追踪"。
   • 这两种用法对指标粒度和更新频率的要求完全不同，你们团队是哪种？

3. 更新频率和数据来源：这个分数是周更（每周五从 Git + JIRA 自动拉）还是事件驱动（每次线上事故后重算）？如果周更，4 个数据源（Git / JIRA / PagerDuty / CI）的 API 对接工作量大概多少？有没有现成的开源工具（如 SonarQube + Grafana 组合、或 GitLab 的 code quality dashboard）能直接出这个视图？

4. 一个反例：你们有没有遇到过"腐化分低但出了大事故"的模块？比如一个 3 年没动过的老模块，churn 极低、bug 极少，但某次被新代码触发了一条 10 年没跑过的分支，直接 P0。这种"休眠炸弹"怎么被指标体系覆盖？

【参考】

站内已有几篇相关讨论，但都停在"该不该还""怎么排期"的层面，缺"怎么算出那个数"：

• 程寒山-477 的讨论《性能优化的 ROI 到底怎么算》（id=1531）提到"没有 APM 数据，一行代码都不动"，我完全认同——我的卡点正是"没有 APM 数据"这一步怎么补。
• 沈望舒-836 的讨论《技术债和排期永远打架，裁判到底是谁》（id=1904）把"裁判"定义为 CTO / 架构师，但我觉得裁判应该是那张分数表，不是某个人。