代码审查主要可以划分4种类型。每一种代码审查类型都有它特有的优缺点。
在高层面，代码审查归为两大类：正式的审查，轻量级的审查。以下详细说明：
正式的审查
正式的审查与开发流程绑定作为流程中不可或缺的一部分。实践方式有很多种，其中最流行的实践方式是 范根检查法（Faganinspection）。它为视图寻找代码缺陷提供了一种非常结构化的流程，并且，还可以用于发现规范中的或者设计中的缺陷。
范根检查法步骤
- 计划
- 概述
- 准备
- 召开检查会议
- 重做
- 追查
其基本思想为：预先制定好每一个步骤所需要达到的输出要求。当进行到某个过程时，检查现在的输出，并与之前指定的理想输出要求做比较。然后，由此决定是否进入下一个步骤。或者仍需在当前步骤继续工作。这种结构化的流程比较繁琐，用的不多。成本较高。一般团队很少使用。然而，如果开发的软件生死攸关，会因为有缺陷而让人丧命，那么以这种结构化的方式查找软件缺陷就显得很合理。比如动车调度，飞机自动驾驶等等。
轻量级审查
相比于正式的代码审查，轻量级代码审查正在被更多的开发团队所使用。
其子分类有：
- 瞬时代码审查，也称为结对编程。
一般情况：
当一个开发者在敲代码的同时，另一个开发盯着代码，注意着代码中潜在的问题，并在此过程中给出提升代码质量的建议。解决复杂问题的情况：
此种方法比较适用于，仔细找解决方案的时候两个大脑汇集起来增加成功的概率。让两个头脑思考同一个问题，并且互相讨论可行的方案，这样你更可能覆盖到问题的一些边界情况。在遇到需要很多复杂业务逻辑的任务时候，可以用结对编程。
需要学习新技术时候的情况：
例如：在使用一个新的框架，或者在探索之前没用过的新技术。最好还是单独行动，因为这时可以根据自己的情况作出快速调整。为了弄清楚技术是如何工作的，需要网络上搜索大量资料。或者阅读文档。这时，结对编程帮助就不大，因为不同的人可能获取知识的方式不同。另一方面，当你被问题卡主之后，与同事之间交流一下解决方案，往往会有意想不到的收获。
开发者水平差距问题的影响：
当一个初级开发者和高级开发者进行结对编程，效果并不好。在初级代码开发者负责写代码时，坐在旁边的高级程序员可能因为他写的太慢而感到烦恼。如此设定，这个高级程序员的能力就被限制住了，从而浪费时间。当键盘在高级程序员手上时，又敲得太快，初级程序员跟不上高级程序员的思路。几分钟后，初级程序员就迷失在代码上下文了，或者需要更多的时间解释代码的含义。徒增时间成本。
总结
结对编程适用于两个有相似经验水平的开发者处理复杂的业务问题的情况。
- 同步代码审查，既时代码审查。
运行方式：
一个开发者独自编写代码，当她写完代码后，立即找代码审查者进行审查。审查者来到开发者的桌前，看着同一个屏幕，一起审查、讨论和改进代码。
审查者不清楚这个任务的目标时：
这种代码审查类型会很有效果。它会在这种情况下发生：团队里没有优化会议，或者sprint计划会议，来预先讨论每一项任务。此种做法会导致一种结果：只有特定的开发人员才能知道某项任务的需求。这种情况下，在代码审查之前，向审查者介绍下任务的目标是很有帮助的。
期待大量的代码改进时：如果代码编写者缺乏经验，写出的代码需要很大的改进，那么同步代码审查也很有效。
如果一个经验丰富的高级开发者将要对一个很初级的程序员写出的一段代码进行审查，那么，当初级程序员写完代码后和高级开发者一起改进这块代码，效率是远远高于初级程序员一个人看的。
缺点：它强行切换了审查者的思路，不仅让审查者感到沮丧，也拖慢了整个团队的效率。
- 异步的代码审查，工具支持的代码审查。
运行方式：
开发者在写完代码后，让这些代码对审查者课件，让后开始他的下一个任务。当审查者有时间了，他会在自己的桌子上按自己的时间表进行审查。他不需要和开发者进行沟通，而是通过工具写一些评论。在完成审查后，那些工具会把评论和需要改动的通知给开发者。开发者就会根据评论改进代码，同样的，以自己的时间进行这些事情。这种循环，会以代码改动再次提交到审查者这里又重新开始。开发者修改代码，知道没有评论需要改进。最后改动完成，并且同意，合并到主分支。同步和异步的代码审查有较大的不同。好处：
没有直接的依赖，异步发生。开发者不需要直接依赖于审查者，并且时间安排相对自由。缺点：
可能有许多次循环的审查，可能持续好几天，最终被接受。可能发生的详情如下：当开发者完成代码后，需要几个小时候审查者才开始做代码审查。很多事会后，审查者给出的建议在第二天才能被开发者修复。这样，第一次审查周期就用了一天，如果有多次循环，审查的时间久延续了一整周，还不算代码和测试的时间。解决方案：
在团队里，我们规定，每天上午，每个开发者在开始做其他工作之前，都需要处理挤压的代码审查任务，同样的，在中午午休结束后也类似的工作安排。在较长的休息时间后，开发者已经不出在他的代码思路里了。这时进行代码审查，冰没有强制他们进行不自然的思路切换，并且能够让代码在合适的时间内得到审查。总结：异步的代码审查应该作为每一个专业开发团队的默认选项。但是在为什么这么做之前，要想清楚这些代码审查分类原则。
- 偶尔的代码审查，基于回忆的代码审查。
执行方式：
坐在会议室，一个开发者展示并解释他最近写的一段困难的代码。其他开发者尝试寻找潜在的缺陷，发表评论，给出如何改进代码的建议。
适用场景：
当整个团队都没有代码审查的经验时，把每个人都聚集起来，一起做代码审查，这样弄几次后，可能帮助每个人理解代码审查的目标和意义。长远看来，此种方式并不是一个合适的技术，因为让劝阻审核一段代码是很低效的。
如何选择
- 正式的代码审查，不流行，较难实现较难用于实践。
- 轻量级的代码审查选择
- 瞬时代码审查用于结对编程，在解决复杂业务时候使用。
- 同步代码审查，用于审查者不知道大量改进时。
- 异步审查，避免了强行切换思路带来的问题，对大多数用例都工作的很好。
- 偶尔的代码审查，对于专业团队来说不是长期的选择。
总结
主要用轻量级代码审查。在轻量级代码审查中按照不同情况进行选择审查方式。
- 默认使用异步审查。
- 在开发一个新系统新业务时候，评估业务复杂度如果复杂度高，进行结对编程。