代码审查（Code Review），大概是程序员日常工作中最被低估的活动之一。许多人把它当成「找bug的工具」，但真正有价值的Code Review，远不止于此——它是团队知识共享的桥梁，是代码质量的第一道防线，更是工程师之间最直接的学习方式。
为什么你的Code Review总是流于形式？
常见的Code Review失败案例：reviewer上来就是「这个变量命名不规范」、「这里应该用const」，然后就没有然后了。作者改完点个approve，review就算完成了。
这种审查几乎没有价值。它把Code Review变成了一个机械的格式化检查，而忽略了更重要的事：这段代码的架构是否合理？它对系统的其他部分会产生什么影响？作者为什么会用这种方式实现？
好的Reviewer，从问好问题开始
优秀的代码审查，首先是一种对话，而非审判。最有力的问题，往往不是「你为什么不这样做？」，而是「我想了解一下你为什么选择这种方案？」
这种问法有三个好处：
- 表达尊重：假设作者有他的理由，而不是假设他错了。
- 获取背景：有时候你不知道的限制（性能约束、遗留代码、第三方API行为），才是真正的原因。
- 发现更好的方案：通过对话，你可能发现你们一起想出了一个比两个人各自方案都更好的第三种解法。
批评代码，不批评人
这是程序员世界里最难做到的事情之一。「这段代码有问题」vs「你的代码有问题」——意思相近，但感受天差地别。
一个实用的技巧是：把注意力放在代码本身，而不是作者。推荐用「这段代码……」替代「你这段代码……」。推荐用「I think this can be simplified because…」替代「This is wrong」。
如果是风格问题，可以提前建立团队共识，把风格规范写进ESLint、Checkstyle等工具里，让机器来处理，Reviewer就不用反复纠缠于格式细节。
Review什么？——建立优先级
不是所有代码都值得同等程度的审查。以下是我推荐的优先级：
- 核心业务逻辑：影响钱、影响用户数据的代码，必须仔细审查。
- 安全相关：权限校验、输入验证、加密逻辑，每一次都要过。
- 架构与设计：模块划分、接口设计、依赖关系，这些改动代价最高，需要充分讨论。
- 测试覆盖：有没有必要的单元测试？边界条件覆盖了吗？
- 代码风格：能工具化的不要人工Review，把精力留给更重要的事。
作者也要做好功课
Code Review是双向的。作者如果做好以下几点，Review效率会大幅提升：
- PR描述写清楚：改了什么？为什么改？有没有需要注意的地方？
- 小步提交：一次Review的代码量不要超过300-400行，大功能拆成多个小PR。
- 自审一遍再提交：自己先过一遍，能避免很多低级问题。
写在最后
Code Review本质上是一种知识传递机制。老员工通过Review把经验和规范传递给新人，新人通过Review理解系统的历史和约束。它是团队成长的加速器。
把Code Review当成一次和同事pair programming的机会，而不是一个关卡。当你这样想的时候，整个审查过程就会变得不同——更开放、更有价值、也更有意思。
愿你的下一个PR，都被温柔而专业地对待。
