评审效能度量什么
代码评审是质量的先行环节，可观察的量包括首次评审响应时长、评审轮次、单个提交的规模分布，以及「评审覆盖率」——多少合并请求经过了实际评审。目标是缩短反馈回路，而不是增加评审环节数量。需要警惕的反向信号是大量提交在无评审的情况下合入，这通常意味着评审流程已经形式化，与文档描述不一致。
观察指标
| 首评响应时长 | 从提交到收到第一条评审意见的时间 |
|---|---|
| 评审轮次 | 一个提交经历的往返次数 |
| 提交规模 | 改动行数的分布，影响评审质量 |
| 评审覆盖率 | 经实际评审后合入的比例 |
| 红线信号 | 大量提交静默合入，评审形式化 |
典型使用场景
- 反馈速度优化：首评时长偏长时，检查评审人分配与通知机制
- 提交规模治理：大规模改动集中出现时，推动拆分与提前对齐设计
- 轮次偏多排查：轮次高往往说明前置沟通不足，而不是评审要求严格
- 覆盖率核查：发现长期无评审的合并路径，评估其风险等级
- 评审人分布：查看是否集中在少数人身上，避免形成瓶颈
提交规模参考
提交规模参考
# 规模与评审体验的关系（经验参考，非硬性标准）
200 行以内 首评通常在一小时内，意见质量较高
200 到 400 行 常见半天内完成，需要评审人安排专门时间
400 行以上 建议拆分，或先对齐设计再提交实现异常信号与处理
| 信号 | 可能原因 | 处理方向 |
|---|---|---|
| 首评时长持续偏长 | 评审人负载高或分配不均 | 调整评审人池与轮换机制 |
| 轮次特别多 | 前置沟通不足，需求未对齐 | 提交前先对齐设计要点 |
| 提交规模普遍偏大 | 缺少拆分习惯或需求本身过大 | 按功能点拆分，先合基础设施改动 |
| 评审覆盖率偏低 | 存在绕过流程的合并路径 | 核查分支保护配置 |
| 评审集中在一两人 | 知识集中，效率瓶颈 | 扩大评审人范围，轮换参与 |
轮次多不一定代表评审严格：更常见的原因是作者与评审人对方案的理解不一致。前置对齐设计要点，通常比提高评审标准更能减少往返。
这些指标用于调整流程，不用于评价个人：按人统计评审速度会诱导快速通过、草率批准，反而削弱评审的实际作用。
落地检查清单
- 分支保护配置确保关键路径必须经过评审
- 评审人分配机制避免集中在少数人
- 提交规模在团队约定中有明确建议
- 指标用于流程改进，不用于个人排名