从《Software Engineer at Google》学 CodeReview

最近在读《Software Engineer at Google》一书，其中覆盖软件工程的内容十分全面，但是我现在可以实践的可能只占十之二三。而其中看来最有用的，就是Code Review的部分。

本文将书中我认为最启发，最重要的知识，已摘要形式呈现，并附带我的个人理解。对于内容带有跳跃和简化，只分为了2个部分：

1. Foundation Concepts 基础概念
2. Best Practices 最佳实践

Foundation Concepts 基础概念

本文对code view的流程不进行赘述，而是列举出实践中会遇到的一些基础知识：

什么是 LGTM?

“The primary end goal of a code review is to get another engineer to consent to the change, which we denote by tagging the change as “looks good to me” (LGTM). We use this LGTM as a necessary permissions “bit” (combined with other bits noted below) to allow the change to be committed.”

翻译:
code review的最终目的就是让另一个工程师认可本次修改，主要通过给本次打上 “looks good to me“(LGTM)，即“我觉得可以” 的标签。我们使用LGTM作为准许修改提交，所必要的一个授权部分。

什么是 OWNERS 文件?

“Specially named OWNERS files list usernames of people who have ownership responsibilities for a directory and its children. ”

翻译：
名为 OWNERS 的文件中，列出了对当前目录以及子目录，负有所有权的人。

在一些开源项目中，也有OWNERS文件，一般其中列出的也是一些具有所有权的用户，CICD流程可能会需要通过OWNERS文件，来判断某一个用户是否具有特定的某权限。

应该找谁来进行code review？【最重要的问题】

“A correctness and comprehension check from another engineer that the code is appropriate and does what the author claims it does.”

“Approval from one of the code owners that the code is appropriate for this particular part of the codebase (and can be checked into a particular directory).”

“Approval from someone with language “readability”3 that the code conforms to the language’s style and best practices, checking whether the code is written in the manner we expect.”

需要三个角色的人（这三个角色可以是同一个人）来进行code review：

1. 首先需要另一个工程师，检查代码的正确性和可理解性，并检查代码是否如同代码作者那样运行工作（举例：新增功能的方法名为每周执行一次某操作，但是实现却写成了每个月，那么就无法通过审查）
2. 然后我们需要代码的所有者（也就是OWNERS文件中列出的用户），检查代码所在的位置（目录或repo）是否合适。（举例：一个工具性的功能，本应该实现在utils repo中，但是现在实现在某一个业务repo中，那么就无法通过审查）
3. 需要特定编程语言的专家，来检查比如代码风格，是否使用组织要求的最佳实践等。

Best Practices 最佳实践

Be Polite and Professional - 礼貌而专业

“In general, reviewers should defer to authors on particular approaches and only point out alternatives if the author’s approach is deficient. If an author can demonstrate that several approaches are equally valid, the reviewer should accept the preference of the author.”

翻译：
普遍来说，审查者应该认可作者提交的特定方案，只有当作者的方案有明显问题的时候，才提出替代方案。如果代码作者可以说明多种方案都是同等可行的，那么审查者应该接受代码作者的偏好。

“Reviewers should be prompt with their feedback. At Google, we expect feedback from a code review within 24 (working) hours.”

翻译：
审查者应该及时的反馈。在Google，我们预期反馈在24个工作时之内。（即3天之内）

“Reviewers should avoid responding to the code review in piecemeal fashion. ”

翻译：
审查者应该避免零碎的提交审查。

这个点在github的功能设计(Start a review)上也有体现，github会缓存comment，然后整个作为一次review提交，详见

“Remember that you are not your code, and that this change you propose is not “yours” but the team’s. ”

翻译：
记住你不是你的代码（或你的代码并不是代表你），你提交的修改并不是“你的”，而是团队的。

对于这一点，可以理解为对代码的质询，并不是针对个人，所以要放下防卫心态，也要对解释方案有耐心。

Write Small Changes - 写小修改

“Probably the most important practice to keep the code review process nimble is to keep changes small.”

翻译：
可能保持代码审查足够灵活的最重要的实践，就是保持修改足够小。

“Small” changes should generally be limited to about 200 lines of code.”

翻译：
小改动应该一般限制在200行代码之内。

Write Good Change Descriptions

“A change description should indicate its type of change on the first line, as a summary. ”

一次修改的描述，应该在第一行总结的描述出该类型的修改。

“Although the first line should be a summary of the entire change, the description should still go into detail on what is being changed and why. A description of “Bug fix” is not helpful to a reviewer or a future code archeologist. ”

翻译：
虽然第一行已经总结了整个修改，但是后续的描述仍然应该包含“什么被修改”以及“为什么修改”的细节。一段“修Bug”的描述，对于当前审查者，和未来的维护者都没有什么帮助。

Keep Reviewers to a Minimum 保持reviewer尽可能的少

“Most code reviews at Google are reviewed by precisely one reviewer.”

翻译：
在Google，大部分的修改都只有一个reviwer。

The code review process is optimized around the trust we place in our engineers to do the right thing.

翻译：
我们在工程师中建立信任，而代码审查正是围绕着这种信任进行优化，以达到良好的效果。

这一点就是信任文化，其实信任文化背后则是“责任文化”，相信一个工程的LGTM就可以通过review，也就是意味着，基于这个工程师更大的权利和责任。而不是造成互相推诿，谁也不用负责的低效环境。

Automate Where Possible 尽可能的自动化

“Code review is a human process, and that human input is important, but if there are components of the code process that can be automated, try to do so. ”

翻译：
代码审查是人工的过程，所以人的输入很重要，但是如果在某些编码的部分可以被自动化，那就一定要尝试自动化。

也就是说，多多尝试各种CICD和自动化工具（笑