代码评审不能依赖一个人

我曾经在一段时间里评审团队的大部分代码。

项目刚开始建设，成员对业务、框架和代码标准的理解还不一致。由相对熟悉全局的人集中评审，能够尽快发现问题，也能避免不同模块在早期形成完全不同的实现方式。

这种方式在初期很有效，时间长了却会产生另一个问题：几乎所有代码都在等待同一个人。

集中评审为什么有效

新团队需要建立共同尺度。

哪些业务对象应该复用，异常怎样处理，接口如何兼容，什么逻辑应该放在公共层，这些问题无法只靠格式规范解决。集中评审让同一个判断能够较快覆盖多个模块，也便于发现项目之间的重复实现。

对负责人来说，Review 还是理解系统变化的一种方式。即使没有亲自参与每项开发，也能持续知道模型、依赖和风险发生了什么变化。

因此，集中评审本身并不是问题。问题在于它是否只是一个阶段。

当提交数量增加，评审会不断挤占其他工作。开发完成以后等待 Review，紧急需求又会压缩评审时间。为了不影响进度，负责人容易快速扫过代码，只检查明显错误。

这时集中评审已经失去最初作用。它仍然保留一道流程，却无法提供足够深入的判断。

更隐蔽的影响是，团队成员会逐渐把代码质量理解为评审者的责任。只要最后有人把关，提交之前就不必完成同等强度的自查。负责人越认真，团队反而越可能依赖这个人。

代码风格、空指针和常见错误可以借助静态检查。人更应该关注工具难以判断的部分：实现是否符合业务含义，边界是否清楚，失败路径有没有处理，修改是否破坏已有约定，以及未来的人能否理解这段代码为何存在。

这要求评审者了解上下文。不了解需求的人可以发现局部代码问题，却很难判断模型是否正确。因此，不能简单把所有提交随机分配给任何成员。

更合适的方式，是让熟悉相邻模块的人交叉评审，关键设计由负责人把关，常规实现则逐步交给团队共同承担。

同一个问题反复出现在 Review 中，说明只靠评论没有形成改变。

可以自动检查的，应进入工具；属于共同约定的，应写进简短规范或示例；涉及设计能力的，则需要在评审中解释原因，而不是只留下“请修改”。

一次评论解决一段代码，解释判断依据才可能影响下一次实现。

让更多成员参与评审，不等于立即平均分配责任。

可以先从熟悉模块开始，让提交者说明改动背景和风险，再由其他成员给出意见。负责人继续观察关键变更，但不再成为每次合并的唯一前置条件。

这个过程会暂时增加沟通成本，也可能出现判断不一致。只有经过这些讨论，团队才会真正建立共同尺度。

代码评审的目标不是保证所有问题都由某个人发现。更稳定的结果，是让代码质量不再依赖某个人一直在场。