审查流程与角色：让代码审查有序运转

代码审查这件事，说起来简单——就是让人看代码嘛。但真正落地的时候，你会发现流程混乱、角色不清、时间失控，最后变成一场形式主义的走秀。

我见过太多团队，审查就是「代码写完了，你帮我瞅一眼」。结果呢？要么拖到上线前才匆匆扫过，要么 reviewer 和作者互相甩锅。今天我们就聊聊，怎么让审查流程真正跑起来。

审查流程：四个阶段，一个闭环

我个人习惯把审查拆成四个阶段：准备 → 审查 → 返工 → 验证。少一个都不行。

第一阶段：准备

别急着把代码丢给 reviewer。作者自己先过一遍，这是基本素养。

• 自检清单：代码能编译通过吗？单元测试跑过了吗？有没有遗留的 TODO 或调试代码？
• 提交说明：写清楚「改了啥、为什么改、怎么改的」。我见过最离谱的提交说明就两个字：「修复」——修复啥？鬼知道。
• 控制范围：一次审查的代码量，别超过 400 行。超过这个数，reviewer 的大脑就开始罢工了。

第二阶段：审查

这是 reviewer 的主场。但注意，审查不是找茬，是协作。

• 先看整体，再看细节：先理解代码要解决什么问题，再去看具体实现。别一上来就揪着变量命名不放。
• 关注逻辑，而非风格：风格问题交给 linter 和 formatter。人的精力应该花在逻辑漏洞、边界条件、性能隐患上。
• 给出具体建议：别说「这段代码不好」，要说「这里用 HashMap 可能更合适，因为查询频率高」。

我在项目中遇到过一位 reviewer，每次评论都是「建议优化」。优化什么？怎么优化？全靠猜。这种评论，说白了就是没走心。

第三阶段：返工

作者收到反馈后，开始修改。这里有个常见误区：不是所有建议都要采纳。

• 区分「必须改」和「可以改」：逻辑错误、安全隐患必须改。代码风格、个人偏好，可以讨论。
• 及时回复：哪怕不采纳，也要说清楚原因。「我觉得这里保持原样更好，因为...」——这样 reviewer 才会觉得被尊重。
• 别拖太久：返工超过 2 天，上下文就丢了。我建议当天或次日完成修改。

第四阶段：验证

返工完就完事了？不行。reviewer 需要确认修改是否到位。

• 二次审查：只看修改的部分，别把整个文件再看一遍。除非改动太大。
• 确认无副作用：改 A 会不会影响 B？这是验证阶段最容易忽略的。
• 打上「已通过」标签：明确告诉作者，可以合入了。

审查者与作者的职责

很多团队审查效率低，就是因为角色职责不清。我列个表，一目了然。

角色	核心职责	常见误区
作者	提交高质量代码、写清楚说明、及时返工	「反正 reviewer 会看，我先提交再说」
审查者	理解上下文、发现逻辑问题、给出建设性意见	「这代码风格我不喜欢，重写」
双方	保持尊重、聚焦问题、及时沟通	「你写的代码真烂」vs「你懂个屁」

你想想看，如果作者提交的代码连编译都过不了，reviewer 还要花时间帮你找编译错误——这合理吗？

审查节奏与时间控制

审查最怕什么？怕拖。一拖，上下文丢了，热情没了，质量也下去了。

时间窗口

• 审查请求发出后：reviewer 应在 4 小时内响应。哪怕只是说「收到，明天上午看」。
• 单次审查时长：不超过 60 分钟。超过这个时间，注意力就开始下降。
• 返工周期：建议 1 天内完成。复杂修改不超过 2 天。

节奏控制

我建议团队约定一个「审查窗口期」。比如每天上午 10:00-11:00 是审查时间，大家集中处理。这样既不会打断开发节奏，也不会让审查无限期拖延。

避坑指南

• 别在周五下午提交审查请求：除非你想让代码在 reviewer 的待办列表里躺到下周一。
• 别一次提交 1000 行以上的代码：没人能认真看完。拆成多个小提交，每个 200-300 行。
• 别在 deadline 前搞大规模审查：压力下的审查，要么流于形式，要么引发冲突。

我曾经在项目上线前三天，收到一个 2000 行的审查请求。你猜我怎么做的？我直接拒绝了。不是我不负责任，而是这种审查毫无意义。后来我们约定：上线前 48 小时，不再接受新的审查请求。

总结一下

审查流程不是死板的教条，而是为了让协作更顺畅。准备阶段花点心思，审查阶段聚焦逻辑，返工阶段及时响应，验证阶段确认到位。角色清晰，节奏合理，审查才能真正发挥作用。

说白了，代码审查不是「找茬游戏」，而是「质量共建」。你想想看，如果每个人都能认真对待这四个阶段，团队的代码质量会差到哪里去？