在研发过程中，为了保证代码质量，很多团队都会使用代码评审，或者叫做代码Review。一般情况下，代码Review都会采用集体Review的形式。
集体Review
形式： 一个团队，大家坐在一间会议室里面。一人进行讲解自己的业务和代码实现，团队的其他成员进行Review，提出问题，发现问题和补充不足。
这样可以达到以下的目的：
1.Linus定律 "只要有足够多的眼睛，就可让所有问题浮现"。每个人思考和理解事情的角度不同，这样发现问题也不尽相同，人数越多，发现问题也就越全面。
2.在进行补充和提出建议的过程中，可以达到组内的开发规范和标准的传播，使大家明白统一标准。
3.在讲解的过程中，和大家提出问题，发现问题的过程中，可以达到经验和知识的共享。
缺陷：耗时过长，在开发时间较短的时候，会造成时间压力过大。虽然能减少后期成本，但是对于当时来说，短期的压力。
因为集体Review耗时过长，往往会耽误大家时间，特别是项目时间紧张的时候，项目负责人往往顶不住压力，选择不Review，或者选择自己一个人进行Review，把问题发给大家。
负责人Review
形式：项目负责人进行checkout所有代码，进行逐个Review，把发现的问题email或者当面告知相关人员。
这样可以达到以下的效果：
1.避免员工设计或者代码出现问题。
2.可以达到项目负责人的开发规范和标准的传播，使大家了解其标准。
缺陷：对项目负责人要求较高，并且耗用其精力过多，使其无法处理更多关键的事项。同时因为一个人进行Review，无法对问题进行全面细致的分析，容易遗漏问题。
后来借鉴了结对编程的思想，把结对编程改为了结对Review，取得了一定的效果。
结对Review
形式：项目组成员进行结对，两人一组，互相Review对方的代码。每次进行轮换Review的对象。
这种形式，中和了负责人Review和集体Review的优点，但是同时也中和了上面两个的缺点，达到的是一种均衡。
效果如下：
1）两个人互相Review的时候，可以达到这二人业务和经验交流。
2）Review的过程中可以发现bug，并且在讲的过程中，讲述人也可以发现自身的bug。
3）加快Review进度，相对于集体Review来说，可以大幅提高Review效率，同时保证一定的效果。
4）可以达到组织知识的充分共享，组内的人会和每个人进行结对Review，可以全面传播组内人员的经验和知识。
缺陷：1）如果两人经验都不足的话，技术交流的效果不明显。但可以通过和另外一人的交流时得到补充。所以建议最开始的时候，指定结对Review人员，一名经验丰富者带一名经验较低人员。
2）缺少足够多的眼睛，有些bug会被遗漏。
3）需要Review的双方都要有责任心，如果任何一方不负责的话，都会产生问题遗漏。
上面三种Review各有其优点和缺点，建议项目上根据自己的情况进行选择，或者组合使用。现在建议的方式是每周1~2次结对Review，每2周一次集体Review，研发负责人根据情况进行抽查Review，或者在项目初期和后期进行加强Review。