"Code Review 太走形式""我提的意见对方不接受""花太多时间在 review 上" —— 这些是 Code Review 常见的痛点。但有效的 CR 是团队代码质量的最强保障,效益超过任何单一工程实践。这篇文章把 Code Review 的目标、原则、技巧、工具链讲透,让 CR 真正发挥价值。
Code Review 的真实目标
很多人以为 CR 是"挑错",其实更多:
- 知识共享:让 reviewer 了解新代码,避免单点知识。
- 代码质量:发现 bug、性能问题、安全漏洞。
- 一致性:风格 / 架构 / 命名保持团队规范。
- 学习:新人通过 review 学老人的代码风格,老人通过 review 学新人引入的新技术。
- 责任分担:出问题不是一个人的事,review 过的人也要负责 —— 反过来促进认真 review。
把 CR 单纯当成"挑错"会让作者觉得被审判,reviewer 觉得是负担。把它当成"协作",氛围完全不同。
作者准备 PR 的最佳实践
1. PR 要小
研究表明,< 200 行的 PR 缺陷发现率最高。> 500 行的 PR,reviewer 基本是"看个大概"。原则:一个 PR 一件事。重构 + 加功能 + 修 bug 混一起是反模式。
2. 自我 Review
提交前自己先 review 一遍。GitHub / GitLab 都支持"Files changed"视图,以"陌生人视角"看自己代码,经常能发现明显问题。
3. PR 描述要完整
# 标题:简洁说明做了什么
"Add user permission caching layer"
# 描述:
## What
增加用户权限的 Redis 缓存,TTL 5 分钟。
## Why
现在每次请求都查权限表,DB 压力大。
## How
- 在 UserPermissionService 加 cache:: 装饰
- 用户权限变更时发布 PermissionChanged 事件,缓存订阅事件失效
## Test
- 添加单元测试覆盖 cache hit / miss / invalidation
- 压测验证 QPS 提升 5x
## Breaking change
无
## Migration
无需迁移,缓存自动生效
## Related
- Closes #234
- Related to #1984. 自动检查通过再 request review
Lint、单测、CI 没过就提交给人 review,浪费 reviewer 时间。这些自动化工具能发现的问题,不要让人发现。
Reviewer 的有效方法
1. 先看 PR 描述和测试
不要直接看 diff —— 先看作者想做什么,有没有测试覆盖。读测试经常能比读实现更快理解意图。
2. 大处着眼
第一遍 review 关注:
- 这个变更的方向对吗?
- 架构 / 边界划分合理吗?
- 有没有更简单的方案?
方向错了,细节再好也白搭。大问题第一时间提出,不要等作者改了一堆细节再说"整体方向不对"。
3. 小处着手
方向 OK 后再看细节:
- 命名清楚吗?
- 边界条件覆盖了吗?
- 错误处理充分吗?
- 性能 / 并发安全?
4. 区分意见的严重程度
# 不同前缀代表严重程度,Google 的 CL 实践
[blocker] 这个 bug 上线会出事,必须改
[critical] 这块设计有问题,需要讨论
[major] 强烈建议改
[minor] 改了更好,可以不改
[nit] 吹毛求疵的小问题,作者自决
[question] 我不懂,问一下
[praise] 这块写得好,学习了这种分级让作者知道哪些必改,哪些可选。否则作者要么全改(浪费时间)要么全忽略(让 review 失去意义)。
5. 给出具体建议,不光指出问题
# 不好
"这段代码有问题,改一下"
# 好
"这段如果 list 是空的会抛 IndexOutOfBoundsException。
建议加一个检查或用 list.isEmpty() ? defaultValue : list.get(0)"
# 更好(代码建议)
GitHub 的 suggested changes 功能直接给出代码改动,作者一键应用6. 解释为什么
不只说"改",说"为什么"。这样作者:
- 能理解原因,下次自己避免。
- 觉得被尊重,而不是被命令。
- 如果你的理由不对,他能反驳让你也学到东西。
反模式
反模式 1:Rubber Stamp(橡皮图章)
看都不看就 approve。表面 review 通过,实际等于没 review。原因通常是"review 负担太重",根源是 PR 太大或 reviewer 不熟。
反模式 2:LGTM 文化(Looks Good To Me)
每个 PR 都"LGTM,merge"。短期效率高,长期代码质量崩。改进:CR 要有实质性反馈,看不出问题就承认"我看不出问题但 X 我不熟悉,建议 @ 该方面专家"。
反模式 3:Bikeshedding(为琐事争论不休)
对核心逻辑没意见,但花一小时讨论"变量名该用驼峰还是下划线"。原因:小问题人人能评,大问题需要专业知识。改进:Linter 自动化所有风格问题,人只 review 实质内容。
反模式 4:Personal Attack(人身攻击)
# 不好
"这代码写得真烂"
"这么基础的东西都不会?"
# 好
"这里的逻辑我没看懂,能解释一下吗?"
"这块可能有更好的方式,见这个文档:..."评论代码,不评论人。语气客观,关注事实。建立"review 是协作不是审判"的团队文化。
反模式 5:Reviewer 强行加自己偏好
"你应该改成我习惯的写法" —— 这是个人喜好,不是质量问题。Reviewer 要尊重作者风格,只在影响可读性 / 正确性时才坚持。
Code Review 的工具链
- GitHub PR / GitLab MR:基础。
- SonarQube / CodeClimate:静态分析,自动找代码坏味道。
- ReviewBoard / Phabricator:专业 CR 工具,适合大型项目。
- Reviewable.io:GitHub 的增强,大型 PR 友好。
- AI 辅助:GitHub Copilot for PRs、CodeRabbit、Cursor 都能给 AI review,辅助但不替代人。
团队规范化 CR 流程
1. 谁 review
- 代码所有者(CODEOWNERS 文件自动指派)。
- 领域专家(数据库、安全、性能各有专人)。
- 新人 PR 由 mentor + 一个普通人 review。
2. 多少人 review
关键代码 2 人 +,普通代码 1 人足。Linus 法则:"足够多的眼睛"反而让每个人不认真。
3. 多久要 review
24 小时内首次响应,3 天内 review 完。否则 PR 堆积、作者效率下降。可以设 SLA,自动 ping reviewer。
4. 怎么 approve
明确"approve"的语义:
- "所有 review 意见已处理,可以合并"。
- 不是"看起来不错"。
大型 PR 的处理
实在没法拆的大 PR(架构改造、新功能):
- 分多次 review:第一次只看架构,第二次看实现,第三次看细节。
- 开会面对面 walkthrough。
- 主要 reviewer 投入更多时间,其他人 spot check。
异步 review vs 同步 review
- 异步(主流):reviewer 看 PR 留评论,作者改。优点:不打断对方;缺点:沟通慢。
- 同步(必要时):约 30 分钟会议,作者 walkthrough。复杂 PR 一次开会节省 10 次评论往返。
写在最后
Code Review 是"团队级别的代码质量"。一个会 review 的团队,几个月后代码会比"只是闷头写"的团队好很多 —— 不是因为 review 时找出多少 bug,而是因为知道会被 review,写代码时更认真。这种"同伴压力"是软件工程里最强的质量提升手段之一,且几乎免费。
给团队的建议:把 review 时间算进工作量,把"我没时间 review"作为团队红线。review 没时间 = 质量没保障,迟早出事故。把 review 文化建好,你的团队会自然进入"越来越好"的飞轮。
一图看懂
Code Review 流程一图看懂:
—— 别看了 · 2026