Code Review 真正值钱的不是挑 bug

Code Review 这件事，绝大多数团队都在做，但做法天差地别。有的团队把它当成质量闸门，每一行代码都认真看，review 成了每天最重要的学习时间。有的团队把它走成了形式，互相点个 approve，代码就合进去了，review 名存实亡。

差距不在工具，也不在流程，在心态。把 review 当成「挑错」的，它就永远是负担。把 review 当成「知识共享和质量对齐」的，它就成了团队进化的引擎。这篇讲怎么从前者走到后者。

为什么 Code Review 值得认真做

图：Code Review 的价值不止于挑 bug，知识流动与标准对齐才是长期收益

先说清楚它到底解决什么问题，不然没有动力坚持。

第一道防线是质量。哪怕是最好的工程师也会写错，自己看自己的代码有盲区，多一双眼睛能拦下大量低级错误。边界条件没处理、空指针、并发问题、资源泄漏，这些在跑测试之前就能被 reviewer 发现。

但质量只是表层。Code Review 更深的价值是知识流动。新人通过看老人的代码学风格和模式，老人通过看新人的代码了解新思路。一个功能分散在多个模块里，review 让团队成员了解彼此在写什么，系统知识不再锁在某个人脑子里。

第三个价值是质量标准的隐性对齐。什么是好代码、坏味道长什么样、这个团队的约定是什么，这些没法写进文档的东西，在一次次 review 里被传递和统一。一个团队代码风格的一致性，很大程度上是 review 带出来的。

图：审查顺序由大到小，红色高发区集中火力，格式细节交给 linter

看代码有个顺序，先看大的再看小的。

先理解这次改动的意图。这个 PR 要解决什么问题，方案整体对不对。如果方向就错了，细节再漂亮也白搭。很多人 review 上来就盯代码细节，指出一个变量名不规范，却没注意到整个方案跑偏了，这是本末倒置。

然后看关键路径。核心业务逻辑、并发和事务处理、外部交互这些高风险的地方重点看。CRUD、样板代码这些扫一眼就行，不必逐行较真。

再看边界和异常。空值、越界、超时、重试、幂等，这些是 bug 的高发区。问一句「这个接口被并发调用会怎样」「依赖的服务挂了怎么办」，能挖出很多隐藏问题。

最后才是风格和细节。命名、注释、代码组织，这些该提，但不要占 review 精力的大头。把它们交给 linter 和格式化工具去管，人的精力留给机器做不了的事。

同样的意见，说法不同效果天差地别。

区分问题级别。阻塞性的问题（会导致 bug 或故障）必须改，明确指出。建议性的（有更好的写法）用疑问句提，「这里用 stream 写会不会更清楚」，把决定权留给作者。nitpick（吹毛求疵的小问题）标出来就行，不要要求改。

用提问代替命令。「这里为什么这么做」比「这里应该那样写」好得多。提问是对话，命令是审判。前者让作者有机会解释他的考量，你也可能学到自己没想到的东西。

对事不对人。「这段逻辑有并发风险」是对的，「你怎么又写出并发 bug」是错的。代码是团队的资产，问题也是团队的，不是某个人能力差的证据。一旦 review 变成人身评价，大家就会开始防御，互相护短，机制就死了。

解释原因。指出问题的同时说清楚为什么是问题。「这里加锁会影响吞吐量，高并发下可能成瓶颈」比单纯说「这里不该加锁」有价值得多，因为前者传递了判断依据，作者下次能自己判断。

Review 质量不只取决于 reviewer，作者怎么提交同样关键。

PR 要小。一个 PR 解决一个问题，控制在几百行以内。上千行的大 PR 没人愿意认真看，review 必然流于形式。拆分是作者的责任，不是 reviewer 的负担。

写清楚的描述。这个 PR 解决什么问题、为什么这么改、有哪些需要注意的点、怎么测试的。一个好的描述能让 reviewer 在看代码之前就建立 context，省下大量来回沟通。

自己先 review 一遍。提交前把自己的 diff 通读一遍，很多低级问题自己就能发现。把干净的代码交出去，是对 reviewer 时间的尊重。

及时响应。reviewer 提了意见要尽快回复，要么改要么解释，别晾着。review 是个对话，对话需要双方都在场。

图：四个典型信号，任一出现都说明 review 在走过场

走过场的 review 有几个典型特征。

全是赞美没有意见。每个 PR 都是「写得好」「学到了」，看起来氛围很好，实际上质量门槛已经没了。健康的 review 一定会有不同意见和讨论，一团和气往往是大家都不想得罪人。

只挑格式不挑逻辑。花十分钟讨论一个空格，却不看核心业务逻辑对不对。这是用低成本的挑刺来制造「认真 review 了」的假象。

巨型 PR 强行过。一个几千行的 PR，reviewer 看不过来，最后只能草草 approve。这种 PR 要拆，不拆就别怪 reviewer 不认真。

把 review 当成审批关卡。author 提了就等 approve，reviewer 提了意见 author 就机械地改，双方都不思考。review 应该是协作不是审批。

设个基调

团队可以一起定几条 review 的约定，比如 PR 不超过多少行、多长时间内响应、阻塞性问题怎么标记。规则不用多，三五条就够，关键是让所有人对「我们怎么 review」有共识。规则定了，执行一阵子，团队的 review 文化自然就长出来了。

Code Review 是我见过的投入产出比最高的工程实践之一。

它的成本是每天一点时间，收益是代码质量上升、知识在团队里流动、新人快速成长、质量标准统一。一个 review 做得好的团队，整体代码质量会持续上升，新人融入速度会快很多，关键人员离职带来的知识断层会小很多。

但它也是最容易被荒废的实践，因为它不产生直接可见的产出，短期内看不到效果，需要团队有耐心去坚持。坚持下来了，它就是团队最稳的质量底座。