Code Review 实战：从 Checklist 到工程文化的落地方法

先说结论：Code Review 是投资，不是成本

很多团队把 Code Review 当作”上线前的门禁”——CI 跑完、Review 通过、合并上线。但 Review 最大的价值不是”拦下不好的代码”，而是”让每个人的代码水平在 Review 中逐步提升”。

本文从三个层面展开：Review Checklist、Review 评论的艺术、Review 流程设计。

---

1. Review Checklist：看什么、不看什么

检查优先级

优先级	检查项	说明
P0	逻辑正确性	边界条件、异常路径、并发安全
P0	安全性	SQL 注入、XSS、权限校验、敏感信息泄露
P1	可维护性	命名、函数长度、重复代码、注释
P1	测试覆盖	新代码有没有测试、边界情况是否覆盖
P2	性能	不必要的循环、N+1 查询、内存泄漏
P3	代码风格	缩进、命名规范——交给格式化工具

不要花时间在 P3 上。代码风格是格式化工具（Prettier、ESLint、Rustfmt）的事，不是人的事。Review 时如果发现风格问题，说明 CI 里没有加格式化检查，应该在 CI 里修，不是在 Review 里修。

每轮 Review 的黄金范围

单个 PR 不要超过 400 行。超过 400 行，Review 的 bug 发现率会急剧下降，Reviewer 的疲劳度会急剧上升。

如果 PR 确实很大，建议：

• 拆成多个小 PR，每个 PR 只做一件事
• 或者 Author 先口头讲解设计思路，Reviewer 再 Review

---

2. Review 评论的艺术

评论的四种语气

类型	示例	效果
命令式	”改成 Map”	抗拒，不想改
提问式	”这里为什么用 Map 而不是 Object？“	思考，讨论
建议式	”有个想法：要不要试试用 Map？“	开放，接受
教育式	”这里用 Map 的好处是 key 的顺序有保证”	学习，成长

写评论的几个原则

先说好的，再提建议。 每轮 Review 至少说一句”这个设计很好”或”这个命名很清晰”。没有正面反馈的 Review 会让 Author 觉得 Review 是来找茬的。

用”我们”不用”你”。 “我们是不是漏掉了这个边界情况？” 比 “你漏掉了这个边界情况” 好得多。前者是”我们一起看”，后者是”你错了”。

明确阻塞和非阻塞。 每条评论标注是”必须改”（blocking）还是”建议改”（nit）。没有标注的评论会让 Author 不知道哪些是必须改的。

---

3. Review 流程设计

设定 SLA

PR 大小	响应 SLA	说明
≤ 100 行	2 小时内	小改动，快速 Review
100-400 行	4 小时内	正常 PR，当天完成
> 400 行	建议拆 PR	大 PR 当面 Review

Review 轮次控制

两轮原则：第一轮 Reviewer 提意见，Author 修改，第二轮 Reviewer 确认修改。如果超过两轮，说明沟通出了问题，建议当面聊。

工具链推荐

用途	工具
格式化	Prettier / ESLint（CI 自动检查）
静态分析	SonarQube / CodeQL（CI 自动检查）
Review 平台	GitHub Pull Request / GitLab Merge Request
Review 模板	PR 模板自动加载 Checklist

---

总结

层面	核心原则	常见错误
检查范围	逻辑 + 安全优先，风格交给工具	花时间在缩进和命名上
评论语气	提问代替命令，先说好的再提建议	只有批评没有正面反馈
PR 大小	不超过 400 行	大 PR 一次性 Review
Review 轮次	两轮原则，超两轮当面聊	来回拉锯
SLA	4 小时内响应	拖到上线前才 Review

Code Review 做得好不好，不看它”拦下了多少 bug”，而看它”让团队的水平提升了多少”。 最好的 Review 是 Author 看完评论后说”原来还可以这样”，而不是”好的我改”。

需要技术方案咨询或团队工程实践优化？联系我们，说清你的现状与痛点，24 小时内回可行性。

相关阅读

• 技术方案评审怎么做：选型、架构评审与可行性报告的方法 —— Code Review 的上游技术决策流程
• 运维自动化脚本模式：从一次性脚本到可维护工具 —— 代码工程化与可维护性的共同理念