共计 3598 个字符，预计需要花费 9 分钟才能阅读完成。
最近在读《Software Engineer at Google》一书，其中笼罩软件工程的内容非常全面，然而我当初能够实际的可能只占十之二三。而其中看来最有用的，就是 Code Review 的局部。
本文将书中我认为最启发，最重要的常识，已摘要模式出现，并附带我的集体了解。对于内容带有跳跃和简化，只分为了 2 个局部：
- Foundation Concepts 根底概念
- 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：
- 首先须要另一个工程师，查看代码的正确性和可了解性，并查看代码是否如同代码作者那样运行工作（举例：新增性能的办法名为每周执行一次某操作，然而实现却写成了每个月，那么就无奈通过审查）
- 而后咱们须要代码的所有者（也就是 OWNERS 文件中列出的用户），查看代码所在的地位（目录或 repo）是否适合。（举例：一个工具性的性能，本应该实现在 utils repo 中，然而当初实现在某一个业务 repo 中，那么就无奈通过审查）
- 须要特定编程语言的专家，来查看比方代码格调，是否应用组织要求的最佳实际等。
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 和自动化工具（笑
