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

三、收获

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

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

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

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

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

亮一下我们的数据:

我们从2014年1月17日开始第一个PR的提交，到2016年7月5日一共发出了6944个PR，其中6171个通过，739个拒绝。日均11.85个PR，最多的一天提了55个PR。
这些PR一共产生了30040个评论，平均每个PR有4.32个评论，最多的一个PR有239个评论。
参与上述PR评论的同事一共有53位，平均每位同事发出了539个评论，最多的用户发出了5311个评论，最少的发了1个（刚推行Code Review就离职的同事）。
需要说明一下，只有简单的问题会通过评论来提出。比较复杂的，比如涉及到架构、安全等方面的问题，其实都会面对面的沟通，因为这样效率更高。

四、总结

虽然有合适的工具支持会更容易实施Code Review，但它本身并不特别依赖具体的工具，所以前文并没有具体指明我们用了什么工具，除了Git。
原因是基于分支的PR流程依赖于大量创建分支，而Git创建一个分支非常的简单，所以PR模式+Git是一个很好的搭配。
我们在切换到Git之前，也做Code Review，采用的是提交代码以后把commit的Id发给相关同事来审查的流程。
审核通过以后会在缺陷跟踪管理系统里面评论，QA同事没见到审核通过的评论就认为任务没有完成，拒绝进行测试。
虽然没有现在这样直接方便，但是也还是做起来了。

PR审核的过程中，新加入的团队成员常见的问题是不符合代码规范之类的，其实是可以通过源代码检查工具来解决的，这部分我们一直在计划中（( ╯□╰ )），并没有开始实施。

（编辑：江门站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!