评审者指南是什么
Google 评审者指南（How to do a code review）的实操要点：先看设计意图再看代码细节，关注点按「设计、功能、复杂度、测试、命名、风格」分层推进，风格细节交给工具。评审者的职责是确认这次改动让代码库变得更好，而不是把代码改成自己偏好的样子。
基本信息
| 文档 | How to do a code review（评审者指南） |
|---|---|
| 推进顺序 | 先整体意图，后代码细节 |
| 风格处理 | 格式与风格交给格式化器和 lint，评论用 nit 前缀 |
| 沟通姿态 | 有疑问先提问确认，再下判断 |
| 响应速度 | 约一个工作日内给出回复 |
| 评审目标 | 代码库整体变好，不是按个人偏好重写 |
评审关注层次
| 层次 | 要回答的问题 |
|---|---|
| 设计 | 改动是否放在系统的正确位置，与既有架构是否一致 |
| 功能 | 行为是否符合意图，边界、异常、并发路径是否考虑 |
| 复杂度 | 有没有更简单的实现，是否为假想需求过度设计 |
| 测试 | 测试是否有效、能否失败，关键路径是否覆盖 |
| 命名 | 命名是否表达意图，是否与领域术语一致 |
| 风格 | 格式细节交给工具，人工评论只标 nit |
操作顺序建议
- 先读描述与关联工单，确认改动要解决的问题。
- 扫一遍文件清单与规模，建立改动地图，决定阅读顺序。
- 先读测试理解行为预期，便于判断覆盖与断言质量。
- 逐一细读核心文件，对每处疑问当场记录评论。
- 回到整体检查：设计是否合理、有没有更简单的替代方案。
- 攒好评论一次性提交，减少作者收到的通知噪声。
不要从风格细节开始评：先确认整体方向正确，否则细节评审可能全部作废。
评审者不必替作者重写代码：指出问题与方向，具体实现留给作者。
对不确定的点用提问代替断言：作者的解释常能补上缺失的上下文。