现在你已经知道了 Code Review 要点，那么管理分布在多个文件中的评论的最有效方法是什么？
- 变更是否有意义？它有很好的描述吗？
- 首先看一下变更中最重要的部分。整体设计得好吗？
- 以适当的顺序查看 CL 的其余部分。
第一步：全面了解变更
查看 CL 描述和 CL 大致上用来做什么事情。这种变更是否有意义？如果在最初不应该发生这样的变更，请立即回复，说明为什么不应该进行变更。当你拒绝这样的变更时，向开发人员建议应该做什么也是一个好主意。
例如，你可能会说“看起来你已经完成一些不错的工作，谢谢！但实际上，我们正朝着删除你在这里修改的 FooWidget 系统的方向演进，所以我们不想对它进行任何新的修改。不过，你来重构下新的 BarWidget 类怎么样？“
请注意，审查者不仅拒绝了当前的 CL 并提供了替代建议，而且他们保持礼貌地这样做。这种礼貌很重要，因为我们希望表明，即使不同意，我们也会相互尊重。
如果你获得了多个你不想变更的 CL，你应该考虑重整开发团队的开发过程或外部贡献者的发布过程，以便在编写CL之前有更多的沟通。最好在他们完成大量工作之前说“不”，避免已经投入心血的工作现在必须被抛弃或彻底重写。
第二步：检查 CL 的主要部分
查找作为此 CL “主要”部分的文件。通常，包含大量的逻辑变更的文件就是 CL 的主要部分。先看看这些主要部分。这有助于为 CL 的所有较小部分提供上下文，并且通常可以加速代码审查。如果 CL 太大而无法确定哪些部分是主要部分，请向开发人员询问你应该首先查看的内容，或者要求他们将 CL 拆分为多个 CL。
如果在该部分发现存在一些主要的设计问题时，即使没有时间立即查看 CL 的其余部分，也应立即留下评论告知此问题。因为事实上，因为该设计问题足够严重的话，继续审查其余部分很可能只是浪费宝贵的时间，因为其他正在审查的程序可能都将无关或消失。
立即发送这些主要设计评论非常重要，有两个主要原因：
- 通常开发者在发出 CL 后，在等待审查时立即开始基于该 CL 的新工作。如果你正在审查的 CL 中存在重大设计问题，那么他们以后的 CL 也必须要返工。你应该赶在他们在有问题的设计上做了太多无用功之前通知他们。
- 主要的设计变更比起小的变更来说需要更长的时间才能完成。开发人员基本都有截止日期；为了完成这些截止日期并且在代码库中仍然保有高质量代码，开发人员需要尽快开始 CL 的任何重大工作。
第三步：以适当的顺序查看 CL 的其余部分
一旦你确认整个 CL 没有重大的设计问题，试着找出一个逻辑顺序来查看文件，同时确保你不会错过查看任何文件。 通常在查看主要文件之后，最简单的方法是按照代码审查工具向你提供的顺序浏览每个文件。有时在阅读主代码之前先阅读测试也很有帮助，因为这样你就可以了解该变更应当做些什么。
