此博文来自博主毕成功。有问题欢迎进入博主专页进行互动讨论！博文地址：http://passover.blog.51cto.com/2431658/1642176为什么需要代码审查？最近看了一些文章，发现越来越多的团队正在实践敏捷开发的一些概念。提出来的时候太天真了，后来出现了很多体现这个概念的工具。其中，关于“如何提高代码质量”的讨论较多。敏捷开发中也有很多提案。最著名但最不可靠的是结对编程。没有被敏捷洗脑过的人都知道，这基本上是不可能的。实际可操作性，不过，这种做法体现的观点是，多人可以相互监督，把事情做得更好，这根本不是问题。所以另一种方式就是review代码，把两个人同时写代码改成一个人分时写，另一个人看。这个在实际开发中是完全可以实现的，只是留点时间回顾一下。审查团队成员的代码一直都是在不知不觉中进行的。经常看git日志，但是这种方式确实效率低下，也没有严格的规定，所以比较随意。最近偶然看到一个说法，“越厉害的团队，对codereview的态度越严格”，顿时引起了共鸣。心里一直有种感觉，这种查代码的方式不好，但是一直没有发现。妥妥的办法，而且这次又想起codereview感觉是个宝，怎么老是忘记了呢？！如果您对代码审查的好处有疑问，请阅读Phabricator官网的这篇文章。代码审查的方式代码审查的方式主要有两种：1.预推：提交合并后的代码前，先审查，再合并。这是一种非常严格的审查方式，确保每一个发布的代码都经过审查。这种在github上维护的开源项目极其适合，代码的拥有者可以保证代码在自己的控制之下。2.post-push：代码提交后，回顾之前的代码。这是一种很宽松的复习方式，复习的效果肯定会打折扣，但好处是可以忽略一些不必要的复习，节省时间。其实在中国这样工程师文化不多的地方，这种方式在早期实施效果更好。如果在团队中实现代码审查工具，则必须有一个工具。相关工具很多，复习方法也各有侧重。这个工具主要解决了这些问题：1.有一个更直观的查看diff的界面。2.基于工具可以做简单的标记和通知，直接在代码中写标记更利于交流。3.可以知道哪些投稿被谁审过，方便审稿协同。之前在sf写了一个问答供参考。这里还有一些例子供参考。1.Gerrit：Google的产品知名度很高，但是这个产品的设计理念比较陈旧，据说没有维护，所以不推荐。2.GitHubpullrequest：这个当然很好，典型的pre-push方式，但是个人用协作不多，团队用成本高。其实我觉得用bitbucket会更经济实用。3.Phabricator：Facebook内部使用的开源工具。它具有超强的功能，但相对复杂。界面设计很有欧美风，运行速度有点慢。东西还是很给力的，就看你喜不喜欢了。4.gitlab：如果你自己搭建一个git服务器，这是一个不错的选择。相当于自己搭建了一个github，但是配置环境会比较费功夫。5.upsource：JetBrains的产品只有post-push方式，但是安装、界面、使用都还不错。唯一的问题是10人以上要收费，而且也很贵。我们选择哪种方法从中受益取决于团队文化、项目背景和预期结果。最终，我们暂时选择了upsource。目标是首先在团队中实施代码审查。到目前为止它看起来不错。有了工具，大家互相做codereview就方便多了，心理抗拒也没那么强了。其实只要进度不是那么急，研发人员都比较愿意做这种事情。代码中的一些问题在review的过程中也发现了，但是不多。我觉得只要能在bug出现之前解决一些问题，都是很有价值的。
