Google 是如何做 Code Review 的？| 原力计划 _Google

文章插图
作者 | 帅昕 xindoo
责编 | 屠敏
出品 | CSDN 博客
我和几个小伙伴一起翻译了google前一段时间放出来的Google’s Engineering Practices documentation（https://github.com/google/eng-practices），翻译后的GitHub仓库：https://github.com/xindoo/eng-practices-cn ，欢迎加star 。目前只是翻译完了，因为译者水平有限，还需要审校。另外后续Google肯定还会有新内容放出来，欢迎想参与贡献的小伙伴加入，也欢迎在GitHub上加star 。
这篇文章是Google’s Engineering Practices documentation的第一章Code Review实践指南：https://xindoo.github.io/eng-practices-cn/review/ 。
谷歌Code Review指南, 包含两个子章节：

评审者指南：https://xindoo.github.io/eng-practices-cn/review/reviewer/
开发者指南：https://xindoo.github.io/eng-practices-cn/review/developer/

1.术语部分文档中会用到一些谷歌内部的术语，特在此说明:

CL: “changelist"的缩写，代表已经进入版本控制软件或者正在进行代码评审的变更。其他组织经常称为"change"或者"patch” 。
LGTM: "Looks Good to Me."的缩写，看起来不错，评审者批准CL时会这么说。

2.评审者指南Code Review标准
Code Review的主要目的是始终保证随着时间的推移，谷歌代码越来越健康，所有Code Review的工具和流程也是针对于此设计的。
为了完成这点，我们不得不权衡利弊。
首先，开发者应当在他们代码中做一些改进，如果你永远都不做出改进，代码库整体质量也不会提升。但是如果审查者为难所有变更，开发者未来也会失去改进的动力。
另一方面，保证代码库随时间推移越来越健康是审查者的责任，而不是让代码库质量变得越来越差。这很棘手，因为代码质量一般都会随着时间推移越来越差，尤其是在团队有明确时间限制、而且他们觉得不得不采取一些投机取巧的方式才能完成任务的情况下。
但是，代码评审者得对他们Review的代码负责，所以他们想始终确保代码库一致、可维护（其他指标见"Code Review应该关注什么？"）
依据这些，我们将以下准则作为我们期望的Code Review标准：
通常而言，只要代码对系统有明显的提升且正常工作，即便不完美，评审者也应该倾向于通过这次变更。
这是所有Code Review指南中的高级原则。
当然这也有些局限。例如，如果变更里加入了有些评审者在系统里不想要的功能，即便代码设计的很好，评审者也可以拒绝掉。
关键点是没有任何完美的代码，只有更好的代码。代码评审者绝对不应该要求开发者在批准前对变更中的每一个小块进行打磨，相反，评审者应该权衡向前推进和他们采纳他们建议二者的重要性。评审者应该追求持续提高，而不是追求完美。那些可以提升整个系统可维护性、可读性和可以理解性的变更不应该因为代码不够完美而被推迟几天甚至几周。
评审者要始终不拘谨于在代码评论里提示可以更好的想法。但如果不是很重要信息，可以在评论前面加上标识告诉他们可以忽略。
注意：这篇文档中没有任何地方辩解在变更中的检查会让整个系统代码变得更糟糕。你唯一能做的在紧急状况中说明。
指导性
Code Review有个重要的作用，那就是可以教会开发者关于语言、框架或者通用软件设计原理。在Code Review中留下评论来帮助开发者学习新东西是很值得提倡的，毕竟共享知识也是长期提升系统代码健康度的一部分。但请注意，如果你的评论纯粹是教育性的，并且不是这篇文档中提到的关键标准，请在前面加上“Nit:”标识，或者明确指出不需要在这次变更中解决。
原则