06 · Code Review：方法、边界与流程
Code Review 不是"挑刺"，是"帮作者把决定再想一遍"。 一次好的评审能拦住 bug、统一规范、传递知识；一次糟糕的评审则变成"线上吵架"。本篇讲怎么看、怎么评、边界在哪、流程怎么立。
速览卡
| 项 | 内容 |
|---|---|
| 一句话定位 | 把 Code Review 从"事后检查"变成"质量与知识的关口"：看什么、怎么写评论、边界与流程 |
| 核心内容 | Review 的价值、评审优先级、评论的写法、边界（什么不该在评审里管）、流程与节奏、新人评审 |
| 读完能回答 | 评审重点看哪几类问题？评论怎么写才不被当成攻击？哪些问题不该在评审里提？ |
| 相关板块 | A28 · 代码生成与规范化工具链 ｜ A11 · 前端测试策略 ｜ F03 · 技术方案写作 |
一、Review 的三个价值
1.1 拦 bug：第二双眼睛
作者写完代码往往"想当然"，评审人带着怀疑重读，能发现边界条件、错误处理、数据契约的问题。评审是低成本拦住问题的关口——上线后修 bug 的成本是评审时的十倍以上。
1.2 统一规范：把规范写进代码
规范文档没人读，但每次评审都在执行规范。命名、错误处理、测试覆盖，通过评审逐渐变成团队的"共识即事实"。
1.3 传递知识：新人成长最快的地方
对新人，评审是"为什么这么写"的现场教学；对老人，评审是了解系统全貌的途径。
二、评审看什么：按优先级
评审时间有限，先看高风险，再看风格：
| 优先级 | 类型 | 例子 |
|---|---|---|
| P0 | 正确性 | 边界条件、空指针、并发、错误处理、数据契约 |
| P1 | 安全性 | 注入、越权、密钥硬编码、敏感信息外泄 |
| P2 | 可维护性 | 命名、函数过长、重复代码、可测试性 |
| P3 | 风格 | 缩进、格式（交给工具，人工不评） |
关键原则：P3 交给工具（linter/formatter），人工只评 P0~P2。把时间花在风格上，是评审效率最大的浪费。
三、评论怎么写：对事不对人
评论的语气决定了评审是"被接受"还是"被抵触"。三条写法：
| 写法 | 差的例子 | 好的例子 |
|---|---|---|
| 问句代替断言 | "这里写错了" | "这里在 XX 情况下会不会出错？" |
| 给理由 | "改一下" | "改成 XX，因为 YY（规范/风险）" |
| 区分阻塞与建议 | 全部用 P0 语气 | 明确标注"阻塞"与"建议" |
一句万能开头："我可能在漏看，但…"。它把对话从"对错"变成"一起确认"，是最便宜的冲突化解器。
四、边界：什么不该在评审里管
评审管不了的事，别在评审里硬管，否则变成拉锯：
| 不该在评审里 | 应该在哪处理 |
|---|---|
| 产品方向对不对 | 需求评审 / 方案文档（F02/F03） |
| 技术选型之争 | 方案评审 / 决策记录（F04） |
| 格式化与琐碎风格 | linter / 自动化 |
| 大规模重构 | 单独的技术方案，不夹带在小 PR 里 |
一条经验：评审里争论超过两个来回的问题，提到线下或方案评审解决，不要在评论里无限对线。
五、流程与节奏：评审要快，块头要小
好的评审节奏：
| 原则 | 实践 |
|---|---|
| 小步提交 | PR 控制在可评审的规模（经验值：几百行以内），大改动拆成多个 |
| 及时评审 | 评审延迟 = 作者阻塞，48 小时内处理完常见规模 |
| 有结论 | 每条评论要么被采纳、要么被明确反驳，不留"待定" |
| 测试护航 | 有测试的改动评审更快，评审人也更敢放行 |
评审不是为了"卡流程"，是为了"让每个合入的改动都经过一次低成本检查"。流程越轻，越容易被坚持。
六、新人怎么参与
新人不是只能"被评"：
- 先当观察者：跟着老人看几个 PR，学"先看哪、怎么问"
- 从测试评审入手：评测试覆盖率与用例质量，风险低又有价值
- 问问题也是评审："这里为什么这么写"本身就是有效的评审
前端转全栈时，跨端评审是稀缺能力：你能同时看出前端调用方式和后端契约是否对齐，这比单端工程师多一个评审视角。
自检清单
- [ ] 评审按 P0 正确性 → P1 安全 → P2 可维护 → P3 交工具 的顺序
- [ ] 评论用问句、给理由、标注阻塞/建议
- [ ] 不在评审里争论产品方向、技术选型、格式风格
- [ ] 能控制 PR 规模，让评审及时完成
- [ ] 每条评论都有结论（采纳 / 明确反驳）
- [ ] 能用"跨端视角"评审前后端契约
常见误区
| 误区 | 事实 |
|---|---|
| "评审 = 找茬" | 评审是帮作者再想一遍，语气决定效果 |
| "评审要评所有细节" | 风格交给工具，人工聚焦正确性与安全 |
| "大 PR 也能慢慢评" | 大 PR 是流程问题，应该拆小而不是硬评 |
| "新人只配被评" | 新人从测试评审和提问入手，同样是有效评审 |
动手练习
练习 A：给 PR 分级评论
翻一个最近的 PR，把每条评论标上 P0/P1/P2/P3，删掉所有 P3 评论，看看评审是否更聚焦。
练习 B：改写评论
把三条"断言式"评论改成"问句 + 理由 + 优先级"，对照感受语气差异。
练习 C：定团队评审规则
给自己（或团队）写三条可执行的评审规则：规模上限、响应时限、评论结论要求。
相关文档
本区
- 03 · 技术方案写作 —— 方案评审与代码评审的分工
- 04 · 技术选型 —— 选型之争放在哪解决
其他域
- A28 · 代码生成与规范化工具链 —— linter/formatter 接管 P3
- A11 · 前端测试策略 —— 测试如何让评审更快
- C11 · 后端测试实战 —— 后端评审配套的测试视角