本文翻译自：https://dzone.com/articles/4-types-of-code-reviews-any-professional-developer
转载请注明出处：葡萄城官网，葡萄城为开发者提供专业的开发工具、解决方案和服务，赋能开发者。
没有人能保证他产出的代码一定是完美的。下文阐述了4种主流的代码审查(code review)类型，相信作为专业的开发人员，你应该都了解它们！
每个专业的软件开发者都知道，代码审查是任何正式开发过程中的必要环节。但大多数开发者不知道的是，代码审查分为很多种类型。根据你项目和团队架构的不同，每一种代码审查类型都有它特有的优缺点。
我将在本文列出几种代码的审查的类型，并详细解释它们各自是如何工作的。并且，我也将对你在何时做出哪种选择给出一些建议。
好了，让我们开始吧。
首先，在一个很高的层面，你可以将代码审查归为两大类：正式的代码审查(formal code review)，和轻量级的代码审查(light weight code review)。
正式的代码审查
正式的代码审查是基于正式的开发流程。其中最流行的实践是范根检查法(Fagan inspection)。
它为试图寻找代码的缺陷提供了一种非常结构化的流程，并且，它还可以用于发现规范(specifications)中的或者设计中的缺陷。
范根检查法由6个步骤组成：计划(Planning)，概述(Overview)，准备(Preparation)，召开检查会议(Inspection Meeting)，重做(Rework)，和追查(Follow-up)。基本的思想是：预先制定好每一个步骤所需要达到的输出要求。接下来，当进行到某个过程时，你检查其现在的输出，并与之前制定的理想输出要求做比较。然后，你由此来决定，是否进入下一个步骤，或者仍需在当前步骤继续工作。
这种结构化的流程用的并不多。事实上，在我的职业生涯中，我从没遇到过哪一个团队使用这种方法，而且我也不认为我能在将来看到这种情况。
我认为其原因是，这种流程带来很大的开销，并没有多少团队用到它。
然而，如果你开发的软件生死攸关，会因为有缺陷而让人丧命，那么以这种结构化的方式去查找软件缺陷就显得很合理了。
例如，你是为核电站开发软件。你可能需要一个非常正式的流程去保证最终交出去的代码是没有问题的。
但像我所说，我们大部分开发者所做的软件都不是危及生命的，因此我们使用一种更加轻量的代码审查方法作为正式流程的替代。
所以，让我们来看看这种轻量级的方法。
轻量级的代码审查
如今，轻量级的代码审查在开发团队中很常用。
你可以将轻量级的代码审查细分为不同的子类：
- 瞬时的代码审查，也称为结对编程(pair programming)；
- 同步的代码审查，也称为即时(over-the-shoulder)代码审查；
- 异步的代码审查，也称为有工具支持的(tool-assisted)代码审查；
- 偶尔的代码审查，也称为基于会议的(meeting-based)的代码审查。
类型1：瞬时的代码审查
第一种类型是瞬时代码审查，它发生在结对编程的情景中。当一个开发者在敲键盘写代码的同时，另一个开发者盯着代码，注意着代码中潜在的问题，并在此过程中给出提升代码质量的建议。
复杂的业务问题
当你需要解决一个复杂问题时，这种代码审查的方法很适用。在仔细寻找解决方案的过程中，把两个人的脑力聚集起来，会增加成功的几率。让两个头脑思考同一个问题，并相互讨论可行的方案，这样你会更可能覆盖到问题的一些边界情况。
在遇到需要很多复杂业务逻辑的任务时，我喜欢使用结对编程。这样，有助于两个人彻底理清流程中的所有不同的可能性，保证所有情况都在代码中得到了适当的处理。
与复杂的业务逻辑不同，有时，你也会需要去解决一个复杂的技术问题。例如，你在使用一个新的框架，或者在探索之前你没用过的一些新技术。在那种情况下，最好还是单独行动，因为你可以根据自己的情况作出快速调整。为了弄清新技术是如何工作的，你需要上网搜索大量资料，或者阅读文档。
这时，结对编程的帮助就不大了，因为你们会成为各自获取这些知识的阻碍。
然而，当你被问题卡住之后，与你的同事交流一下解决方案，往往会帮你获得看问题的不同视角。
相同的专业水平
考虑进行结对编程的另一个重要方面，是一起工作时，两个开发者的专业水平。两个开发者最好是处于同一水平，因为这样他们才能以相同的速度一起工作。
让一个初级开发者和一个高级开发者进行结对编程，效果并不好。在初级开发者负责写代码的时候，坐在旁边的高级程序员可能会因为他写得太慢了而感到烦恼。如此设定，这个高级程序员的能力就被限制住了，从而浪费了时间。
而当键盘在高级程序员手上时，他又敲得太快，初级程序员跟不上高级程序员的思路。几分钟后，初级程序员就迷失在代码上下文里了。
只有当高级程序员慢下来，向初级程序员解释清楚他的做法，这种设定才合理。然而，这就不是我们所说的结对编程了，而是一种学习的环节，其中高级程序员在教初级程序员如何解决特定问题。
但是，如果两个开发者都在同一水平，在这种设定下，他们所能取得的进展是令人惊讶的。其中有一个很大的好处是，两个开发者能相互激励，当其中一位失去注意力时，另一位开发者能把他拉回正轨。
总结一下：结对编程适用于两个有相似经验水平的开发者处理复杂的业务问题的情况。
类型2：同步的代码审查
第二种类型是同步的代码审查。这种是，一个开发者独自编写代码，当她写完代码后，立即找代码审查者进行审查。
审查者来到开发者的桌前，看着同一块屏幕，一起审查、讨论和改进代码。
审查者不清楚代码的目标
当审查者不清楚这个任务的目标时，这种代码审查类型会很有效果。它会在这种情况下发生：团队里没有优化会议(refinement sessions)，或者sprint计划会议(sprint planning sessions)，来预先讨论每一项任务。
此做法通常会导致一个结果：只有特定的开发人员才知道某项任务的需求。
这样的情况下，在代码审查之前，向审查者介绍一下任务的目标是很有帮助的。
期待大量的代码改进
如果代码编写者缺乏经验，写出的代码需要很大的改进，那么同步代码审查也会很有效。
如果一个经验丰富的高级开发者将要对一个很初级的程序员写出的一段代码进行审查，那么，当初级程序员写完代码后就和高级开发者一起改进这段代码，效率是远远高于初级程序员自己一个人看的。
强行切换思路的缺点
但是同步审查有一大缺点，就是它强行切换了审查者的思路。它不仅让审查者感到沮丧，也拖慢了整个团队的效率。
类型3：异步代码审查
然后我们有了第三种类型，异步代码审查。这一类型的审查不是在同一时间、同一块屏幕上完成的，而是异步的。开发者在写完代码后，让这些代码对审查者可见，然后开始她的下一个任务。
当审查者有时间了，他会在自己的桌子上按自己的时间表进行代码审查。他而不需要当面和开发者沟通，而是用工具写一些评论。在完成审查后，那些工具会把评论和需要的改动通知给开发者。开发者就会根据评论改进代码，同样的，是以自己的时间表来做这些事情。
这个循环，会以代码改动再次被提交到审查者这里而又重新开始。开发者修改代码，直到没有评论说需要改进。最后，改动得到同意，并提交到主分支(master branch)。
你可以看到，同步的代码审查和异步的代码审查相比有很大的不同。
没有直接的依赖
异步代码审查的一大好处， 就是它是异步发生的。开发者不需要直接依赖于审查者，并且他们都可以按自己的时间表去做各自的工作。
多次审查循环的缺点
这里的缺点就是，你可能会有许多次循环的审查，它们可能会持续好几天，直到最终被接受。
当开发者完成代码后，通常需要几个小时，审查者才开始做代码审查。很多时候，审查者给出的建议只有在第二天才能被开发者修复。
这样，第一次审查周期就至少用掉了一天。如果你又多次这样的循环，审查的时间就延续至一整周了——这还不算写代码和测试的时间。
但这里有一些做法，可以避免这样的长时间间隔导致的失控。例如，在我的团队里，我们规定，每天上午，每个开发者在开始做其他工作之前，都要先处理积压的代码审查任务。同样的，在中午午休结束后也需要这样做。
因为在较长的休息时间后，开发者已经不处在他的代码思路中了。这时进行代码审查，你并没有强制它们进行不自然的思路切换，并且能够让代码在合适的时间得到审查。
对比这种代码审查类型的优缺点，我认为，异步的代码审查应该作为每一个专业开发团队的默认选项。
但在我告诉你为什么我是这么想的之前，让我看看第四种代码审查类型。
类型4：偶尔的代码审查
很久以前，我曾经每个月会和整个团队开一次代码审查会议。我们坐在会议室，一个开发者展示并解释着他最近写的一段困难的代码。
其他开发者尝试寻找着潜在的缺陷，发表评论，给出如何改进代码的建议。
我不认为任何团队和长期地使用偶尔代码审查的方式。我只想到这个类型适用于的一种情况：当整个团队都没有代码审查的经验时，让把每个人聚起来，一起做代码审查，这样弄几次之后，可能会帮助每个人理解代码审查的目标和意义。
然而，从长远来看，这第四种类型并不是一个合适的技术，因为让全组成员审查一段代码是很低效率的做法。
我应该选择哪种代码审查类型呢？
好了，现在你可能会想，该选哪种类型。
我们讨论了正式的类型，它显然不太流行，并且较难用于实践。
然后，我们讨论了轻量级的代码审查这一大类，然后是其中著名的4个子类型。
类型1，瞬时的代码审查，用于结对编程。当两个开发者有相似的技术组合，并且处理一些复杂的业务问题时，这种方式工作得很好。
类型2，同步的代码审查，用于审查者不清楚任务的目标时，需要开发者向其进行解释的这种情况。当开发者经验不足，写出的代码需要大量改进时，这种代码审查模式也工作得很好。
但是它的缺点是需要强行切换思路，会让审查者沮丧，以及拖慢团队开发速度。
类型3，异步的代码审查，避免了强行切换思路带来的问题，对大多数用例都工作得很好。
类型4，偶尔的代码审查，对于专业团队来说不是一个长期的选择。可以只在团队刚刚开始代码审查时被使用。
使用异步代码审查作为默认选择
我认为，专业的团队应该把异步的代码审查作为默认的选择。因为它避免了同步代码审查的缺陷。
当审查者不能理解开发者做出一项代码修改的原因时，可以使用同步的代码审查。但在那种情况下，审查者将会去询问开发者，以获得额外的信息和说明。如果你在一个团队中工作，这样的情况应该很少发生。
如果你不在一个真正的团队中，而是和一群人一起工作，那么同步的代码审查就有意义了。如果审查者对你过去这几天的工作内容毫不知情，那么在开始一起做代码审查之前，向审查者给出一个合适的说明是很合理的。
如果你有两个开发者，他们具备相似的技能组合，并且在攻克一个复杂的业务问题，那么也有理由切换到结对编程的模式。但是，一个团队往往由许多经验水平不同的成员组成，并且不会一直都在处理复杂的业务问题。大多数时间，你手上是复杂度在平均水平的常规任务。
因此，专业团队的最佳选择是：使用异步的代码审查作为默认选择，然后当需要时切换到同步的代码审查或者结对编程。
好了，这就是今天的内容。
你的团队使用什么代码审查的类型呢？你知道其他的、我这里漏掉的代码审查类型吗？请在评论里让我知道吧。
下次再聊。保重。