评审体量研究说的是什么
评审体量研究（SmartBear 的代码评审著作）给出的是一个方向性结论：单次审查超过约 400 行之后，缺陷发现率明显下降；一次评审持续超过约 60 分钟，注意力也会衰减。这些数字是参考值而不是法规，但它说明一件事——把大改动拆成可消化的批次，比要求评审者更用力更有效。
基本信息
| 来源 | SmartBear《Best Kept Secrets of Peer Code Review》 |
|---|---|
| 体量参考 | 单次审查约 400 行以内缺陷发现率更高 |
| 时间参考 | 单次评审建议控制在 60 分钟以内 |
| 使用方式 | 作为拆分与排期的依据，不用于个人考核 |
典型使用场景
- 上千行的功能分支：按提交意图切成若干批，每批独立可合并
- 一人同时负责多个模块：把评审拆到不同时段，避免连续长时间阅读
- 发布前的集中送审：提前分批，不要让改动堆到窗口期
- 新人第一次写大改动：老手先陪看结构，再看细节
- 研究数字与团队实际冲突：以缺陷逃逸率等真实数据校准
拆分时的注意点
- 每批主题自洽：一批只解决一件事，评审者才建得起上下文
- 批与批之间保持可合并状态：避免长期挂着的半成品分支
- 机械改动单独成批：重命名与格式化不要和逻辑改动混在一起
- 拆分不减总量：只是把认知负担分散到时间里
体量问题的典型症状
| 现象 | 可能原因 | 调整方向 |
|---|---|---|
| 意见集中在文件开头 | 读到后段注意力已经耗尽 | 拆成更小的批次 |
| 多轮仍在反复 | 改动太大，上下文建不起来 | 先对齐方案再逐批审 |
| 漏掉的缺陷集中在尾部文件 | 尾部文件几乎没被细读 | 按风险排序，高风险文件优先 |
查看改动体量
查看改动体量
git diff --shortstat main...HEAD # 总行数概览
git diff --stat main...HEAD # 逐文件行数分布
git diff --numstat main...HEAD | sort -k1 -n -r | head # 改动最大的文件研究数字用来说明方向：过大的评审单位会系统性地漏掉缺陷，而不是说 401 行就一定有问题。
拆批改变的是注意力分配：把 800 行分成两批各 400 行，总工作量不变，缺陷发现率却明显不同。