作者指南讲什么
Google 的 CL 作者指南把请评审之前和之后的事都写清楚了：把改动做成单一自包含的 CL、在描述里写明背景与验证方式、提交前先自己通读一遍 diff，然后邀请合适的评审人，并在意见到达后快速响应。作者对评审效率负一半责任，描述越清楚，来回轮次越少。
基本信息
| 文档 | The CL Author's Guide（Google Engineering Practices） |
|---|---|
| 关键动作 | 写清意图 / 控制规模 / 先自审 / 响应意见 |
| 描述要素 | 背景、改动内容与取舍、验证方式、风险与回滚 |
| 响应要求 | 逐条回复评审意见，说明改法或解释为何不改 |
作者的四个动作
- 描述：写清改什么、为什么改、怎么验证，附上命令与结果。
- 规模：控制在小而完整的范围，重构与功能改动分开提交。
- 自审：提交前通读完整 diff，清掉调试输出、注释代码与临时文件。
- 响应：收到意见后逐条回复，改了说明改法，不改说明理由。
描述里必须写清的内容
- 问题背景：为什么需要这次改动，影响面有多大。
- 改动范围：哪些部分改了，哪些刻意不在本次范围。
- 验证方式：跑了哪些测试、手工验证步骤与结果。
- 风险与回滚：可能的失败点、监控项、出问题怎么退。
常见返工原因
| 现象 | 根因 | 改进做法 |
|---|---|---|
| 评审者反复追问背景 | 描述只有标题式一句话 | 补背景与动机，附工单链接与要点 |
| 改动被要求拆分 | 一个 CL 混了多个主题 | 重构与功能分开，机械改动单独提交 |
| 低级问题消耗注意力 | 跳过自审直接请评审 | 提交前通读 diff 并跑本地校验 |
| 讨论反复无法收敛 | 评论未逐条回应 | 改法写清，不改则说明理由 |
提交评审前的自检
提交评审前的自检
git diff --stat # 看规模是否合理，文件是否都在预期内
git diff # 通读一遍，清掉调试输出与注释掉的代码
git diff --check # 查空白错误与残留的冲突标记
# 再确认：描述里的验证方式真的跑过吗？结果能贴出来吗？作者对评审效率负一半责任：描述清楚、改动自包含，评审者就不用从 diff 里反推上下文。
邀请评审人时选熟悉该模块的人：跨模块大改可以同时请两位，一位看设计、一位看该领域细节。