代码审查的五个实用建议：让 Code Review 不再流于形式
Code Review 是软件开发中投入产出比最高的质量实践之一，但也是最容易被敷衍的。我所见过的低效 Review 模式包括：点个 LGTM 就合并、只抓格式问题不关注逻辑、以及把 Review 变成个人风格的角力场。
以下是经过几个项目验证后沉淀下来的五条实践。
建议一：区分阻塞性评论和建议性评论
不是所有问题都需要在合并前修改。把评论明确分为两类可以大幅减少沟通摩擦：
- 阻塞性（blocking）：逻辑错误、安全漏洞、数据一致性风险、会导致生产事故的边界情况——这些必须改
- 建议性（non-blocking / nit）：命名偏好、代码组织方式、可选的性能优化——这些可以讨论，但不阻塞合并
实践中我使用前缀标记：[nit] 表示建议性评论，[blocking] 表示必须修改。没有前缀的默认是建议性。这个简单的约定让提交者一眼就能判断优先级，避免在非关键问题上消耗过多时间。
// Review 评论示例
[blocking] 这里 `user.id` 可能为 null，下面的 `findById` 会抛 NPE
[nit] 变量名 `data` 可以改成更具体的 `userPreferences`
建议二：PR 粒度的黄金法则
超过 400 行的 PR，Review 的有效性会断崖式下降。这不是态度问题，是认知负载问题。当你 Review 一个 800 行的 PR 时，到第 500 行，你的注意力已经消耗殆尽，后面的逻辑错误很容易被漏掉。
实际操作中：
- 一个 PR 对应一个逻辑变更，而不是一个功能模块
- 重构和功能修改放在不同的 PR 里
- 如果 PR 看起来很大，先看提交记录——如果每个 commit 都是独立的、可审查的，可以按 commit 逐个审查
建议三：建立团队级别的审查清单
与其每次 Review 时凭直觉检查，不如维护一份共享的审查清单。清单的价值不在于”记住所有项”，而在于不遗漏常见的非功能性缺陷：
- 是否存在 SQL 注入或 XSS 风险？
- 错误处理是否覆盖了异常路径？是否有静默吞错？
- 新增的数据库查询是否有合适的索引？
- 敏感信息（密钥、Token）是否被硬编码或暴露到日志中？
- API 响应是否有合适的超时和重试策略？
- 命名是否清晰到”不需要注释就能理解意图”？
建议四：Review 评论的语言模式
Review 时的措辞直接影响团队的心理安全感。几条经过验证的模式：
- 用提问代替断言：“这个函数在
items为空数组时会发生什么？“而不是”你这里没处理空数组” - 引用原则而非个人偏好：“根据我们的错误处理规范，这里应该 throw 而不是返回 null”而不是”我觉得应该 throw”
- 对于好的实现，明确指出来：“这个错误处理写得很清晰，特别是重试逻辑的 exponential backoff”——正面反馈和发现问题同样重要
建议五：Review 速度的团队约定
PR 晾太久是 Review 质量的最大杀手。提交者会失去上下文，Review 者需要重新理解。我们的团队约定：
- 非紧急 PR：24 小时内完成第一轮 Review
- 紧急修复：4 小时内 Review，Slack 上 @ 提醒
- 如果超过 48 小时无人 Review，提交者有权直接合并（前提是 CI 全绿且有至少一个 approving review）
Code Review 本质上是一种知识分发机制——每一次 Review 都是在团队成员之间传递代码库的理解和设计决策。好的 Review 文化让团队的代码质量均值不断提升，同时减少因为人员流动带来的知识断层。