多仓多项目先对齐口径
组织里有多仓库、多项目时，度量的第一步不是拿数字对比，而是先对齐口径：统计窗口是滚动三十天还是自然月、工具与版本是否一致、是否排除生成代码与第三方目录、门禁规则是否等价。口径不同就对比，等于拿两把刻度不同的尺子量同一根柱子。
基本信息
| 对齐项 | 工具链、统计窗口、排除规则、门禁定义 |
|---|---|
| 分组 | 按语言与项目类型分组比较 |
| 例外 | 跨技术栈只做趋势观察，不做排名 |
| 文档 | 口径写成可复现的说明，随报表一起发布 |
典型使用场景
- 平台建设：统一扫描配置与排除规则，让各仓数据可比
- 汇报：按语言与项目类型分组展示，避免跨栈排名
- 门禁推广：先在一个分组内统一阈值，验证后再扩到其他分组
- 新仓接入：接入检查清单里固化口径项，防止新项目自带一套
- 差异复盘：跨组差异先归因到技术栈与业务形态，再谈执行差异
分组报告示例
分组报告示例
# 分组 A（Java 服务）：覆盖率、圈复杂度、技术债比例
# 分组 B（前端应用）：包体积预算、静态检查门禁、可访问性
# 分组 C（数据脚本）：仅基础检查，不做复杂度门禁
# 跨组报表：只展示趋势方向（上升或下降），不做排名口径项与常见差异
| 口径项 | 常见差异 | 统一办法 |
|---|---|---|
| 统计窗口 | 滚动 30 天与自然月混用 | 统一为滚动窗口并写进报表标题 |
| 排除规则 | 是否含生成代码与测试代码不一致 | 排除规则集中配置，随仓库分发 |
| 工具版本 | 不同语言用不同扫描器与版本 | 按语言固定版本，升级时同步 |
| 阈值来源 | 各仓自行定义 | 按分组统一，例外需书面说明 |
分母比分子更容易出错：覆盖率的分母是「可执行的代码行」，不同工具对生成的代码、抽象方法与纯声明行的处理并不一致，跨项目比较前先确认分母定义是否相同。
跨语言直接排名会激励错方向：后端语言的复杂度基线天然高于函数式或前端代码，用同一阈值考核会把团队推到「为拆而拆」的表演性重构上。