代码评审步骤
概要
现在你知道了要从CL中得到什么，那能在众多文件中完成评审的方法是什么？
这条改动是否生效？这次变更是不是描述清晰?
首先阅读CL最重要的一部分，整体上是否设计良好？
按照合适的顺序阅读剩下的变更。
第一步: 综观这个改动
阅读CL描述并且明白CL大体内容。这些修改是否有意义？首先如果这个修改不应该有，请立刻说明为什么这些修改不应该有。当你因为这个拒绝了这次改动提交时，告诉开发人员该怎么去做是非常好的。
例如，您可能会说：“看起来您为此做了一些出色的工作，谢谢！但是，我们实际上正着手删除FooWidget系统，您正在此处进行修改，因此我们不想进行任何新的修改现在。所以，您可以重构我们的新BarWidget类吗？"
请注意，审阅者不仅拒绝了当前的CL并提供了替代建议，但他们礼貌地做到了。这种礼貌是重要，因为我们想表明我们甚至在开发人员之间也相互尊重，尤其是当我们意见不同时。
如果您得到的多个CL并且您不想进行的更改，您应该考虑重新设计团队的开发流程或发布的外部贡献者的流程，以便在CL完成之前进行更多的交流。最好在做大量工作之前告诉人们“不必做”，因为现在要将其丢弃或彻底重写。
第二步: 检查CL的主要部分
查找属于此CL的“主要”部分的文件。通常来说一个CL最重要的部分是它逻辑修改数最多的那个文件。这样有助于了解相关的CL，通常来说会加快代码评审。如果CL太大，您无法确定哪些部分是主要部分，请开发人员告诉你应该首先看什么，或要求他们将CL拆分为多个CL。
如果您发现CL的这一部分存在一些主要的设计问题，则即使您现在没有时间审查CL的其余部分，也应立即写下这些评注。 实际上，检查其余的CL可能会浪费时间，因为如果设计问题足够严重，那么许多其他正在检查的代码将消失并且无论如何都不会发生。
立即写下这些主要设计评注非常重要有两个主要原因：
开发人员通常会发送给审核者一个CL，然后在等待审核时立即基于该CL进行新工作。 如果您正在审查的CL中存在重大设计问题，那么他们也将不得不重新设计其以后的CL。你能在他们做太多无用功之前制止他们。
重要的设计变更比小的变更需要更长的时间。 开发人员几乎都有截止日期；为了在截止日期之前完成工作， 并在代码库中保留高质量的代码，开发人员需要尽快开始CL的所有主要的重做。
第三步:依序阅读CL的其余部分
确认CL整体上没有大的设计问题后，请尝试找出逻辑顺序来浏览文件，同时还要确保不要错过对任何文件的审查。通常，在浏览了主要文件之后，按照代码审查工具向您展示它们的顺序浏览每个文件是最简单的。有时在阅读主要代码之前先阅读测试代码也是有帮助的，因为这样您就可以知道更改应该做什么。
下一节: 代码评审的速度
Last updated