Google 风格代码审查的精髓：一种“改进”胜于“完美”的文化

抱歉，我需要您提供要翻译的完整文本内容（除代码块和链接外），才能为您进行简体中文翻译。请把文章的正文粘贴在这里，我会保持原有的 Markdown 格式并只翻译文字部分。

介绍

对于工程师而言，代码审查占据了日常工作的大部分。许多人会困惑诸如“我应该审查到多细的粒度？”、“个人偏好和 bug 的界限在哪里？”以及“为什么审查过程拖慢了我们的开发？”等问题。

Google 的工程实践文档为这些问题提供了明确且经受实战检验的答案。本文阐述了全球顶尖工程组织之一所遵循的 代码审查标准，并将其适配到常见的开发工作流（如 GitHub）。

注意： 在 Google 中，Pull Request（PR）被称为 CL（Change List）。本文为便于理解，PR 与 CL 可互换使用。

Google 用一句简明的使命定义了代码审查的目的：

“代码审查的首要目的在于确保 Google 代码库的整体代码健康随时间得到提升。”

代码审查标准

关键要点是，Google 并不追求“完美代码”。
如果一次改动 不是完美的，但比当前状态更好，就应该被批准。审查者可以留下评论以供以后改进，但只要改动不降低代码健康度，就可以给出 LGTM（Looks Good To Me）。这种务实的折中最大化了开发速度。

审查优先级

审查者应根据以下优先级评估代码，而不是仅仅浏览：

1. 设计 – 整体架构是否健全且良好集成？
2. 功能 – 是否按作者意图运行并为用户提供价值？
3. 复杂度 – 代码是否简洁？是否存在其他人难以理解的“巧妙”写法？
4. 测试 – 是否有正确且易于维护的单元测试？
5. 命名 – 名称是否清晰且具描述性？
6. 注释 – 注释是否解释 为什么 要这么做，而不仅仅是 做了什么？

参考: What to look for in a code review (Google guidelines)

个人偏好

Google 的指南指出，对于没有技术依据的个人偏好，审查者应 遵从作者的判断。审查者不应将自己的编码风格强加给他人。

审查速度

单个工作日规则

• 审阅者应力争在一个工作日内提供首次回复（理想情况下在次日早晨）。

中断 vs. 专注

• 您无需打断深度专注来立即响应。请在自然的间歇期间（例如完成任务后或午餐后返回时）将审查视为最高优先级。

“慢审查” 的代价

• 审查时间越长，作者忘记上下文的程度越高，导致在修复阶段产生高昂的上下文切换成本。

参考: Speed of Code Reviews (Google guidelines)

Reference: 如何撰写代码审查评论（Google 指南）

如何撰写代码审查评论

• 协作，而非批评: 审查 代码，而不是 人。

  • 与其说“你写得很差”，不如说“这个函数感觉很复杂，因为 …”。

• 提供“原因”: 解释为何需要更改（例如性能、未来可扩展性），而不是仅仅要求修复。

• Nit（挑剔）: 使用 Nit: 标签来标记可选但有益的细微建议。这可以减轻作者的心理负担。

文化原则

• 拒绝完美主义： 即使改动并不完美，也要批准能够改进代码库的更改。
• 平衡速度与质量： 在保持细致的同时，确保在一个工作日内作出响应。
• 尊重与指导： 将评审视为指导和共同成长的机会。

通过采用这些做法，团队可以消除开发停滞的挫败感，营造一种每个人都为更健康的代码库做出贡献的文化。