代码评审怎么做才有效：分工、粒度与反模式

一、代码评审为什么常常流于形式

代码评审几乎存在于所有研发团队，但评价却两极分化。有的团队把它当成质量防线，有人觉得它浪费时间、拖慢进度、还会引发争论。

问题通常不在「要不要评审」，而在「评审什么、怎么评审、评审到什么程度」。当评审没有明确的范围和分工时，它就会退化成两种极端：一种是走过场，看一眼点个通过；另一种是逐行挑毛病，把评审变成个人风格的争论。两者都消耗了时间，却没有带来对应的质量收益。

这篇文章讨论的是三个具体问题：评审与自动化检查该如何分工、评审的范围与粒度怎么定、有哪些反复出现的反模式。理解了这三点，代码评审才能从形式回到它本来的位置——一条低成本、可持续的质量防线。

关于我们整体的工程实践，可以先参考 工程与质量保障。

二、评审和自动化检查的分工

有效评审的第一个前提，是搞清楚「什么是机器该做的、什么是人该做的」。

自动化能做的事，尽量不要留给人。因为人做机械检查既不可靠，也不经济。适合交给自动化的包括：

• 格式与风格：缩进、命名约定、导入顺序。这类问题有确定答案，交给格式化工具即可。
• 静态检查：空指针风险、未使用变量、明显的类型问题、常见缺陷模式。
• 编译与单元测试：能不能编译、测试是否通过，这是硬门槛。
• 依赖与安全扫描：已知漏洞的依赖版本、许可证问题。

把这些问题挡在评审之前，评审时就不必再讨论它们。反之，如果团队还在评审里争论缩进和命名，说明自动化环节缺位。

人应该关注的是机器判断不了的事：

• 逻辑是否正确：边界条件、异常路径、并发假设是否成立。
• 设计是否合理：模块划分、接口抽象、职责是否清晰。
• 是否贴合业务：实现是否满足业务规则，是否有理解和实现上的偏差。
• 可维护性：这段代码半年后还看得懂吗，改起来会不会牵连一片。

一句话概括分工：机器管「对不对」，人管「好不好、合不合适」。这条线划清楚，评审效率会明显提升。

三、评审范围与粒度怎么定

评审到什么程度，比评审本身更影响体验。

关于范围：一次评审的改动量不宜过大。改动几百行甚至上千行的提交，评审者很难真正看清逻辑，往往只能抽查，等于没审。比较可行的做法是把大改动拆成多个小提交，每个提交聚焦一件事。小改动审得快、看得清，也更容易回滚。

关于粒度：不是每一行都值得讨论。评审应聚焦在「会带来风险或长期成本」的地方：核心业务逻辑、数据一致性相关的代码、权限与安全相关的代码、被公共依赖的接口。而纯粹的文案调整、注释补充、简单配置，可以快速通过。

关于频率：评审应该尽早、尽快。提交后放置几天再评审，作者自己都忘了当时为什么这么写，评审者的反馈也很难被及时吸收。小步快跑，比攒成一个大批次更有效。

关于时间：一次评审不宜过长。连续评审超过一定时间后，注意力会明显下降，漏检率上升。与其一次审两小时，不如分两次，每次集中半小时。

这些原则的共同点是：降低单次评审的认知负担。评审的效果和评审者的专注度高度相关，而专注度是有限的。

四、评审时该关注什么

如果没有明确的检查方向，评审很容易滑向「找能挑的地方」。

可以从几个固定的角度切入，形成习惯：

正确性。代码有没有实现预期逻辑？边界条件（空值、零、越界、超大输入）处理了吗？异常路径有兜底吗？错误是被吞掉了还是被正确传播了？

安全性。有没有把用户输入直接拼进查询或命令？权限校验是不是在正确的层级做的？敏感信息有没有被写进日志？

一致性与状态。涉及多步写操作时，失败怎么处理？有没有考虑并发？重复请求会不会产生副作用？这类问题在单看某一段代码时并不明显，需要结合上下文判断。

可读性。命名是否表达了意图？复杂逻辑有没有注释解释「为什么」而不是「做了什么」？是否存在重复代码可以合并？

测试。改动是否有对应的测试？测试覆盖的是关键路径还是边角？测试本身是否可靠（会不会偶发失败）？

把注意力放在这五类上，评审会更有针对性，也更少变成风格之争。

五、常见的反模式

在真实团队里，有几类反模式反复出现，值得单独点出来。

反模式一：把评审当质量把关的唯一环节。 如果没有自动化测试、没有静态检查，评审者就要同时承担所有检查，结果往往是「看起来都过了，但漏掉了关键问题」。评审是防线之一，不是全部。

反模式二：用评审夹带个人偏好。 「我习惯这么写，所以你也得这么写」。除非偏好被写进了团队规范并由工具执行，否则不应在评审里强制。个人风格之争最消耗团队信任。

反模式三：橡皮图章式通过。 作者一提，评审者秒过。这种评审既没有收益，还给了团队「有人审过」的虚假安全感。宁可少评，也不要假评。

反模式四：一次性抛出大量意见。 十几条意见同时提，作者难以消化，也分不清轻重。更好的做法是区分「必须改」与「建议」，并聚焦在最重要的几条上。

反模式五：只挑问题不给理由。 「这里不对」但不解释为什么，作者只能猜测，甚至照搬却不懂原理。给出理由，评审才有教育价值，而不只是拦截。

反模式六：长期只由少数人评审。 评审集中在一两个人身上，会成为瓶颈，也让知识集中在少数人手里。健康的团队应有多人具备评审能力。

反模式七：评审后的分歧无限拉扯。 有些问题没有唯一正确答案，争论超过一定轮次就应当升级到更大的决策场合，而不是在评论区拉锯。

六、评审的流程与节奏

除了内容与粒度，评审的「流程」本身也决定了它是否可持续。几个值得明确下来的环节：

异步优先，必要时同步。 大多数代码评审适合异步进行：提交后由评审者在自己方便的时间查看，作者与评审者在评论区交流。异步的好处是不打断双方的深度工作时间。但有两类情况适合同步沟通：一是涉及复杂设计取舍、评论里说不清楚；二是分歧较大、评论区已经开始拉扯。此时一次简短的当面沟通，往往比十几条评论更有效。

设定响应时限。 评审最怕的不是严格，而是拖延——提交后没人看，作者只能干等。团队可以约定一个合理的响应时限，例如「工作日当天内给出首次反馈」。这个约定能显著减少等待，也间接推动了「小提交」的习惯，因为改动小才容易及时审完。

区分阻塞性与非阻塞性意见。 明确哪些意见必须改完才能合并，哪些只是建议、可以后续处理。这个区分能避免「因为一句可改可不改的意见而卡住整个提交」的情况。惯用的做法是在意见前加显式标记，让作者一眼看出优先级。

作者也要主动。 评审不是单方面被挑错。作者可以在提交时附上说明：这次改动做了什么、为什么这么做、哪些地方自己也不确定、希望评审者重点看哪里。这一小段说明能极大降低评审者的理解成本，也让评审更有针对性。

合并前的门槛。 明确合并的前置条件：自动化检查通过、必要数量的评审通过、无阻塞性意见。门槛清楚，就不需要每次临时判断。

把评审嵌进流程而不是附加在上面。 如果评审是流程里的一个强制节点，它就会稳定执行；如果它只是「有空再做」的建议，它就会最先被牺牲。真正有效的团队，通常是把评审写进了合并规则，而不是靠自觉。

流程的意义在于：让评审成为一种稳定的习惯，而不是有时认真、有时流于形式。稳定，才有复利。

七、评审记录的价值

评审过程中产生的讨论，本身就是一种资产，但常被忽略。

它是决策的依据。 为什么这段代码要这么写、为什么当时排除了某个方案，这些信息如果只留在对话里，很快就会丢失。保留在提交记录或评审意见里，后来者能理解来龙去脉。

它是知识传递的载体。 新成员看历史评审，比看代码本身更容易理解团队的判断标准。评审里反复出现的问题，往往就是团队最需要注意的地方。

它是改进流程的输入。 如果某类问题在评审里反复被提出，说明它应该被自动化检查覆盖，或者应该被写进开发规范。评审的沉淀，能反过来减少未来评审的负担。

它是质量的证据链。 对于需要追溯的合规场景，谁审了什么、改了什么，如果能记录清楚，会显著降低审计成本。这也和我们在 技术能力 中强调的可追溯性一致。

因此，评审记录不应只写「通过」两个字。哪怕是一句「已按建议调整」或「这里有争议，已升级讨论」，也比空白有价值。

八、落地建议

想把代码评审做实，可以从几件小事开始。

1. 先补齐自动化门槛。 格式、静态检查、单元测试、安全扫描，能在提交前自动跑的就自动跑，让评审只处理机器判断不了的问题。
2. 规定单次改动的上限。 约定一次提交的合理规模，超出就拆分。这条规则对提升评审质量的作用往往立竿见影。
3. 给出评审清单。 把「正确性、安全性、一致性、可读性、测试」这五类作为固定的检查方向，贴在团队可见的地方。
4. 区分必须改与建议改。 用明确的标记区分两类意见，作者知道优先级，评审者也会更克制。
5. 控制分歧轮次。 约定超过几轮仍无共识就升级讨论，避免评论区拉锯。
6. 定期回顾评审记录。 找出反复出现的问题，把它们前移为自动化规则或团队规范。

最终目标是让评审变得轻量而持续，而不是沉重而偶发。轻量，才有可持续性；可持续，才谈得上质量改进。具体的交付与质量流程，可以参考 交付流程。

还有一条容易被忽视的建议：把评审当成团队学习的场合，而不是互相挑错的场合。评审者指出问题时说明理由，作者解释设计时讲清思路，一来一回之间，团队对代码质量的共同理解会逐步建立起来。这种共识，比任何规范文档都更能决定长期的代码质量。

九、小结

代码评审的价值不在于「有没有做」，而在于「有没有做对」。把机械检查交给自动化，把评审聚焦在逻辑、设计、安全与可维护性上；控制单次改动的规模与评审时长；避免风格之争和橡皮图章；把讨论沉淀成可追溯的记录——做到这些，评审就会成为一条真正有效、且成本可控的质量防线。

对研发团队来说，评审习惯的养成需要时间，但一旦形成，质量收益会持续累积。如果团队正在梳理研发流程或质量规范，也可以参考我们的 软件研发服务 与 常见问题 中的相关说明。