接上篇：google code review系列1 - code review的标准 。本片主要讲述我们应该在code review中寻找什么？也就是我们应该在code review中关注什么？主要的关注点应该集中在哪里？下面我们看看google是如何做的。
翻译：
https://google.github.io/eng-practices/review/reviewer/standard.html
Code Review名词解释
| 缩写 | 说明 |
| CR | code review |
| CL | change list，指这次改动 |
| reviewer | cr的那个review人 |
| Nit | 全称nitpick，意思是鸡蛋里挑骨头 |
LGTM | "Looks Good to Me."的缩写，看起来不错，评审者批准CL时会这么说。 |
整个Code Review分成如下五个部分，本节主要讲述Google在code review中寻找什么？
目录
code review的标准
在code review中寻找什么
浏览审查中的CL
code review的速度
如何编写code review注释
处理code review中的pushback
设计
Code review最重要的事情是要全面覆盖到CL的整体设计。CL中的各个代码是否能够正常交互？这个更改属于您的代码库，还是lib包？它与系统的其他部分集成得好吗？现在是添加此功能的恰当时机吗？
功能
这个CL中，开发人员的目的是什么？开发人员的意图对这段代码的“用户”有好处吗? 这里”用户“是指受变更影响到的终端用户，和将来会使用到这些代码的开发者。
大多数情况下，我们希望开发人员能够很好地测试CLs，以便在进行code review的时候，代码能够正确地工作。然而，作为reviewer，您仍然应该考虑一些边界情况，寻找并发性问题，尝试像用户一样思考问题，并确保不会看到仅通过阅读代码就能发现的错误。
你可以验证CL，对于reviewer来说，哪些对面向用户有影响的CL尤其重要，例如：UI的变更。检查CL的行为是非常重要的尤其是在有面向用户的影响时，评审者应该仔细检查整个变更。当reviewer仅仅阅读代码时，很难理解一些更改将如何影响用户。对于这样的CL，如果在CL中打补丁太不方便，您可以让开发人员给您演示该功能，然后自己尝试。
在code review过程中考虑功能的另一个特别重要的时刻是，在CL中是否存在某种并发编程，这理论上可能会导致死锁或竞争条件。仅通过运行代码很难发现这类问题，通常需要有人(开发人员和reviewer)仔细考虑这些问题，以确保没有引入新的问题。(所以除了死锁和资源争抢之外，增加code review复杂度也可以成为拒绝使用多线程模型的一个理由)
复杂性
CL是否比它应该的更复杂？检测CL的每一个级别，是否个别行太复杂？功能是否太复杂？类是否太复杂？”复杂“意味着代码阅读者很难快速理解代码，也可意味着开发者尝试调用或修改此代码时可能会引入bug。
一种典型的复杂性问题就是过度设计导致的。开发人员设计代码的时候，为了让代码比需要的更通用，或者增加了系统目前不需要的功能。reviewer应该特别警惕过度设计。鼓励开发人员解决他们知道现在需要解决的问题，而不是解决开发人员推测将来可能需要解决的问题。未来的问题应该在它到来后解决，到那个时间，你才能看到问题的本质和实际的需求。
测试
根据CL的需求进行单元测试、集成测试或端到端测试。一般来说，变更中应该包含测试，除非这个变更只是为了处理紧急情况。
确保CL中的测试是正确的、合理的和有用的。因为测试本身无法进行自我测试，而且我们很少为我们的测试编写测试，我们必须确保测试是有效的。
当代码被破坏时，测试真的会失败吗？如果它们下面的代码发生了变化，它们会开始产生误报吗？每个测试都做出简单而有用的断言吗？测试是否在不同的测试方法之间适当地分开？
请记住，测试也是必须维护的代码。不要仅仅因为测试不是主分支的一部分就接受测试中的复杂性。
命名
开发人员是否为所有东西都选择了好名字？一个好的名字足够长，可以充分传达该项目是什么或是做什么，而不会太长以至于难以阅读。
注释
开发人员是否用可理解的英语编写了清晰的注释？所有的注释都是必要的吗？通常，注释在解释某些代码为什么存在时很有用，而不应该解释某些代码在做什么。如果代码不够清晰，无法达到自解释，那么应该简化代码。也有一些例外(例如，解释正则表达式和复杂算法在做什么通常帮助很大)，但大多数注释是针对代码本身不可能包含的信息，比如决策背后的推理。
变更中附带的其他注释也很重要，比如列出一个可以移除的待办事项，或者一个不要做出代码变更的建议，等等。
注意，注释不同于类、模块或函数的文档，这些文档应该表示代码的用途、应该如何使用以及使用时的行为。
风格
在谷歌内部，主流语言甚至部分非主流语言都有编码风格指南 ，确保变更遵循了这些风格规范。
如果你想对风格指南中没有提及的风格做出改进，可以在注释前面加上“Nit:”，让开发人员知道这是一个你认为可以改进的地方，但不是强制性的。但请不要只是基于个人偏好来阻止变更的提交。
开发人员不应该将风格变更与其他变更放在一起，这样很难看出变更里有哪些变化，让合并和回滚变得更加复杂，也会导致更多的其他问题。如果开发者想要重新格式化整个文件，让他们将重新格式化后的文件作为单独的变更，并将功能变更作为另一个变更。
一致性
如果现有代码与样式指南不一致怎么办？根据我们的code review原则，样式指南是绝对权威的：如果样式指南有要求，CL应该遵循指南。也就是说如果公司有代码样式的规范，必须遵循公司的规范
在某些情况下，样式指南会提出建议，而不是声明要求。在这些情况下，新准则是否应该与建议或周围准则保持一致是一个判断问题。倾向于遵循风格指南，除非局部的不一致性太令人困惑。
如果没有其他规则适用，作者应与现有代码保持一致。
不管怎样，都要鼓励作者提交一个bug，并添加一个TODO来清理现有代码。
文档
如果CL更改了用户构建、测试、交互或发布代码的方式，请检查它是否还更新了相关文档，包括READMEs、g3doc页面和任何生成的参考文档。如果CL删除或弃用代码，请考虑是否也应该删除文档。如果缺少文档，就去问作者要。
每一行
查看分配给您code review的每一行代码。有些东西，比如数据文件、生成的代码或大型数据结构，您有时可以大致浏览一下，但是由人编写的类、函数或代码块不能粗略的浏览，并假定其中的内容是正确的。显然，有些代码需要比其他代码检查的更仔细—这是您必须做出的判断—但是您至少应该确保您理解所有代码在做什么。
如果这段代码您阅读起来比较费劲，并且会减慢评审的速度，那么您应该让开发人员知道这一点，并在您尝试评审之前等待他们澄清它。在谷歌，我们雇佣优秀的软件工程师，你就是其中之一。如果您不能理解代码，其他开发人员也很可能无法理解。因此，当您要求开发人员澄清这些代码时，您也在帮助未来的开发人员理解这些代码。
如果您理解所review的代码，但是您觉得不能胜任这次reviewer，那么请确保针对这个CL有一个合格的reviewer，特别是对于复杂的问题，比如安全性、并发性、可访问性、国际化等等。
上下文
在广泛的上下文中查看CL通常是有帮助的。一般地，code review工具只会显示正在更改的部分周围的几行代码。有时您必须查看整个文件，以确保更改实际上是有意义的。例如，您可能只看到添加了四行，但是当您查看整个文件时，您会看到这四行位于一个50行方法中，现在确实需要将其分解为更小的方法。
在整个系统的上下文中考虑CL也很有用。这个CL是提高了系统的代码健康度，还是使整个系统更复杂、测试更少等等?不要接受降低系统代码健康度的CLs。大多数系统都是通过许多累积起来的小更改而变得复杂的，因此，即使是防止在新更改中引入很小的复杂性也是很重要的。
例外情况
如果对你来说review每一行都没有意义呢？例如，您是CL的多个审阅者之一，可能会被请求：
仅查看较大变更中的某些文件。
仅review CL的某些方面，如顶层设计、隐私或安全影响等
这种情况下，请在评论中说明你review了哪些部分。给与LGTM的评论。
如果您希望其他reviewer给与LGTM的评论，可以在评论中明确指出，即设定你的期望值，目的是在CL达到所需的状态后快速响应。
处理CL中好的方面
如果您在CL中看到一些不错的东西，请告诉开发人员，特别是当他们以一种很好的方式处理您的一条评论的改进建议。Code review通常只关注错误，但是它们也应该为好的实践提供鼓励和赞赏。有时候，在指导方面，告诉开发人员他们做对了什么比告诉他们他们做错了什么更有价值。
总结
在code review过程中你应确保:
代码设计得很好。
该功能对代码的用户（开发人员以及终端用户）有益。
任何UI更改都是合理的，看起来也不错。
任何并发编程都是安全的。
代码并不比它需要的复杂。
开发人员没有实现他们将来可能需要但不知道现在是否需要的东西。
代码有适当的单元测试。
单元测试是精心设计过的。
开发人员在代码中的所有命名都是清晰的。
注释清晰有用，主要解释为什么而不是解释是什么。
代码被合适地文档化了(通常在g3doc中)。
代码风格符合规范。
确保检查您被要求检查的每一行代码，查看上下文，确保您正在改进代码的健康状况，并赞扬开发人员做的好的地方。
往期阅读
google code review系列1 - code review的标准
云原生之可观测性-OpenTracing、OpenSensus、OpenTelemetry
HBase、Cassandra、LevelDB、RocksDB 相关数据结构是什么？
快乐程序员、读书狂魔、爱撸代码、开源项目、硬核互联网技术分享
觉得写得不错，请点在看，谢谢！
187
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
