代码审核的建议路径
汇总
当你知道该如何审核代码之后，如何有效率的在多个文件中进行审核呢？
- 变更合理吗？有没有适当的描述？
- 优先确认变更提交中的核心部分有没有经过良好设计？
- 确认变更提交中的其他部分都是有良好排序的。
第一步：对变更进行概览
查看变更的描述并且对变更提交整体的浏览。变更是否合理？如果一开始就发现变更不应该发生，就应当立即解释原因和理由。当你拒绝这个变更的时候，最好也能够提出建议开发者应该怎么做。
例如你可以这样说“感谢你投入时间并且产出了这么优秀的成果，但是我们实际上正在规划移除你修复的FooWidget 这个模块，我们也不希望现在再对这个模块进行新的调整。你是否有兴趣重构一下我们的BarWidget 类？”
注意这并不是仅仅审核者拒绝变更提交并且提供其他选择性建议，关键在于礼貌。我们对于所有的开发者礼貌性，即使我们拒绝了他们的提交。
如果你收到了比较多不需要的变更提交，就应该考虑优化你们的研发流程管理或者提交流程，在编写代码前能够有更多的沟通来预防这样的事情出现。应该在大家写出一大堆代码之前就制止，比写完后直接放弃或者重构好的多。
第二步：检查变更的核心部分
找到变更提交中的核心部分的文件。通常就是包含最多逻辑变更的一个文件，也是变更提交中最主要的部分，优先看这部分代码。这有助于你理解变更中其他较小的部分，从而能够加快你审核的速度。如果你发现一份提交变更太大而很难发现核心部分，可以直接询问开发者或者要求他们切分成多个较小的提交清单。
如果你发现提交的核心部分存在设计问题，你应该立即提交你的评论，即使你当前还没有看过其他部分的代码。实际上这时候去看代码的其他部分也是浪费时间，因为核心的设计问题已经足够重要了，可能会影响剩余的大部分代码。
下面给出发现核心代码后立即反馈并停止审核的两个主要原因：
- 开发者一般在提交了变更清单后就会立即基于当前变更的分支进行新的开发，而不会等待审核完成。如果你审核的代码中存在核心设计问题，他们后续的提交也是需要重构。你需要能够减少他们在后续无效工作上的投入。
- 核心设计变更一定比小项变更花更多时间。开发者一般都有会截止时间，为了能够按时并且高质量完成编码工作，开发者需要立即开始重构工作。
第三部：按照合理的顺序来查看变更提交的剩余部分
一旦能够确认提交中不存在核心的设计问题，应当要考虑剩余文件的合理查看顺序了，从而不会遗漏任何文件。一般当你审核完核心代码后，最简单的方式都是按照代码审核工具的排序来顺序查看剩余的文件。有时可以先看测试代码，这样有助于你理解核心代码，这样你能够理解审核的代码想要做什么事情。
下一篇：代码审核要快速