为什么需要代码审查

    最近看了一些文章,发现敏捷开发的一些理念越来越多的团队在实践,也觉得敏捷不再像最早提出的时候那么虚,有很多体现这个理念的工具涌现。其中,“如何提高代码质量”的讨论一直很多,敏捷开发中也有好多种提案,最广为人知、但也最不靠谱的应该就是结对编程了,只要没被敏捷洗脑的人都清楚知道这个基本没有实际可操作性,然而这个做法的出发点——多个人互相监督可以把事情做的更好,这反而是完全认同的。所以还有一种方式就是代码审查(Code Review)了,把两人同时写代码改成在不同的时间上一个人写、另外一个人看。这个实际开发中是完全可以做到的,只是要留有审查的时间即可。

    复查团队成员的代码自己一直也是无意识的在做,经常去看git log,但是这个方式效率真的很低,也没有严格的规定,所以做的也比较随意。恰巧最近看到一个论调,“越牛逼的团队,对于代码审查的态度越严谨”,顿时引发共鸣,长久以来在心里一直有一种这样去检查代码的方式是不行的感觉,但是一直也没找到合适的方式,而这次再联想到代码审查感觉茅塞顿开,怎么一直都把它给忘了呢?!

    如果你对代码审查能带来什么好处有疑问的话,我觉得Phabricator官网的这篇文章解释的面面俱到,我也不想再费时费力去翻译了,看原文吧。


代码审查的方式

    代码审查主要有两种方式:

    1. pre-push:在提交合并代码之前,先进行审查,通过和才能合并。这是一种非常严格的审查方式,可以确保每个发布的代码都是已经被审查过的。这种放到在github上维护的开源项目极其合适,代码的所有者可以确保代码是在自己的控制范围。

    2. post-push:代码提交后,再审查之前的代码。这是非常宽松的审查方式,审查的效果肯定是打折扣的,但是好处是可以忽略一些不必要的审查以节约时间。其实在国内这种没有太多工程师文化的地方,这种方式是比较好在早期推行的。

    这两种方式也就对应这两种完全不同的审查时间节点。pre-push需要尽快审查,应该每周定时,甚至只要提交合并就要安排审查;post-push可以更加灵活,在一个功能模块完成就可以发起审查了,在版本发布之前必须审查结束。这个需要每个团队制定符合自己情况的方案,落实好即可。


代码审查的工具

    这个事情在团队中实行的话,是一定需要有个工具的,相关的工具有很多,审查方式也各有偏重。这里工具主要是解决了这几个问题:

    1. 有一个更为直观的界面查看diff。

    2. 可以基于工具进行简单的标记和通知,直接把标记写在代码里更利于沟通。

    3. 可以知道哪些提交时已经被谁审查过了,方便审查的协作。


    之前在sf写过一篇问答可以参考。这里再例举一些,供参考选择。

    1. Gerrit:google的产品,名气很大,但是这个东西设计理念比较陈旧,据说也没有什么维护了,不推荐。

    2. github pull request:这个当然很好,典型的pre-push方式,但是个人用也没太多协同的事情,团队用又觉得贵。其实感觉用bitbucket会经济实用些。

    3. phabricator:facebook内部使用并开源出来的工具,功能超级强大,但相对的就是非常复杂,界面设计非常欧美的风格,运行速度也有点慢。东西还是很牛逼的,看你是不是喜欢了。

    4. gitlab:如果是自己搭建的git server,这个是不错的选择,相当于自己弄了个github,就是配置环境会比较多工作量。

    5. upsource:JetBrains的产品,只有post-push的方式,但是从安装、界面、到使用都是挺不错的,唯一问题就是10个人以上要收费,而且还很贵。


我们从中的获益

    选用哪种方式,我觉得因团队文化、项目背景、效果预期而定,我们最后暂时选用的是upsource,目标是先在团队中把代码审查施行起来。   

    目前来看效果还可以。有了工具之后大家互相做代码审查也方便很多,心理抗拒性也没那么强。其实只要进度不那么催,研发人员还是比较愿意去做这种事情的。审查过程中目前发现了一些代码中的问题,但是现在还不多,我想只要能在出现bug之前能解决掉一些问题,就已经有很大价值了。