代码评审--流程、工具和最佳实践

为什么执行代码评审

1.      代码评审的最大好处是纯社会性的，当你知道你的每一行代码都有另外一个人看，自然而然会更加卖力的表现，拿出最好的状态编码，因为每个人都有虚荣心嘛；

2.      代码评审可以及时发现一些容易发现的BUG，而不必将发现BUG的时间点推迟到测试阶段；

3.      代码评审可以保证至少有两个人都理解任何一份代码。当出现员工休假，离职等情况的时候，至少保证团队的代码不会陷入无人理解或者无人处理的状况。

 

流程篇

代码评审的流程有以下两种：

1.      提交前评审(pre-push code review)

2.      提交后评审(post-push code review)

 

提交前评审的流程如下：

1.      程序员在试图提交代码变更到代码库之前，先提交变更申请，变更申请包含了这次变更的内容，评审人；

2.      评审人查看变更内容，评估变更，与变更申请人沟通，评估是否通过变更；

3.      如果评审人通过变更，则变更申请人才可以提交代码到代码库；

4.      如果评审人不通过变更，则变更申请人需要根据讨论结果或评审建议做出修改，直到与评审人达成一致，通过评审，才可以提交代码到代码库；

 

提交后评审的流程如下：

1.      程序员提交变更代码到代码库；

2.      评审人审查这次变更的内容，如果评审通过，则标记此次的变更已审查；

3.      如果评审人有疑义，则与变更人沟通，变更人根据讨论结果或评审意见做出修改，知道与评审人达成一致，通过评审。

 

pre-push code review vs post-push codereview

Google，Facebook都严格执行pre-pushcode review。提交前评审对比提交后评审有诸多好处：

1.      程序员会更积极的将变更的代码组织的更好，更模块化，更容易阅读；

2.      评审人有机会在代码提交之前发现问题，或给出更好的建议，对应的程序员对这样的反馈更容易接受；

3.      评审人给出建议或意见之后，相比提交后评审，程序员会更加积极的最反馈做出响应；

4.      评审人会更加认真的对变更进行评审，并且发现问题后会更加积极的参与讨论，对发起变更的程序员提供支持；

5.      在真正提交变更前发现问题并予以解决显然比提交后再进行评审，然后提交修改补丁更好；

 

post-push code review的好处：

1.      普遍认为相比pre-push code review，post-push code review几乎没有任何好处！

2.      但是post-push code review 更加容易实施，过程对现有的组织架构和流程没有完全的颠覆，对团队成员的要求没有那么高；

3.      相比pre-push code review，post-push code review不需要对修改代码&提交变更这个过程中断，不需要等待评审的时间；

4.      可以作为组织向pre-push code review过程实施的过渡训练；

 

 

工具篇

Facebook 的代码评审工具 Phabricator简介

 

使用phabricator的理由，一条就打动我了：phabricator被认为facebook成功的11个重要因素或者工具之一，facebook的工程师对这个工具赞誉有加。

phabricator已经开源，在github可以下载。

phabricator对pre-push code review和 post-push code review 过程都支持，分别是differential和 audit。

不必因为phabricator是facebook的产品，而担心它是重量级的工具。事实上，它完全支持小团队开发，甚至两个人的团队都可以使用进行代码评审。

 

关于Phabricator的安装和配置就不介绍了，参考

http://www.phabricator.com/docs/phabricator/index.html

中间有些配置选项需要注意，尤其在配置arc工具以及配置repository的时候，本地化以及svn的根目录等相关细节。

如果安装配置和使用过程中有问题，欢迎留言或者微博私信讨论。

 

 

最佳实践篇：

Google工程师的重要建议：

（此处参考：http://www.aqee.net/things-everyone-should-do-code-review/）

最重要的一个原则：代码审查用意是在代码提交前找到其中的问题——你要发现是它的正确。在代码审查中最常犯的错误——几乎每个新手都会犯的错误——是，审查者根据自己的编程习惯来评判别人的代码。

 

对于一个问题，通常我们能找出十几种方法去解决。对于一种解决方案，我们能有百万种编码方案来实现它。作为一个审查者，你的任务不是来确保被审查的代码都采用的是你的编码风格——因为它不可能跟你写的一样。作为一段代码的审查者的任务是确保由作者自己写出的代码是正确的。一旦这个原则被打破，你最终将会倍感折磨，深受挫折——这可不是我们想要的结果。

 

ps: 我见过很多程序员都有心理洁癖，总是要求其他人按照标准的格式，标准的思路去设计或者编码，要知道，program是创造性的工作，程序员有独立的个性，思考方法，表现方式都是很正常的。

 

另外在IBM developerworks 上有一篇介绍代码评审的最佳实践的文章写得相当好，参考：

http://www.ibm.com/developerworks/rational/library/11-proven-practices-for-peer-review/

其中大部分最佳实践都可以通过自己实践，慢慢摸索，寻找最适合团队执行的模式和规则。我认为最重要的有两条，一是创造良好的评审氛围。这个与上面提到的代码评审时发现正确而不是发现错误是一样的道理。另外一条是采用轻量级的工具，的确如此，之前经历的团队评审代码基本都没有采用工具，直接查看svn代码log，不仅效率不高，对bug发现率也有很大影响。工具采用要轻量级。

 

SVN Commit 篇

这一篇是笔者这几年经历过项目中存在的问题的思考

1.      Svn 提交的日志要写清楚，尽量准确的描述此次变更的内容，比如：修改了某某某某bug，增加了什么具体功能。很多程序员包括老程序员对svn日志很无所谓，写得log内容诸如“做一些修改”，“update”等毫无意义的log。这样的log不仅对代码评审毫无意义，在修改bug或者版本回滚时更是令人恼火。

2.      Svn 提交的次数和提交的内容控制。有两种情况，一种是无限制的随意提交svn，随意的几行变更就迫不及待的提交；另外一种是好多天都不提交，积累了非常多代码之后，进行一次性更新。很多程序员对提交太随意，最常见的情况是发布版本前，提交未经测试的代码，然后发现问题，不断的提交修改，每一个修改都只有两三行。严重破坏svn版本log的可读性。比较好的做法是，对一个模块，完成修改之后，在本地执行单元测试之后，统一提交，提交的代码不宜太少，也不宜太多。如果提交代码太多，对代码评审和版本回滚造成不便。这种情况，可以考虑细分成一些相关的变更，分多次提交。