代码评审（Code Review，简称 CR）常被当成”上线前挑刺”的关卡，但在成熟团队里，它其实是性价比最高的能力放大器：一份好的评审能拦住 bug、统一风格、传递上下文，还能让新人快速成长。本文从流程、清单到文化，系统讲清怎么把代码评审做成团队的基础设施。如果你也在纠结技术债与交付速度的取舍，可以先看我们的技术债工程决策。
一、为什么代码评审值得投入
很多团队把评审当成”拖慢进度”的成本，但越往后发现的缺陷修复成本越高，而评审作为离代码最近的一道关，单位时间拦下的 bug 数量往往高于自动化测试。更隐性但更值钱的是三件事：
- 知识传递：一次评审就是一次 mini 技术分享，reviewer 和 author 都能涨经验，避免知识锁在单人脑子里。
- 风格与架构收敛：避免”每个人一种写法”，长期显著拉低维护成本。
- 风险对冲：至少两人见过这段代码，key person risk 被摊薄，有人请假也不至于无人能改。
换句话说，评审省下的不是一次 review 的几分钟，而是未来无数次排查与返工的几小时。
二、三种典型反模式
评审做不好，往往不是人不认真，而是流程错了。下面三种反模式最常见。
1. 审批式评审：点个 Approve 就过
reviewer 只扫一眼 diff 大小，确认”看起来没问题”就点通过。这种评审形同虚设——既没发现逻辑漏洞，也没传递任何上下文，等于把质量把关权让渡给了运气。
2. 个人英雄式评审：只有 Tech Lead 看
所有 PR 都堆在一个人头上，结果是瓶颈 + 单点故障：他休假，合并就停摆。评审应该是全员 distributed 的职责，而不是某个”守门人”的专利。
3. 临终评审：上线前一晚才提
功能写完、deadline 压顶才提 PR，reviewer 在”要不就过吧”的心理下草草通过，评审价值归零。配合良好的 Git 分支与 rebase 习惯（见Git rebase 与 cherry-pick 实战踩坑）能让 PR 自始至终保持干净。
| 反模式 | 典型表现 | 代价 | 解法 |
|---|---|---|---|
| 审批式 | 扫一眼就 Approve | 漏掉逻辑 bug | 给评审清单，要求逐条回应 |
| 个人英雄式 | 只 TL 看 | 瓶颈 + 单点故障 | 评审轮值，至少 1 名非作者 reviewer |
| 临终评审 | 上线前才提 | 走过场 | 小 PR + 早提早评，分桶合并 |
三、高效 CR 的流程设计
把评审从”靠自觉”变成”靠流程”，核心是两条：小 PR、早评审。先用一个 PR 模板约束作者提供的信息，再用评审清单约束 reviewer 的关注点。
## 这个 PR 做了什么
- 一句话描述变更目标
## 变更类型
- [ ] 新功能
- [ ] Bug 修复
- [ ] 重构
- [ ] 文档
## 自检清单
- [ ] 本地测试通过
- [ ] 新增/修改逻辑有测试覆盖
- [ ] 无遗留 debug 代码、无 secrets 硬编码
- [ ] 相关文档已更新
## 关联
- 关联 issue / 需求：#评审者逐条确认清单
评审者逐条确认：
1. 目的清晰：PR 描述和变更一致，没有"顺手改了一堆"
2. 接口与边界：入参校验、错误路径、并发与幂等
3. 可观测：关键路径有日志/埋点，便于后续排查
4. 安全：权限、注入、敏感信息、依赖来源
5. 测试：覆盖 happy path 与异常路径
6. 可读性：命名、注释、函数粒度是否易于维护清单的价值在于把”凭感觉看”变成”按条目过”，既降低 reviewer 的认知负担，也让作者知道会被关注哪些点，提 PR 时就会更自觉。
四、把评审做成文化：五条软规则
- 小步快跑：一个 PR 只解决一件事，diff 控制在可审阅范围（建议单 PR < 400 行）。
- 对事不对人：评论针对代码，不针对人；用”建议这样是否更好”而非”你错了”。
- 及时响应：设定 SLA，例如工作日 4 小时内首评，避免 PR 堆积成山。
- 解释”为什么”：reviewer 给出背景和权衡，作者才能从中学到，而不是机械改。
- 鼓励提问式评审：新人问”这里为什么这样写”往往能挖出隐藏假设，比直接下结论更有价值。
文化不是靠发通知建立的，而是靠一次次评审里的语气和习惯沉淀出来的。前几条软规则，和我们讲技术选型决策矩阵时强调的”用机制代替拍脑袋”是同一套思路。
五、用工具把评审自动化
能自动化的别让人肉。把 lint、类型检查、单测、覆盖率门禁放进 CI，让 reviewer 把精力放在真正需要判断的地方。
name: review-gate
on: [pull_request]
jobs:
checks:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: 20
- run: npm ci
- run: npm run lint # 风格与静态检查
- run: npm test # 单测 + 覆盖率
- run: npx danger ci # PR 评论级检查：大 diff 警告、缺测试等这套 CI 门禁的搭建思路，和我们之前讲的GitHub Actions 从零搭建 CI/CD一脉相承：把重复劳动交给机器，把判断力留给人。Danger 这类工具还能在 PR 里自动贴出”本 PR 超过 500 行””缺少测试文件”等提示，把评审清单部分自动化。
六、度量与持续改进
评审也需要被度量，否则容易停在”感觉还行”。几条可观测指标：
| 指标 | 健康区间 | 说明 |
|---|---|---|
| PR 平均合并时长 | < 24h | 过长说明评审阻塞或 PR 太大 |
| 单 PR 代码行数 | < 400 行 | 过大显著降低审阅质量 |
| 评审参与人数 | ≥ 2 | 避免单点，促进知识扩散 |
| 评审评论数 / PR | 3–10 | 过少可能走过场，过多可能争议大 |
| 缺陷逃逸率 | 持续下降 | CR + 测试共同压低线上 bug |
把这几条放进周报或仪表盘，团队对”评审健不健康”就有了一把尺子，也能据此调整流程，而不是永远在重复同样的争论。
七、小结
代码评审不是上线前的”找茬关”，而是团队的能力放大器：它拦 bug、传知识、收风格、摊风险。落地时抓住三件事——用清单和 CI 把评审标准化、用”小 PR + 早评审”把流程跑顺、用五条软规则把文化养起来。当评审变成日常习惯而不是负担，代码质量和团队成长会一起往上走。把这套机制坚持下去，你会发现很多”技术债”其实在评审阶段就被悄悄还清了。
