我所钟爱的代码审查

译者 logix

One of the most life-altering events in my move from academia to industry was the discovery of code reviews. This is pretty standard fare for developers in the "real world", but I have never heard of an academic research group using them, and had never done code reviews myself before joining Google.

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

In short: Code reviews are awesome. Everyone should use them. Heck, my dog should use them. You should too.

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

For those of you not in the academic research community, you have to understand that academics are terrible programmers. (I count myself among this group.) Academics write sloppy code, with no unit tests, no style guidelines, and no documentation. Code is slapped together by grad students, generally under pressure of a paper deadline, mainly to get some graphs to look pretty without regard for whether anyone is ever going to run the code ever again. Before I came to Google, that was what "programming" meant to me: kind of a necessary side effect of doing research, but the result was hardly anything I would be proud to show my mother. (Or my dog, for that matter.) Oh, sure, I released some open source code as an academic, but now I shudder to think of anyone at a place like Google or Microsoft or Facebook actuallyreading that code (please don't, I'm begging you).

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

Then I came to Google. Lesson #1: You don't check anything in until it has been reviewed by someone else. This took some getting used to. Even an innocent four-line change to some "throw away" Python script is subject to scrutiny. And of course, most of the people reviewing my code were young enough to be my students -- having considered myself to be an "expert programmer" (ha!), it is a humbling experience for a 23-year-old one year out of college to show you how to take your 40 lines of crap and turn them into one beautiful, tight function -- and how to generalize it and make it testable and document the damn thing for chrissakes.

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

So there's a bunch of reasons to love code reviews:

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

Maintain standards. This is pretty obvious but matters tremendously. The way I think of it, imagine you get hit by a truck one day, and 100 years from now somebody who has never heard of your code gets paged at 3 a.m. because something you wrote was suddenly raising exceptions. Not only does your code have to work, but it also needs to make sense. Code reviews force you to write code that fits together, that adheres to the style guide, that is testable.

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

Catch bugs before you check in. God, I can't count the number of times someone has pointed out an obvious (or extremely subtle) bug in my code during the code review process. Having another pair of eyes (or often several pairs of eyes) looking at your code is the best way to catch flaws early.

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

Learn from your peers. I have learned more programming techniques and tricks from doing code reviews than I ever did reading O'Reilly books or even other people's code. A couple of guys on my team are friggin' coding ninjas and suggest all kinds of ways of improving my clunky excuse for software. You learn better design patterns, better approaches for testing, better algorithms by getting direct feedback on your code from other developers.

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

Stay on top of what's going on. Doing code reviews for other people is the best way to understand what's happening in complex codebase. You get exposed to a lot of different code, different approaches for solving problems, and can chart the evolution of the software over time -- a very different experience than just reading the final product.

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

I think academic research groups would gain a lot by using code reviews, and of course the things that go with them: good coding practices, a consistent style guide, insistence on unit tests. I'll admit that code quality matters less in a research setting, but it is probably worth the investment to use some kind of process.

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

The thing to keep in mind is that there is a social aspect to code reviews as well. At Google, you need an LGTM from another developer before you're allowed to submit a patch. It also takes a lot of time to do a good code review, so it's standard practice to break large changes into smaller, more review-friendly pieces. And of course the expectation is you've done your due diligence by testing your code thoroughly before sending it for review.

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

Don't code reviews slow you down? Somewhat. But if you think of code development as a pipeline, with multiple code reviews in the flight at a time you can still sustain a high issue rate, even if each individual patch has higher latency. Generally developers all understand that being a hardass on you during the review process will come back to bite them some day -- and they understand the tradeoff between the need to move quickly and the need to do things right. I think code reviews can also serve to build stronger teams, since everyone is responsible for doing reviews and ensuring the quality of the shared codebase. So if done right, it's worth it.

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

Okay, Matt. I'm convinced. How can I too join the code review bandwagon? Glad you asked. The tool we use internally at Google was developed by none other than Guido van Rossum, who has graciously released a similar system called Rietveld as open source. Basically, you install Rietveld on AppEngine, and each developer uses a little Python script to upload patches for review. Reviews are done on the website, and when the review is complete, the developer can submit the patch. Rietveld doesn't care which source control system you use, or where the repository is located -- it just deals with patches. It's pretty slick and I've used it for a couple of projects with success.

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

Another popular approach is to use GitHub's "pull request" and commenting platform as a code review mechanism. Individual developers clone a master repository, and submit pull requests to the owner of that repository for inclusion. GitHub has a nice commenting system allowing for code reviews to be used with pull requests.

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

I was floored the other day when I met an engineer from a fairly well-known Internet site who said they didn't use code reviews internally -- and complained about how messy the code was and how poorly designed some pieces were. No kidding! Code reviews aren't the ultimate solution to a broken design process, but they are an incredibly useful tool.

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