我经历过的公司，有如下几种code review方式，其中第一种是我觉得是比较严格的。我们先说第一种。 先看一张图，这个是一个代码「合并请求」。
点我点击确定后，就会来到如下的界面：
这个时候，负责代码审核的人就可以在这个合并请求里，写自己的comment了。比如：
点击立刻发出后，这个comment就变成了一个「待解决」的问题了。如果这个问题不解决，代码是无法合并的。代码提交者必须强制的去解决。
对于非常核心的业务模块，经常是有2个代码审核人的，他们会写大量的comment。代码提交者必须一个一个的解决。
比如上面的代码问题，我重新提交后，审核人觉得没问题，它会手动关闭这个问题的，然后点击审核通过。
下面是我改后的代码，并提交了。
@Slf4j
public class CodeReviewDemo {
public static void main(String[] args) {
log.info("Code Review Demo");
if (args.length > 0)
log.info("Argument 1: " + args[0]);
}
}
这个时候，之前的合并请求会自动更新修改后的代码的。如下：
审核人觉得没问题，就会关闭之前的那个comment的。
这就是我们当时玩的比较正统的代码审核流程了。
但是呢，很多公司并不是这么玩的，多数都是如下几种方式：
- 定一个会议室，然后由代码提交者，直接做代码投屏，讲解代码给审核人听。审核人给出修改意见；
- 也有把合并请求链接发给某个高级开发，让他帮忙看一下，给出意见，提交者去修改；
用会议室那种，其实对代码提交者来说，压力挺大的。经常会出现某些自以为厉害的高手，给出各种高大尚的方案。但是呢，当时的条件下，又无法实施。项目进度又紧张，真搞不了。
因此，我的个人建议是，把技术方案(并不一定写成很完整的技术设计文档的，思路也行的)，跟团队里的leader或者高手，先对一下。
先保证大方向，大家是一致的。这个很关键，既能避免走偏，也能大大加快后续的code review过程。
另外呢，业务核心代码模块，我是建议，的确要审核一下，哪怕是只是改了一行，也是有可能导致大故障的。
剩下的，如果是人本来就靠谱的，不是很核心的，不用代码审核都可以的。
