项目刚开始建设时，成员对业务、框架和代码标准的理解还不一致，我有一段时间评审了团队的大部分代码。这能尽快发现问题，也避免各个模块一开始就采用完全不同的做法。
初期效果不错，时间久了却发现，几乎所有提交都在等我评审。
集中评审为什么有效
哪些业务对象应该复用，异常怎样处理，接口如何兼容，什么逻辑放在公共层，这些光靠格式规范说不清楚。集中评审可以让不同模块采用相近的做法，也容易发现重复实现。
对负责人来说，Review 还是理解系统变化的一种方式。即使没有亲自参与每项开发，也能持续知道模型、依赖和风险发生了什么变化。
集中评审可以作为起步时的办法，但不能一直这样做。
负责人逐渐成为瓶颈
当提交数量增加，评审会不断挤占其他工作。开发完成以后等待 Review，紧急需求又会压缩评审时间。为了不影响进度，负责人容易快速扫过代码，只检查明显错误。
这时集中评审已经失去最初作用。它仍然保留一道流程，却无法提供足够深入的判断。
更隐蔽的影响是，团队成员会逐渐把代码质量理解为评审者的责任。只要最后有人把关，提交之前就不必完成同等强度的自查。负责人越认真，团队反而越可能依赖这个人。
Review 应该看什么
代码风格、空指针和常见错误可以借助静态检查。人更应该关注工具难以判断的部分：实现是否符合业务含义，边界是否清楚，失败路径有没有处理，修改是否破坏已有约定，以及未来的人能否理解这段代码为何存在。
这要求评审者了解上下文。不了解需求的人可以发现局部代码问题，却很难判断模型是否正确。因此，不能简单把所有提交随机分配给任何成员。
更合适的方式，是让熟悉相邻模块的人交叉评审，关键设计由负责人把关，常规实现则逐步交给团队共同承担。
从指出问题到形成标准
同一个问题反复出现在 Review 中，说明只靠评论没有形成改变。
能自动检查的问题交给工具，共同约定写进简短规范或示例，涉及设计判断的则在评审时解释原因。只留下“请修改”，这次代码可能改了，下次却未必知道如何处理。
负责人如何退出中心
让更多成员参与评审，不等于立即平均分配责任。
可以先从熟悉模块开始，让提交者说明改动背景和风险，再由其他成员给出意见。负责人继续观察关键变更，但不再成为每次合并的唯一前置条件。
这个过程会暂时增加沟通成本，也可能出现判断不一致。只有经过这些讨论，团队才会真正建立共同尺度。
负责人不在时，提交仍有人评审，成员也知道为什么这样改，评审才不至于只剩下等待一个人点头。