为什么需要代码审查
最近看了一些文章，发现敏捷开发的一些理念越来越多的团队在实践，也觉得敏捷不再像最早提出的时候那么虚，有很多体现这个理念的工具涌现。其中，“如何提高代码质量”的讨论一直很多，敏捷开发中也有好多种提案，最广为人知、但也最不靠谱的应该就是结对编程了，只要没被敏捷洗脑的人都清楚知道这个基本没有实际可操作性，然而这个做法的出发点——多个人互相监督可以把事情做的更好，这反而是完全认同的。所以还有一种方式就是代码审查（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之前能解决掉一些问题，就已经有很大价值了。
本文转自passover 51CTO博客，原文链接：http://blog.51cto.com/passover/1642176，如需转载请自行联系原作者
