软件自动化部署和测试，必须执行代码审查制度

没有程序，任何产品、任何项目的程序代码，可以在没有经过有效的代码审查前提交到代码库里的，这是我们常常做的事情。代码审查用意是在代码提交前找到其中的问题――你要发现是它的正确。在代码审查中最常犯的错误――几乎每个新手都会犯的错误――是，审查者根据自己的编程习惯来评判别人的代码。代码审查不是可有可无的。不论你采用什么形式的测试过程，什么形式的部署过程，没有代码审查――game over。为什么？因为代码的质量是一种人能看懂的质量。不管你如何测试，有如何严谨的部署流程，只有当另外一个人看了这些代码，并且表明能看懂时，这些代码才有意义。如果看不懂，你认为这样的代码――虽然测试通过、部署符合流程――可以上线吗？没有经过代码审查，测试说明不了任何问题。测试通过但没有经过代码审查的代码仍然是有bug的。

什么是代码审查？

请参考谷歌是如何做代码审查的。设计中使用的“走廊UX测试”是说：在开始实现你的设计前，至少需要有一个人看过你的设计。代码审查是相同的道理。代码审查是说：在把你的代码合并到代码库里之前，请至少找一个人看看你的代码。

代码审查的作用

1.属于纯社会***的。如果你在编程，而且知道将会有同事检查你的代码，你编程态度就完全不一样了。你写出的代码将更加整洁，有更好的注释，更好的程序结构――因为你知道，那个你很在意的人将会查看你的程序。没有代码审查，你知道人们最终还是会看你的程序。但这种事情不是立即发生的事，它不会给你带来同等的紧迫感，它不会给你相同的个人评判的那种感受。2.代码审查能传播知识。在很多的开发团队里，经常每一个人负责一个核心模块，每个人都只关注他自己的那个模块。除非是同事的模块影响了自己的程序，他们从不相互交流。这种情况的后果是，每个模块只有一个人熟悉里面的代码。如果这个人休假或――但愿不是――辞职了，其他人则束手无策。通过代码审查，至少会有两个人熟悉这些程序――作者，以及审查者。审查者并不能像程序的作者一样对程序十分了解――但他会熟悉程序的设计和架构，这是极其重要的。

如何进行代码审查？

对于一个问题，通常我们能找出十几种方法去解决。对于一种解决方案，我们能有百万种编码方案来实现它。作为一个审查者，你的任务不是来确保被审查的代码都采用的是你的编码风格――因为它不可能跟你写的一样。作为一段代码的审查者的任务是确保由作者自己写出的代码是正确的。一旦这个原则被打破，你最终将会倍感折磨，深受挫折――这可不是我们想要的结果。问题在于，这种错误是如此的普遍而易犯。如果你是个程序员，当你遇到一个问题，你能想到一种解决方案――你就把你想到的方案作为标准答案。但事情不是这样的――作为一个好的审查者，你需要明白这个道理。代码审查的第二个易犯的毛病是，人们觉得有压力，感觉非要说点什么才好。你知道作者用了大量的时间和精力来实现这些程序――不该说点什么吗？不，你不需要。只说一句“哇，不错呀”，任何时候都不会不合适。如果你总是力图找出一点什么东西来批评，你这样做的结果只会损害自己的威望。当你不厌其烦的找出一些东西来，只是为了说些什么，被审查人就会知道，你说这些话只是为了填补寂静。你的评论将不再被人重视。第三是速度。你不能匆匆忙忙的进行一次代码审查――但你也要能迅速的完成。你的同伴在等你。如果你和你的同事并不想花太多时间进行代码复查，你们很快的完成，那被审查者会觉得很沮丧，这种代码审查带来的只有失望的感觉。就好象是打搅了大家，使大家放下手头的工作来进行审查。事情不该是这样。你并不需要推掉手头上的任何事情来做代码审查。但如果中途耽误了几个小时，你中间还要休息一会，喝杯茶，冲个澡，或谈会儿闲话。当你回到审查现场，你可以继续下去，把事情做完。如果你真是这样，我想没有人愿意在那干等着你。

下面是代码审查基本的步骤：把身体向左转。

看到另外一个程序员？拍拍他的肩膀。

让他看你的显示器。

说：这代码你能看懂吗？我打算把它提交到代码库里。

听他的建议。

自己做决定：是应该修改一下，还是继续提交到代码库里。

就这样。现在，我想告诉你，有大量的代码审查工具可以使用（https://en.wikipedia.org/wiki/List_of_tools_for_code_review）。它们都能高度的自定义配置。它们的作用都是让你代码审查过程更方面、灵活。

简单的几款代码审查工具

下面是我推荐的几款简单的代码审查工具(如果你的公司的程序员少于5千人)。less（https://gist.github.com/textarcana/4611277）

diff, 或 wdiff（http://en.wikipedia.org/wiki/Diff http://www.gnu.org/software/wdiff/ ）

GitHub pull requests（https://github.com/blog/1124-how-we-use-pull-requests-to-build-github）

就是这些。虽然还有很多很多的代码审查工具，我很少听说哪个程序员说喜欢它们的。而我的观点，less, diff, github pull requests能解决我们正常开发中的大部分代码审查问题。如果你的代码审查过程过于复杂，需要使用大量的工具，这说明你过分的依赖于一些不必要的形式，你应该简化它们。你可以说成你的反对的观点，或在微博上和我们讨论。 【转至外刊IT评论】