这条标准是什么
Google Engineering Practices 给出的评审决策标准：一次改动只要让代码库整体变好，评审者就应当批准，不要求它完美；只有当改动让质量明确变差时才拦下。它同时约束两端：评审者不把「还能更好」当作阻塞理由，作者也不把未成型的代码丢给评审。标准服务的是代码库的长期健康，而不是单次改动的完美程度。
基本信息
| 出处 | Google Engineering Practices · The Standard of Code Review |
|---|---|
| 核心决策 | 让代码库整体变好的改动应当批准 |
| 阻止条件 | 改动让质量明确下降：删测试、绕过校验、引入明显耦合 |
| 判断依据 | 技术事实、数据与文档优先于个人偏好与资历 |
| 适用对象 | 评审者与作者双方；PR/MR、结对复查、开源维护同样适用 |
| 配套实践 | 小 CL、约一个工作日内响应、评论写清原因与影响 |
决策时依次问什么
- 这次改动让代码库比之前更好吗：整体改善即可批准。
- 有没有明确劣化：正确性、可测性、可维护性上的退步必须拦下。
- 「还能更好」是改进建议而非阻塞理由，标注 nit 留给后续处理。
- 争议能否引用依据：团队规范条款、基准数据、兼容性要求优先于口味。
- 方向正确但细节欠佳：先合入再开跟进项，避免改动长期挂起。
- 双方僵持：引入第三方或负责人裁决，结论写进评论留痕。
三种典型决策情形
| 情形 | 处理 | 依据 |
|---|---|---|
| 整体变好，局部可改进 | 批准，提建议不阻塞 | 改进空间不属于劣化 |
| 质量明确下降 | 阻止并指出劣化点 | 删除测试、绕过校验、增加耦合 |
| 无法判断优劣 | 要求作者补充依据 | 测试结果、日志、文档、复现步骤 |
| 方案偏好分歧 | 另开讨论，不卡合并 | 评审聚焦代码健康而非谁赢 |
按优先级看关注点
| 层次 | 要回答的问题 |
|---|---|
| 设计 | 改动是否放在系统的正确位置，与既有架构是否一致 |
| 功能 | 行为是否符合意图，边界与异常路径是否考虑 |
| 复杂度 | 有没有更简单的做法，是否为假想需求过度设计 |
| 测试 | 关键路径是否覆盖，测试能否真的失败 |
| 命名与风格 | 命名是否表达意图；风格细节交给格式化工具 |
常见误解
- 「必须完美才批准」：标准明确反对，小瑕疵不应挡住整体改善。
- 「批准等于担保没缺陷」：不等于，作者仍对最终质量负责。
- 「小问题也必须先改完」：非阻塞建议可标注 nit 后放行。
- 「标准只约束作者」：评审者响应慢、表述含糊同样破坏评审效率。
- 「有争议就先拖着」：拖不是决策，应补依据或升级裁决。
两种评审意见对比
两种评审意见对比
# 空泛表态：作者只能猜意图
这里不要这么写。
# 可执行意见：问题 + 影响 + 建议
两次读取之间没有事务，并发下可能读到不一致状态；
能否合并为一次查询，或用事务把两次读包住？
# 非阻塞建议：标明不修也能合
nit: 这个变量名改成 retryLimit 读起来更直白，后面再改也可以。「更好」是方向判断：整体改善要放行，明显劣化要拦下，这两条是同一枚硬币的两面。
把这条标准写进团队评审协议：新评审者按同一口径执行，评审速度与一致性都会改善。
作者对评审效率负一半责任：描述写清背景、改动与验证方式，能显著减少来回轮次。