表面上看来Code Review会延缓项目的进度，但是在我们2年多的执行过程中，大多数时候没感觉到有延缓。
原因是，虽然代码合并的周期变长了，但是由于代码质量提高了，导致Bug变少了，由于Bug引起的返工问题也变少了，因此整体的进度其实并没有延缓。
我个人认为对一个成熟的团队其实做Code Review反而会加快整体的项目进度，但是手头上没有统计数据支撑我的观点。（对于软件开发的度量，欢迎有心得的同学告知我）

我们每个分支有权限合并的人都不止一个，这样可以保证有人请假不在的时候，代码仍然可以被其他同事审核通过之后合并。

半年前，我们团队加入了很多新成员，刚加入的新同事对规范、项目、产品的熟悉程度都不高，导致了有一段时间，我们遇到了PR审核周期变长的问题。
加上之前遇到的一些问题，我们总结了一个说明，目的是减轻Code Review对开发人员工作的负担，加快PR审核通过的过程。
说明如下： 

Pull Request 的说明 

任务完成才能提交PR。
PR应该在一个工作日内被合并或者被拒绝。
PR在有严重问题（包括但不限于架构问题、安全问题、设计问题），太多问题，或者任务无效的情况下会被拒绝。
严禁一个PR里面有多个任务，除非它们是紧密关联的。
PR提交之后只允许针对Review发现问题再次提交代码，除非有充足的理由，严禁在同一个PR中再次提交其它任务的代码。 

提交PR时候有一个描述框，内容会自动根据Commit的message合并而成。
切记，如果一次提交的内容包含很多Commit，请不要使用自动生成的描述。
请用简短但是足够说明问题的语言（理想是控制在3句话之内）来描述： 

 审核人员邀请原则： 

1. 在创建PR时，Reviewers（审核人）一栏里主要填写“必需审核人”。只有这些人审核都通过，才允许合并。
2. 除了“必需审核人”外，还有一些其它审核人，我们可以在Description里做为“邀请审核嘉宾”@进来。
3. 主干分支间的合并，如Develop => Master，或Master => Develop等，则需要把整个团队（开发+QA）都列为“必需审核人”。 

必须审核人的列表由团队决定，可能包括以下人选： 

 其它审核人，包括但不限于： 

需要知悉此处代码改动的人但又不必非要其审核通过的同事
可以从这个PR中学习的同事 

可以授权指的是，根据约定，Bug修复之类的改动，或者影响较小的改动，前端架构师和后端架构师可以授权团队内的某个资深开发人员，由这个资深开发人员代表他们进行审核。
主干分支之间的合并，大型Feature的合并，前端架构师和后端架构师需要参与。 

上述审核人关注的视角不太一样：
团队Leader关注你是否完成了任务，前后端架构师关注是否符合公司统一的架构、风格、质量，产品架构师从整个产品层面来关注这个PR。
熟悉此问题的同事可以更好的保证问题被解决，确保没有引入新问题。
被影响的同事可以及时了解他受到的影响。 

团队Leader或者产品架构师如果觉得PR邀请的审核者不足或者过多，必须调整为合适的人员，其它同事可以在评论中建议。

我们团队实施Code Review收获不少，总结出来大概有以下几点：

1、短期内迅速提高了代码质量。
     原因有几个，大家知道自己的代码会被人审核之后写得会比较认真。
     理论上代码质量是由整个团队内最优秀的那个人决定的。
     大家也能在Review的过程中学习到其它同事优秀的编码。

2、Bug数量迅速减少。
    但是这个我们没有数据统计比较，比较遗憾。
    我和QA聊过，他给我的数据是在我们的一个新项目每2周一次的大发布，平均只会发现1~2个Bug。
    这点提高了整个团队的幸福感，大家不用经常被火烧眉毛。

3、团队成员对项目的熟悉程度会比较均衡。
    新同事通过参与Code Review能很快熟悉团队的规范。
    代码不会只有个别人了解、熟悉，Bug谁都能改，新功能谁都能做。
    对公司来说避免了人员的风险，对个人来说比较轻松（谁都能来帮你），可以选自己喜欢的任务做。

4、改善团队的氛围
    Review的过程中会需要非常多的沟通，多沟通能拉近团队成员的距离。
    并且无论级别高低，大家的代码都是要经过Review的，可以在团队内营造一个平等的氛围。
    每个成员都可以审查别人的代码，这很容易激发他们的积极性。

亮一下我们的数据: