Google程序员他们是如何去做coder review的

点击上方“IT平头哥联盟”，选择“置顶或者星标”

你的关注意义重大！

该文档一共分为如下六篇：

1. Code Review的标准
2. Code Review关注点
3. CL阅读指南
4. Code Review 的速度
5. 如何编写Code Review 评语
6. 处理pushback

一、 Code review的标准

Code review 的主要目的是确保Google代码库的整体代码运行状况随着时间的推移而得到改善。Code review的所有工具和流程都是为此而设计的。

为了实现这一目标，必须综合考虑许多因素，并做出取舍和平衡。

首先，开发人员必须能够在任务上取得进展。如果你从不向代码库提交改进后的代码，那么代码库就永远不会得到改进。另外，如果一个reviewer使任何更改都很难进行，那么开发人员就不愿意在将来进行改进。

另一方面，reviewer有责任确保每个CL(Change Log)具有这样的质量，即随着时间的推移，其代码库的整体代码健康状况不会降低。这可能很棘手，因为代码库通常会随着时间的推移而降低代码运行状况，特别是当团队的交付受到严重的时间限制，并且他们觉得必须采取捷径才能实现目标时。

此外，reviewer对他们正在审核的代码拥有所有权和责任。他们希望确保代码库保持一致，可维护以及“code review中要注意的内容”中提到的所有其他内容。

因此，我们将以下规则作为我们在code review中期望的标准：

一般来说，如果一个 CL并不完美，但是它肯定会提高当前系统的代码整体健康度，那reviewer就应该让它通过。

这是所有code review指南中的首要原则。

当然，这是有局限性的。例如，如果一个CL添加了一个reviewer不希望在其系统中使用的功能，即使代码设计得很好，reviewer也可以拒绝批准该CL。

这里的一个关键点是，没有“完美”的代码，只有更好的代码。Reviewer不应该要求开发人员对CL的每一个微小的部分进行打磨。相反，reviewer应该在项目的进展和reviewer的改进建议两者之间做好权衡。Reviewer不应该追求完美，而应该追求持续的改进。作为一个整体，提高系统可维护性、可读性和可理解性的CL不应该因为它不是“完美的”而延迟几天或几周通过审批。

如果有些东西可以做得更好，reviewer 应该随时留下评论。但是如果该评论所建议的改进不是很重要，可以在前面加上“Nit:”这样的前缀，让作者知道这种改进只是一种锦上添花的效果，作者可以选择忽略。

注意：本文档中没有任何内容推荐合入会明显恶化系统的整体代码健康状况的CL。只有在紧急情况下你才会那样做。

指导思想

Code review的一个重要功能是教授开发人员关于语言、框架或一般软件设计原则的新知识。留下有助于开发人员学习新知识的评论是可以的。随着时间的推移，共享知识是改善系统代码健康状况的一部分。你只需要记住，如果你的评论纯粹是教育性的，但对达到本文档中描述的标准并不重要，请在其前面加上“nit:”，或者以其他方式表明作者不必在本CL中解决它。

原则

技术事实和数据优先于意见和个人偏好。

现实和数据推翻了个人喜好。在代码风格方面，风格指南（style guide）是绝对的权威。任何不在style guide中的一些点（如空格等）都是个人偏好的问题。代码风格应该与现有的一致。如果项目没有以前的统一样式，那就接受作者的样式。

软件设计的各个方面从来都不仅仅是一个纯粹的代码风格问题或者是个人喜好问题。它们是以基本原则为基础的，应当以这些原则为依据，而不仅仅是以个人意见为依据，有时几乎都没有选择的。如果作者能够证明（通过数据或基于原理的一些事实）他的方法是同样有效的，那么reviewer应该接受作者的偏好。否则，代码风格选择取决于软件设计的标准原则。

如果没有其他规则适用，那么reviewer可以要求作者与当前代码库中的内容保持一致，只要这些代码不会恶化系统的整体代码健康状况。

解决冲突

在对代码评审的任何冲突中，开发人员和reviewer应该始终根据本文档的内容以及“CL Author 's Guide“和“Reviewer Guide”中的其他文档，尝试达成一致意见。

当达成共识变得特别困难时，reviewer和作者需要进行面对面会议，而不是仅仅试图通过代码审查注释来解决冲突。（不过，如果这样做，请确保将讨论结果记录在CL的评论中，以供将来的读者阅读。）

如果这不能解决问题，最常见的解决方法就是升级。通常情况下，升级的途径是进行更广泛的团队讨论，让team leader参与进来，请求代码维护人员做出决定，或者请求技术经理提供帮助。不要因为作者和审稿人不能达成一致意见而让CL无所事事

二、 Code review关注点

注意：在考虑这些要点时，请务必同时参考“Code review的标准”。

设计

Code review 评论最重要的内容是CL的总体设计。CL中不同代码段的交互是否有意义？此更改属于你的业务代码库还是属于引进来的其他代码库？它是否与系统的其他部分很好地集成？现在是添加此功能的合适时机吗？

功能

这个CL做了开发者想要的吗？开发者对这些代码的设计初衷用户有好处吗？“用户”通常既是最终用户（当他们受到更改的影响时）又是开发人员（他们将来必须“使用”此代码）。

大多数情况下，我们希望开发人员在进行cr时能够对CL进行充分的测试，使其能够正常工作。但是，作为reviewer，仍然应该考虑边缘状况，寻找问题，尝试像用户一样思考，并确保仅通过阅读代码就不会看到错误。

如果您愿意，您可以对CL进行验证—检查CL行为最重要的时间是当它具有面向用户的影响时，例如UI更改。当您仅仅阅读代码时，很难理解一些更改将如何影响用户。对于这样的更改，如果不方便在CL中进行修补并亲自尝试，您可以让开发人员提供功能的演示。

在代码评审过程中考虑功能的另一个特别重要的时刻是，在CL中是否存在某种并发编程，这理论上可能会导致死锁或竞争条件。仅通过运行代码很难发现这类问题，通常需要有人(开发人员和review)仔细考虑这些问题，以确保没有引入问题。(注意，这也是一个不使用可能存在竞争条件或死锁的并发模型的好理由——这会使code review或理解代码变得非常复杂。)

复杂性

CL比它应该的复杂吗?在cl的每一层检查这个—单个行是不是太复杂了?函数是否过于复杂?类太复杂了吗?“太复杂”通常意味着“代码读者不能很快理解”。这也意味着“当开发人员试图调用或修改这段代码时，他们很可能会引入bug。”

一种特殊类型的复杂性是过度设计，开发人员使代码比需要的更通用，或者增加了系统目前不需要的功能。reviewer应该特别警惕过度设计。鼓励开发人员解决他们知道现在需要解决的问题，而不是解决开发人员推测将来可能需要解决的问题。未来的问题应该在它到来后解决，你可以看到它在物理宇宙中的实际形状和需求。

测试

请将单元测试、整合测试、端到端测试视为要求CL所做的适当变更。一般CL内除了生产环境的业务代码外，测试也应该要被加入其中。除非该CL是为了处理某个紧急事情而存在。

另外，也要确保测试是正确、合理、有用的。测试并非来测试它们本身，一般也极少为了测试而测试（如测试一下测试代码有没有问题又走了测试流程），因此我们要保证测试是有效的。

当代码真的有问题，测试是否会失败？如果被测试的程序发生改动时，测试是否会产生误报？每一个测试是否做出了简单而有用的断言？不同的测试方法之间的测试是否适当分开？

请记住，测试代码也是必须维护的代码，不要因为它们不在主要关注的范围内。

命名

开发人员是否为所有东西都选择了好名字?一个好的名字应该足够长，从而可以充分地表达条目是什么或做了什么，并且不会长到让人难以阅读。

推荐参考文章「Clean code 101 — Meaningful names and functions」: https://medium.com/coding-skills/clean-code-101-meaningful-names-and-functions-bf450456d90c

注释

开发人员是否用可理解的英语编写了清晰的注释?所有的评论都是必要的吗?通常注释是解析这段代码为什么存在的时候是相当有用的，而不应该去解释某段代码正在做什么。如果代码本身不能解释清楚的话，意味着它更加需要简化了。当然也有例外，比如解释正规的表达式或者复杂的算法正在做什么的时候，注释解释这段代码正在做什么就相当有用。但对于大部分注释来说是用来说明那些不包含在程序本身但资讯，比如说为什么要这样子做的理由

查看CL之前的评论也会很有帮助。也许现在有一个可以删除的待办事项，一个建议不要做这个更改的评论，等等。

注意，注释不同于类、模块或函数的文档，这些文档应该表示代码的用途、应该如何使用以及使用时的行为。

风格

Google 对于主要语言都有提供风格指南（http://google.github.io/styleguide/），甚至包括大多数小众语言。确保CL遵循适当的样式指南。

如果你想改进CL中某些不包含在风格指南中的要点时，请在评论前加上Nit: ，让开发人员知道这是你认为可以改善代码的小问题且并非强制性的。但记住，不要仅根据个人风格偏好阻止提交CL。

开发者不应该在 CL内同时包含主要风格的改动与其他代码的修改，这样会导致难以看出CL到底做出什么改动。同时也会让合并和回滚更为复杂，并产生其他问题。例如，如果作者想要重新格式化代码的话，让他们将新格式在一个新CL里面重构。

文档

如果CL更改了用户构建、测试、交互或发布代码的方式，请检查它是否还更新了相关文档，包括READMEs、g3doc页面和任何生成的参考文档。如果CL删除或弃用代码，请考虑是否也应该删除文档。如果缺少文档，就去问作者要。

每行代码

查看分配给您的每一行代码。有些东西，比如资料文件(data files)、生成的代码(generated code)、大型数据结构(large data structures)，您有时可以大致浏览一下。但是由开发者编写的类、函数或代码块不能粗略的浏览，去假设它内部是没问题的。很显然的某些代码需要比其他代码更仔细的review。这是必须由你做出的判断，但至少你应该确定你理解所有代码在做些什么。

如果这段代码您阅读起来比较费劲，并且会减慢评审的速度，那么您应该让开发人员知道这一点，并在您尝试评审之前等待他们澄清它。在Google 我们聘请许多优秀的软件工程师，而你也是其中的一员。如果连你也无法理解的话，很可能其他人也不会。因此，你要求开发者去说清楚这段代码时，同时也在帮助未来的开发人员理解这些代码。

如果你能够理解review的代码，但是您觉得不能胜任这次review，请确保 reviewer中有一个适合(合格) 的人来review该部分。尤其是针对安全性、并发性、可访问性、国际化等复杂问题时。

上下文

在广泛的上下文中查看CL通常是有帮助的。一般地，code review工具只会显示正在更改的部分周围的几行代码。有时您必须查看整个文件，以确保更改实际上是有意义的。例如，您可能只看到添加了四行，但是当您查看整个文件时，您会看到这四行位于一个50行方法中，现在确实需要将其分解为更小的方法。

在整个系统的上下文中考虑CL也很有用。这个CL是提高了系统的代码健康度，还是使整个系统更复杂、测试更少等等?不要接受降低系统代码健康度的CLs。大多数系统都是通过许多累积起来的小更改而变得复杂的，因此，即使是防止在新更改中引入很小的复杂性也是很重要的。

处理CL中好的方面

如果您在CL中看到一些不错的东西，请告诉开发人员，特别是当他们以一种很好的方式处理您的一条评论的改进建议。Code review通常只关注错误，但是它们也应该为好的实践提供鼓励和赞赏。有时候，在指导方面，告诉开发人员他们做对了什么比告诉他们他们做错了什么更有价值。

总结

在code review过程中你应确保:

代码设计得很好。

该功能对代码的用户（开发人员以及系统的用户）有益。

任何UI更改都是合理的，看起来也不错。

任何并发编程都是安全的。

代码并不比它需要的复杂。

开发人员没有实现他们将来可能需要但不知道现在是否需要的东西。

代码有适当的单元测试。

单元测试是精心设计过的。

开发人员在代码中的所有命名都是清晰的。

注释清晰有用，主要解释为什么而不是解释是什么。

代码被合适地文档化了(通常在g3doc中)。

代码符合我们的样式指南。

确保检查您被要求检查的每一行代码，查看上下文，确保您正在改进代码的健康状况，并赞扬开发人员做的好的地方。

三、 CL阅读指南

摘要

既然您知道“Code review关注点”，那么管理跨多个文件的codereview的最有效方法是什么?

这种变化有意义吗? CL(change log)的描述清晰明了吗?

首先看看CL中最重要的部分。CL的整体设计好吗?

按照适当的顺序查看CL的其余部分。

第一步:从全局的视角看下CL

看看CL的描述，以及CL大概做了什么。CL涉及的变更有意义吗?如果这个变更一开始就不应该发生，请立即回复并解释为什么不应该发生变更。当您拒绝这样的变更时，最好也向开发人员建议他们应该做什么。

例如，你可以说“看起来你在这方面做得不错，谢谢!”不过，我们实际上准备删除你在修改的FooWidget系统，所以我们现在不想对它做任何新的修改。你不如来重构我们的新BarWidget类?”

注意，review不仅要在拒绝了当前的CL时提供一个替代的建议，而且很有礼貌的拒绝。这种礼貌是很重要的，因为我们想要表现出即使我们意见不一致，我们作为开发人员也彼此尊重。

如果您发现出现多个你不希望进行更改的CLs，那么您应该重新考虑一下团队的开发流程或外部贡献者发布的流程，以便在他们编写CLs之前跟你有更多的沟通。最好在人们完成大量工作之前就说“不”，这些工作现在必须扔掉或彻底重写。

第二步：检查CL的主要部分

找出这个CL的“主要”部分，CL的主要部分一般是一个或者几个文件。通常，只有一个文件具有最多的逻辑更改，它是CL的主要部分。首先看看这些主要部分。这有助于为CL的所有较小部分提供上下文，并且通常这会加速代码评审。如果CL太大，您无法确定哪些部分是主要部分，请询问开发人员应该首先查看什么，或者让他们将CL分割成多个CLs。

如果您看到CL的这一部分存在一些主要的设计问题，您应该立即给出反馈，即使您现在没有时间来检查CL的其余部分。事实上，检查CL的其余部分可能是浪费时间，因为如果设计问题足够严重，那么许多其他正在检查的代码后面可能会删掉或者重构，不管怎样都无关紧要。
如果主要设计有缺陷，立即给出反馈非常重要，有两个主要原因：

开发人员通常会提交一个CL，然后在等待评审时立即基于该CL开始新的工作。如果您正在检查的CL中存在主要的设计问题，那么他们还必须重新编写后面的CL。您应该在它们在有问题的设计上做过多额外工作之前阻止它们。

大的设计变更比小的变更需要更长的时间。开发人员的任务几乎都有截止日期;为了在代码库中保持高质量代码的同时在这些截止日期前完成任务，开发人员需要尽快开始对CL主要问题进行修改。

第三步：以适当的顺序查看CL的其余部分

一旦你确认整个CL没有重大的设计问题，试着找出一个逻辑序列来查看这些文件，同时确保你不会漏看任何文件。通常在查看主要文件之后，最简单的方法是按照代码审查工具向您提供的顺序浏览每个文件。有时在阅读主代码之前先阅读测试也很有帮助，因为这样你就可以了解CL做了什么。

四、 Code review 的速度

为什么code review 要快？

在谷歌中，我们针对开发团队共同开发产品的速度进行优化，而不是针对单个开发人员编写代码的速度进行优化。个人发展的速度很重要，但是没有整个团队的速度重要。

当code review很慢时，会发生以下几件事：

整个团队的速度降低了。如果一个人对评审的反应不是很快，他虽然在这期间做了一些其他的工作，但是，由于每个CL都要等待一次又一次的评审，团队其他成员的新特性和bug修复会延迟几天、几周或几个月。

开发人员开始抗议code review过程。如果reviewer每隔几天才回复一次，但每次都要求对CL进行重大更改，这对开发人员来说可能是令人沮丧和困难的。通常，这表现为对reviewer的“严格”的抱怨。如果reviewer请求相同的实质性更改(这些更改确实改善了代码的健康状况)，但是每次开发人员进行更新时都会快速响应，那么抱怨就会消失。对代码评审过程的大多数抱怨实际上是通过加快过程来解决的。

代码健康状况会受到影响。当评审速度较慢时，允许开发人员提交不如预期的CLs的压力就会增加。缓慢的评审还会阻碍代码清理、重构和对现有CLs的进一步改进。

代码评审应该有多快？

如果您没有集中精力完成任务，那么应该在任务完成后不久进行代码检查。

一个工作日是响应代码审查请求所需的最长时间（即第二天早上的第一件事）。

遵循这些指导原则意味着一个典型的CL应该在一天内(如果需要的话)进行多轮评审。

速度与中断

有一段时间，对个人速度的考虑超过了对团队速度的考虑。如果你正在集中精力做一项任务，比如写代码，不要打断自己去做codereview。研究表明，开发人员在中断开发之后，可能需要很长时间才能恢复到平稳的开发流程。因此，对团队来说，在编写代码时打断自己实际上比让另一个开发人员等待code review的时间更昂贵。

相反，在你的工作中等待一个断点，然后你才回应一个审查的请求。这可能是当你当前的编码任务完成时，午饭后，从会议回来，从微型厨房回来，等等。

快速反应

当我们讨论代码评审的速度时，我们关心的是响应时间，而不是CL完成整个评审并提交所需的时间。理想情况下，整个过程也应该是快速的，但是对于单个响应的快速响应比整个过程的快速响应更重要。

即使有时需要很长时间才能完成整个评审过程，但是在整个过程中reviewer的快速响应可以极大地减轻开发人员对“缓慢”code review的沮丧。

如果在一个CL提交过来时，你太忙了,难以做一个完整的review,你仍然可以发送一个快速反应,让开发人员知道什么时候你会开始review,建议由其他reviewer来评审可以更快地响应的效果,或者提供一些最初的粗略评论。(注意:这并不意味着您应该中断编码，即使是为了发送这样的响应—也应该在您工作中的一个合理的断点发送响应。)

重要的是reviewer要花足够的时间进行评审，以确保他们的“LGTM”的意思是“这段代码符合我们的标准”。然而，个人的反应最好还是要快。

跨时区评论

当处理时区差异时，试着在作者还在办公室的时候给出回应。如果他们已经回家了，那么在他们第二天回到办公室之前，确保你的评估已经完成。

LGTM评论

为了加快code review的速度，在某些情况下，reviewer应该给出LGTM/Approval，即使他们还在CL上留下未解决的注释。这是在以下两种情况下完成的:

reviewer确信开发人员将适当地处理reviewer剩余的所有评论。

其余的更改是次要的，开发人员不一定非要完成。

如果不清楚，reviewer应该指定他们想要的选项。

当开发人员和reviewer处于不同的时区时，使用带有注释的LGTM尤其值得考虑，否则开发人员将会等待一整天，只为获得“LGTM，批准”。

大型CLs

如果有人给你提交了一个非常大的CL，你不知道什么时候你能有时间去review它,你的典型的反应应该要求开发人员把CL分割成几个较小的CLs,而不是一个巨大的CL必须一次性审查。这通常是可行的，并且对reviewer非常有帮助，即使这需要开发人员做额外的工作。

如果CL无法分解为较小的CL，并且您没有时间快速查看整个内容，那么至少要对CL的整体设计写一些评论并将其发送回开发人员以进行改进。作为reviewer，您的目标之一应该是始终取消阻止开发人员或使他们能够快速采取某种进一步的操作，而不会牺牲代码运行状况。

Code review随时间的改进

如果您遵循这些指导原则，并且对code review非常严格，那么您应该会发现，随着时间的推移，整个code review过程会变得越来越快。开发人员了解健康代码需要什么，并从一开始就向您发送非常棒的CLs，这使得需要的评审时间越来越少。reviewer学会快速响应，而不是在评审过程中添加不必要的延迟。但是不要为了提高速度而牺牲code review标准或质量——从长远来看，这实际上不会使任何事情发生得更快。

紧急情况

在一些紧急情况下，CLs必须非常快速地通过整个评审过程，并且不会严格按照质量指南来要求它。但是，请看看什么是紧急情况?用于描述哪些情况实际上符合紧急情况，哪些不符合紧急情况。

五、 如何编写code review 评语

摘要

对人友善

解释你的观点

在给出明确的指示与指出问题并让开发人员决定之间保持平衡。

鼓励开发人员简化代码或添加代码注释，而不仅仅是向您解释复杂性

礼貌

一般来说，礼貌和尊重是很重要的。并且您也要对review对象非常明了和有帮助。一种方法是确保您总是对代码进行评论，而从不对开发人员进行评论（译者注：对事不对人）。你不必总是遵循这个习惯，但是当你说一些可能会让人心烦意乱或有争议的话时，你绝对应该使用这个习惯。例如:

反例:“为什么您在这里使用线程，但是没有从并发中获得任何好处?”

正例:“这里的并发模型增加了系统的复杂性，但我看不到任何实际的性能优势。因为没有性能上的好处，所以这段代码最好是单线程的，而不是使用多线程。”

解释为什么

关于上面的正面示例，您将注意到的一件事是，它帮助开发人员理解您为什么要发表评论。您并不总是需要在评审注释中包含这些信息，但是有时候，对于您的意图、您所遵循的最佳实践，或者您的建议如何改进代码健康状况，给出更多的解释是合适的。

提供指导

一般来说，修复CL是开发人员的责任，而不是review的责任。您不需要为开发人员提供解决方案的详细设计或编写代码。

不过，这并不意味着review应该毫无帮助。一般来说，你应该在指出问题和提供直接指导之间取得适当的平衡。指出问题并让开发人员做出决策通常有助于开发人员学习，并使code review变得更容易。它还可以产生更好的解决方案，因为开发人员比reviewer更接近代码。

但是，有时直接的指令，建议甚至代码会更有帮助。Code review的主要目标是获得最佳的CL。第二个目标是提高开发人员的技能，以便他们随着时间的流逝需要越来越少的审查。

接受解释

如果您要求开发人员解释一段您不理解的代码，这通常会帮助他们更清楚地重写代码。偶尔，在代码中添加注释也是一种适当的响应，只要它不只是解释过于复杂的代码。

仅在code review工具中编写的解释对将来的代码读者没有帮助。它们只在少数情况下是可接受的，例如当您正在review一个您不太熟悉的区域，并且开发人员仅仅解释了一些代码的显而易见的内容时。

六、 处理回退

有时开发人员会抵制code review。要么他们不同意你的建议，要么他们会抱怨你总体上过于严格。

谁是对的？

当开发人员不同意您的建议时，请先花点时间考虑一下它们是否正确。通常，开发人员比您更接近代码，因此可能实际上他们对代码的某些方面比您更了解一些。他们的论点有意义吗？从代码健康角度来看，这有意义吗？如果是这样，请让他们知道他们是对的，然后解决问题。

然而，开发人员并不总是正确的。在这种情况下，reviewer应该进一步解释为什么他们认为他们的建议是正确的。一个好的解释不仅说明了对开发人员的回答的理解，也说明了为什么开发人员需要做出更改的附加信息。

特别是，当reviewer认为他们的建议将改善代码的健康状况时，如果他们认为所产生的代码质量改进能够证明所要求的额外工作是合理的，那么他们应该继续提倡更改。改善代码健康状况往往是一些小步骤。

有时候，为了让开发人员真正理解您的一个建议之前，您需要花几轮时间来解释它。您只要确保始终保持礼貌，并让开发人员知道您听到了他们在说什么，您只是不同意。

令开发人员不安

reviewer有时认为，如果自己坚持要进行改进，开发人员会感到不安。有时候开发人员确实会感到沮丧，但是这通常是很短暂的，之后他们会非常感谢您帮助他们提高了代码的质量。通常，如果您在评论中表现得很有礼貌，开发人员实际上一点也不会感到不安，而这种担心只存在于您的脑海中。通常，令人不安的地方更多的是评论的编写方式，而不是reviewer对代码质量的坚持。

稍后清理

回退的一个常见原因是开发人员（可以理解）想要完成任务。他们不想仅仅为了获得此CL而进行另一轮审核。因此，他们说他们将在以后的CL中清除某些内容，因此您现在应该LGTM此CL。一些开发人员对此非常好，并会立即编写后续的CL来解决此问题。但是，经验表明，开发人员在编写原始CL之后花费的时间越多，清理工作的可能性就越小。实际上，通常除非开发人员在当前CL之后立即进行清理，否则它永远不会发生。这不是因为开发人员不负责任，而是因为他们有很多工作要做，而清理工作却在其他工作中被遗忘或遗忘。因此，通常最好是坚持要求开发人员在代码进入代码库并“完成”之前立即清理其CL。让人们“稍后清理”是代码库退化的一种常见方法。

如果CL引入了新的复杂性，在提交之前必须清理它，除非是紧急情况。如果CL暴露了周围的问题，而这些问题现在还无法解决，开发人员应该为清理工作提交一个bug文件，并将其分配给自己，这样它就不会丢失。他们还可以选择在引用已归档错误的代码中编写TODO注释。

对严格的普遍抱怨

如果您以前有相当松散的代码评审，而现在您转而进行严格的评审，那么一些开发人员将会非常大声地抱怨。提高代码评审的速度通常会使这些抱怨逐渐消失。

有时，这些抱怨可能要花费数月的时间才能消失，但是最终，开发人员往往会看到严格的代码审查的价值，因为他们会看到自己帮助生成的出色代码。有时，一旦发生某种事情，使严格的抗议者甚至成为您最坚强的支持者，这会使他们真正地看到自己在增加的价值。

解决冲突

如果您遵循上述所有方法，但是您仍然遇到您自己和开发人员之间无法解决的冲突，请参阅代码评审标准，了解有助于解决冲突的指导原则和原则。

原文: https://google.github.io/eng-practices/review/reviewer/

❤️ 看完两件事

如果你觉得这篇内容对你有所帮助，我想邀请你帮我两个小忙：

1. 点个「在看」，让更多的人也能看到这篇内容（喜欢不点在看，都是耍流氓 -_-）
2. 关注公众号「IT平头哥联盟」，一起进步，一起成长！

推荐阅读：