象牙塔里需要追求好的代码质量吗？

这篇文章是我翻译自Matt Welsh的最新博客，My love affair with code reviews，在这篇文章中， Matt主要谈了自己对code review的看法，字里行间，Matt透露出自己对学术界也应该展开code review的期望，这也是我的一个想法， 学术界尽管重要的是publication， 但是追求好的工程能力， 应该是有百利而无一害的。因此我翻译了这篇文章，与诸位分享

我从学术界进入到工业界之后， “发现”了世界上有个东西叫code review，这件事无疑是我生活中最具影响力的事情之一。对于在工业界长期工作的程序员们来说， code review简直是家常便饭， 但是我从没听说过任何一个来自学术界的团队将这个机制引入进来，而我自己在加入google之前也从没有做过这件事。

简而言之， code review机制巨牛逼，每个人都该去做这件事。开个玩笑， 连我的狗也应该去这么做， 你也应该去做。

对于你们这些不在学术界的哥们儿们来说，你们必须理解， 学术界的那帮人真的是些糟透了的程序员(我自己也不例外）。学术界的小伙子们， 总是写着稀稀拉拉的代码，从没有单元测试， 也没有代码风格的统一规范， 没有文档。在这种环境下， 代码往往都是些学生为了去赶某个论文的deadline，没日没夜的堆起来的，这些乱七八糟的代码只有一个最终目的， 就是得到一些看上去很牛逼的图表， 而从不会去考虑是否有人会再次运行这些代码。在我来Google之前，编程之于我， 无非就是所谓科研的副产品，而编程的结果往往让我羞于去给我老妈或是额， 我家的狗狗看。嗯， 当我是一个学术帝的时候， 我确实发布了一些开源软件， 不过每当我想起谷歌， 微软或者facebook的某个程序员可能会去看我的代码时， 我总是不寒而栗（哥， 别去看， 我求你了）

后来我就来谷歌上班了。在这里， 我学到的第一课就是，任何东西只有在被review之后你才可以提交。这一点你需要去慢慢习惯， 在这里甚至是对一个即用即扔的python脚本的修改， 也必须接受检查。当然， 这里大多数review我代码的人都很年轻， 他们甚至都能做我的学生了，所以他们也习惯性的认为我是个编程专家（我得儿意的笑， 我得儿意的笑）。每当一个23岁左右， 刚刚毕业一年的小伙子在你面前展示如何将你写的一个40来行的函数转化成一个优美紧凑的函数， 或者是如何使他更通用， 更具有测试性， 以及添加一些适当的注释时， 这真的是值得你虚心学习的一个经历。

我有一大把推荐code review的理由：

维护标准. 这条理由最为显而易见却又是最重要的理由之一。假设你有一天被卡车撞了（我操， Matt Welsh都这么举例子的）， 100年后因为你的代码突然开始抛异常，一个从没接触过你代码的人凌晨3点gets paged (什么意思？)。所以你的代码不仅要能够正常工作， 而且还需要表达清晰。Code review能够使你写的代码能够与其他人的代码更好的融合， 更符合代码风格规范以及更具有测试性。

在提交之前捕捉到BUG。我已经不记得有多少次在Code review的时候别人指出了我代码中明显的（或者是非常严重的BUG）。多一双（或者多双）时刻关注你代码的眼睛是最好的提早发现错误的方法。

向同事学习。我在code review的过程中学习到的编程技巧比我以前通过读O'Reilly的书或者读别人的代码学到的要多得多。在我的团队中， 有很多人都是代码神牛， 他们提出了各种各样的方法来改进我拙劣的变成技巧。通过从其他的开发者那里得到直接的反馈， 你可以学到更好的设计模式， 更好的测试方法， 更好的算法。

纵览全局. review别人的代码是理解复杂系统开发进程的最好的方法。在你面前有各式各样的代码， 各种各样解决问题的方法， 所以你可以绘制出一种软件行为演进的时间图表，这是一种与阅读最后产品代码完全不同的体验。

我觉得， 学术界的研究团队可以从code review，以及其他相关事务，如好的代码习惯， 代码风格指南， 以及坚持写单元测试中受益良多。当然， 我必须承认， 代码质量对研究者来说不是那么重要，但是这些东西都值得我们花些精力去尝试一下。 

你必须铭记在心的一件事是， code review同时还是一个社交性的活动。在google， 你提交补丁前， 必须从另一位开发者处获得一个LGTM。同时， 要做一次好的code review是一个很耗时间的事情， 所以一个好的经验是， 开发者需要把一些大的改动拆解成更小， 更便于review的小的改动。而且， 在code review之前， 你必须尽你的权力彻头彻尾的去测试你的代码。

code review会拖缓你的进度吗？多少有些吧。不过如果你把软件开发与code review看成一个整体， 你仍然能保持很高的发射率， 尽管就单个的补丁发布而言有些延迟。通常来说， 程序员都能够理解如果在别人code review时太过尖锐会遭报应的，而且他们也能深入理解在进度与质量之间的权衡。我觉得code review有助于构建一个强大的团队， 因为团队中的每个人都有责任去做code review并且保证代码的质量。所以如果能保证code review本身被正确执行，那么他必然值得你去做。

 

OK，Matt。我被说服了， 我如何才能去做code review呢？很高兴你这么问。我们在Google内部使用的code review系统是Guido van Rossum独立开发的,他也发布了和这个系统类似的开源版本，Rietveld. 简单说， 你在AppEngine上安装Rietveld，每个开发者可以用一些简单的Python脚本提交他们的补丁。Review可以在网站上进行， 当review完成后， 程序员就可以提交补丁了。Rietveld不关心你用哪种版本控制系统， 或者你的代码库在什么地方， 他仅仅对补丁进行操作。Rietveld非常简单， 我已经在很多项目中成功使用了他。

另一个流行的方法是使用Github的“pull request”以及评论平台作为code review的机制。每一个程序员都在本地克隆一个主库， 并且向代码库的所有者提交“pull request”.Github有一个非常友善的评论系统， 从而允许程序员使用pull request来进行code review

当有天我和一个在一个著名网站工作的程序员聊天时我被震精了， 他告诉我他们内部从来不使用code review机制，他们的代码时如此的混乱， 并且一些模块的设计师如此的糟糕。我不开玩笑！code review不是唯一的良药， 不过他的确是一个非常有用的工具。