代码审查（Code Review)是软件开发中常用的手段，和QA测试相比，它更容易发现和架构以及时序相关等较难发现的问题，还可以帮助团队成员提高编程技能，统一编程风格等。

1. 代码审查要求团队有良好的文化

团队需要认识到代码审查是为了提高整个团队的能力，而不是针对个体设置的检查“关卡”。

“A的代码有个bug被B发现，所以A能力不行，B能力更好”，这一类的陷阱很容易被扩散从而影响团队内部的协作，因此需要避免。

另外，代码审查本身可以提高开发者的能力，让其从自身犯过的错误中学习，从他人的思路中学习。如果开发者对这个流程有抵触或者反感，这个目的就达不到。

2. 谨慎的使用审查中问题的发现率作为考评标准

在代码审查中如果发现问题，对于问题的发现者来说这是好事，应该予以鼓励。但对于被发现者，我们不主张使用这个方式予以惩罚。软件开发中bug在所难免，过度苛求本身有悖常理。更糟的是，如果造成参与者怕承担责任，不愿意在审查中指出问题，代码审查就没有任何的价值和意义。

3. 控制每次审查的代码数量

根据smartbear在思科所作的调查，每次审查200行-400行的代码效果最好。每次试图审查的代码过多，发现问题的能力就会下降，具体的比例关系如下图所示：

我们在实践中发现，随着开发平台和开发语言的不同，最优的代码审查量有所不同。但是限制每次审查的数量确实非常必要，因为这个过程是高强度的脑力密集型活动。时间一长，代码在审查者眼里只是字母，无任何逻辑联系，自然不会有太多的产出。

4. 带着问题去进行审查

我们在每次代码审查中，要求审查者利用自身的经验先思考可能会碰到的问题，然后通过审查工作验证这些问题是否已经解决。一个窍门是，从用户可见的功能出发，假设一个比较复杂的使用场景，在代码阅读中验证这个使用场景是否能够正确工作。

使用这个技巧，可以让审查者有代入感，真正的沉浸入代码中，提高效率。大家都知道看武侠小说不容易瞌睡，而看专业书容易瞌睡，原因就是武侠小说更容易产生代入感。

有的研究建议每次树立目标，控制单位时间内审核的代码数量。这个方法在我们的实践中显得很机械和流程化，不如上面的方法效果好。

5. 所有的问题和修改，必须由原作者进行确认

如果在审查中发现问题，务必由原作者进行确认。

这样做有两个目的：

(1)确认问题确实存在，保证问题被解决

(2)让原作者了解问题和不足，帮助其成长

有些时候为了追求效率，有经验的审查者更倾向于直接修改代码乃至重构所有代码，但这样不利于提高团队效率，并且会增加因为重构引入新bug的几率，通常情况下我们不予鼓励。

6.利用代码审查激活个体“能动性"

即使项目进度比较紧张，无法完全的进行代码审查，至少也要进行部分代码的审查，此时随即抽取一些关键部分是个不错的办法。

背后的逻辑是，软件开发是非常有创造性的工作，开发者都有强烈的自我驱动性和自我实现的要求。让开发者知道他写的任何代码都可能被其他人阅读和审察，可以促使开发者集中注意力，尤其是避免将质量糟糕，乃至有低级错误的代码提交给同伴审查。开源软件也很好的利用了这种心态来提高代码质量。

7.在非正式，轻松的环境下进行代码审查

如前所述，代码审查是一个脑力密集型的工作。参与者需要在比较轻松的环境下进行该工作。因此，我们认为像某些实践中建议的那样，以会议的形式进行代码审查效果并不好，不仅因为长时间的会议容易让效率低下，更因为会议上可能出现的争议和思考不利于进行如此复杂的工作。

8.提交代码前自我审查，添加对代码的说明

所有团队成员在提交代码给其他成员审查前，必须先进行一次审查。这次自我修正形式的审查除了检查代码的正确性以外，还可以完成如下的工作：

(1)对代码添加注释，说明本次修改背后的原因，方便其他人进行审查。

(2)修正编码风格，尤其是一些关键数据结构和方法的命名，提高代码的可读性。

(3)从全局审视设计，是否完整的考虑了所有情景。在实现之前做的设计如果存在考虑不周的情况，这个阶段可以很好的进行补救。

我们在实践中发现，即使只有原作者进行代码审查，仍然可以很好的提高代码质量。

9.实现中记录笔记可以很好的提高问题发现率

成员在编码的时候应做随手记录，包括在代码中用注释的方式表示，或者记录简单的个人文档，这样做有几个好处：

(1)避免遗漏。在编码时将考虑到的任何问题都记录下来，在审查阶段再次检查这些问题都确认解决。

(2)根据研究，每个人都习惯犯一些重复性的错误。这类问题在编码是记录下来，可以在审查的时候用作检查的依据。

(3)在反复记录笔记并在审查中发现类似的问题后，该类问题出现率会显著下降

10. 使用好的工具进行轻量级的代码审查

“工欲善其事，必先利其器”。我们使用的是bitbucket提供的代码托管服务。

每个团队成员独立开发功能，然后利用Pull Request的形式将代码提交给审查者。复审者可以很方便在网页上阅读代码，添加评论等，然后原作者会自动收到邮件提醒，对审阅的意见进行讨论。

即使团队成员分布在天南海北，利用bitbucket提供的工具也能很好的进行代码审查。

　　当我从学术界转向产业界的过程中，对我生涯改变最大的事情就是发现了代码审核。这是一件在产业开发者的世界中一件非常正常的事情，但是我此前才学术界从来没有听说过哪个学术组织在使用代码审核，在我加入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"进行代码审查

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