我所钟爱的代码审查【转】

　　当我从学术界转向产业界的过程中，对我生涯改变最大的事情就是发现了代码审核。这是一件在产业开发者的世界中一件非常正常的事情，但是我此前才学术界从来没有听说过哪个学术组织在使用代码审核，在我加入Google之前我自己也从来没有做过。

　　简而言之，代码审查是一件了不起的事情，每个从业者都应该使用它们，我的狗也真应该去使用它，你们也会使用到；

　　对于不是身在学术研究组织的人们，你必须知道学术界的代码是槽糕的(我自认为我是其中一员)，学术人员写出的代码是粗糙的，没有单元测试，没有代码的模式策略，甚至没有文档。学术界的代码掺杂着毕业生的，面对交稿时间压力的人的，只为了漂亮的图表而不在乎代码是否可以再次运行的人的；在我进入谷歌之前，编程对我而言，是一种必要和有效的研究工具，那结果是我几乎没有任何东西可以让我的母亲骄傲(甚至对我的狗)，噢，当然，我作为学者时也发布了一些开源代码，但现在如果有在谷歌，微软或者Facebook这样公司的人在读我的那些代码的话，我将感到全身颤抖(请别读，我求你们了)。

　　后来我来到了google，在那的第一课：你不要去提交任何代码，直到有人已经审核过它；这需要花一段时间来适应；就算是一段被遗弃的python脚本中无关紧要的4行修改，也是需要审核的；当然，大部分审核我代码人年轻得可以当我的学生，把我当成是一个专家级的程序员(哈！)，一个23岁刚走出校门一年的人，来告诉你怎么把你40行的垃圾代码变成美丽的紧凑的函数，并且把代码变得更加通用，变得可测试，还得为这该死的东西写文档，这是多么羞耻的事情。

　　因此有一堆理由去喜爱代码审核。

　　维护标准，这是显而易见并且事关重大的。你可以想象如果不幸有一天被卡车撞了，那么从现在起的100年，一个没有听说过你代码的人，由于一些模块突然抛出了异常，得到了一份你的代码；因此你的代码不只是需要运行，还需要有可读性，代码审核会强迫你在编写的时候将这两点合二为一，坚持风格的规范，这是可以测试得出的。

　　在提交代码前找出bug，天哪，我都记不清有多少次别人在代码审核的过程中指出了我明显的代码bug，甚至是非常微小的问题，有另外一双眼睛（或者更多双眼睛）看着你的代码，这是找到代码瑕疵的最佳方法。

　　从你的同行中学习，我从代码审查中学到的编程技术和技巧多过我曾经读过的o'reilly的书籍和其他的代码，我团队中有两三个伙伴是friggn的代码忍者，并且提出各种建议来改善我那些使软件变得笨重的理由，我从其他开发者直接反馈中学到了更好的设计模式，更好的测试方法，更好的算法。

　　了解代码的进展，审核其他的人的代码是学习在复杂代码库变迁的中最佳途径，你会接触到一些不同的代码，不同的解决问题的方法，可以图示出一段时间内软件的变迁，这是与读取最终产品非常不同的经验。

　　我想学术研究组织会从代码审核上受益良多，当然随之而来的：良好的代码实践，一致的代码风格，坚持单元测试。我承认代码的质量对研究项目的影响没有那么大，但是它对投资某种形式的使用过程更有价值。

　　需要记住有一个社会要素和代码审核同等重要，在Google,你在被允许提交任何补丁之前需要得到另一个开发者的LGTM(译者注："look good to me")。当然一次优秀的代码审核也是相当耗费时间的，因此需要有一定标准把大的修改变成许多小修改，生成更多友好的代码片段。最好的预期是你在提交给代码审核前，自己已经尽职的完成了测试。

　　代码审查会让你工作更慢吗？多少会有一些影响，但如你把代码工作比喻成一跟管道，当许多代码审核工作在同一时间打成一团时，你可以坚持最高优先级的事情，甚至让许多独立的补丁更延迟些；通常的开发人员都知道你在代码审核中遇到的困扰，在将来的某天都会得到回报，并且他们懂得平衡好效率与质量的需求。我想代码审核可以帮助建立更强大的团队，由于他们都是可靠的代码审核者并且对共享的代码库的质量非常确认。因此如果做的对，那么代码审核就非常值得。

　　“OK,Matt,我相信了。我该如何加入代码审核的行列呢？” 很高兴有人问这个问题，我们在Google内部使用的这个工具的开发者不是别人，正是Guido van Rossum,他大方的发布了一个叫做Rietveld的类似系统，作为开源的代码。基本上，你在AppEngine上安装了Rietveld,每个开发者使用一些python脚本发布补丁，审查者工作也是在站点上，当审查完成后，开发者的提就能够提交他们的补丁。Rietveld系统并不关心你用什么资源控制系统，或者你的代码仓库在哪里，它只处理补丁程序。这真是太聪明了，我使用它完成了两三个成功的项目。

　　另一个流行的方式就是使用GitHub的"pull request"功能和评论平台作为代码审查的机制。独立开发人员克隆一个主代码仓库，然后提交"pull requests"给代码仓库的所有者。Github有很好的评论系统允许人们通过"pull requests"进行代码审查

　　前两天我被难住了，当我遇见一个工程师，他来自一个相当出名的互联网站点，他说他们内部并没有使用代码审核，并且抱怨内部代码多门的混乱和一些功能设计得如何糟糕。说真的，代码审查不是解决不良设计流程的终极方案，但它确实是一个作用惊人的工具。