CodeReview（代码审查）

这周在公司一直给同事做CodeReview，感觉还是比较痛苦的，因为一些机制并不是很人性化，至少说，流程上有一些不成熟的环节。和大家一起分享，希望有经验的朋友给我一下批评建议。

代码审查（Code review）是指对计算机源代码系统化地审查，常用软件同行评审的方式进行，其目的是在找出及修正在软件开发初期未发现的错误，提升软件质量...

 

方案1：Review Meeting，即Online Review。
基本不可行。很大程度上依赖于主持者的素质，而且如果主持者不积极，就会流于形式。此外时间成本过高，为reviewer+owner的时间总和。倒是可以将其改造为Team内部新技术新观点的交流Meeting，完全头脑风暴式的那种。

方案2：Offline Review
我特别想说的就是这种。包括重构、代码逻辑、代码规范。

对于变更的代码，owner应该提供一份ChangeList，基于需求或者功能点，列举出增删改动了那些类和方法以及关键变量，这就迫使owner首先review一下自己的代码，从而首先自身发现一些问题。对于代码重构，更需要这份清单，甚至是一个变更前后的类之间的关系图（当然可以从之前的LLD中复制过来）。额外的一个好处就是，重构会把很多方法原封不动的从一个类迁移到另一个辅助类，那么，reviewer就不用去care这些代码，而只是关心整体的结构，从而对症下药，对架构而不是代码，提出新的见解。

Code-review并不应该局限于纸面上，仅仅依赖于一个DB是不够的。一定要进行face to face的沟通或者by phone。由reviewer来讲解自己的心得，可以不受owner的主观意向影响，从其他角度来思考这个问题，还有就是迅速掌握代码，可以在owner离开的情况下迅速接手这段code；由owner来讲解，可以在介绍过程中，及时发现一些无法自圆其说的地方，然后加以修正。因此code-review从准备到完成的时间，应该大致为coding的50％左右。

最后，非常不赞同连错别字都写进code-review报告的行为。一方面要肯定reviewer的勤恳，但是，另一方面，这些与code无关的suggestion，会转移我们的视线。我们究竟要关注什么？是代码质量，是架构设计，而不是单词拼写错误。过多此类的suggestion，会把真正的问题掩藏起来，即使有critical等级的区别，也无济于事。一种极端的解决方式是禁止提这样的suggestion，比较缓和的方式是私下交流这些小错误。
额外需要指出的是，对代码规范的审核，尽量不要依赖人力，而是通过先进的工具来处理。人，总是要做一些机器做不了的事情，比如说重构与算法的review。这样，我们就可以有更多的时间focus在这些高层次的地方了。

补充：版本变更的代码比较（我们公司使用的是ClearCase）
如果类中原先有两个方法A和B，A在B的前面。版本变更后将A方法挪到了B方法的后面，那么ClearCase会只认为B方法是不变的，而认为新版本在B方法前删除了A方法，而在B方法后又添加了这个A方法——这就由ClearCase的逐行比较算法导致的，它毕竟只是一个文件控制工具，而不是for code file的；但是对于人而言，其实是没有改变的。这就对Code-Review添加了困扰，如果代码文件2万行，将一个方法从头位置挪到了尾部，这无疑就给reviewer造成了麻烦。

解决方案：如果ClearCase比较不同版本的代码文件的算法，能够细化为先list出一个类所有的成员（使用反射），按字母顺序排列，那么比对两个版本的类文件时，就可以按照成员的顺讯，先比较成员是否有所增删改变，再深入到方法属性中，用ClearCase原先的算法，逐行比较代码变更。
此外，还要注意嵌套类，因此要使用迭代来实现以上新算法。还有就是partial分散类的问题，这应该在代码规范中，禁止使用这种类的实现（自动生成的winform窗体除外）。

 

 

 

Code Review中文应该译作“代码审查”或是“代码评审”，这是一个流程，当开发人员写好代码后，需要让别人来review一下他的代码，这是一种有效发现BUG的方法。由此，我们可以审查代码的风格、逻辑、思路……，找出问题，以及改进代码。因为这是代码刚刚出炉的时候，所以，这也是代码重构，代码调整，代码修改的最佳时候。所以，Code Review是编码实现中最最重要的一个环节。

长时间以来，Code Review需要有一些有效的工具来支持，这样我们就可以更容易，更有效率地来进行代码审查工作。下面是5个开源的代码审查工具，他们可以帮助你更容易地进行这项活动。

1. Review board:
Review board 是一个 基于web 的工具，主要设计给 django 和python的用户。 Review board 可以帮助我们追踪待决代码的改动，并可以让Code-Review更为容易和简练。尽管Review board 最初被设计在VMware项目中使用，但现在其足够地通用。当前，其支持这些代码版本管理软件： SVN, CVS, Perforce, Git, Bazaar, 和Mercurial.

 

Yahoo 是review-board的其中一个用户。

“Review board 已经改变了代码评审的方式，其可以强迫高质量的代码标准和风格，并可以成为程序员编程的指导者。每一次，当你访问search.yahoo.com 时，其代码都是使用 Review board工具Review过的。 We’re great fans of your work!” – Yahoo! Web Search

2. Codestriker:
Codestriker 也是一个基于Web的应用，其主要使用 GCI-Perl 脚本支持在线的代码审查。Codestriker 可以集成于CVS, Subversion, ClearCase, Perforce 和Visual SourceSafe。并有一些插件可以提供支持其它的源码管理工具。

David Sitsky 是 Codestriker 的作者，并也是最活跃的开发人员之一。 Jason Remillard 是另一个活路的开发者，并给这个项目提供了最深远最有意义的贡献。大量的程序员贡献他们的代码给 Codestriker 项目，导致了这个项目空前的繁荣。

 

 

3. Groogle:
Groogle 是一个基于WEB的代码评审工具。 Groogle 支持和 Subversion 集成。它主要提供如下的功能：

<!--[if !supportLists]-->· <!--[endif]-->各式各样语言的语法高亮。

<!--[if !supportLists]-->· <!--[endif]-->支持整个版本树的比较。

<!--[if !supportLists]-->· <!--[endif]-->支持当个文件不同版本的diff功能，并有一个图形的版本树。

<!--[if !supportLists]-->· <!--[endif]-->邮件通知所有的Reivew的人当前的状态。

<!--[if !supportLists]-->· <!--[endif]-->认证机制。

 

 

4. Rietveld:
Rietveld 由Guido van Rossum 开发（他是Python的创造者，现在是Google的员工），这个工具是基于Mondrian 工具，作者一开始是为了Google 开发的，并且，它在很多方面和Review board 很像。它也是一个基于Web的应用，并可以Google App Engine 当主机。它使用了目前最流行的Web开发框架 django 并支持Subversion 。当前，任何一个使用 Google Code 的项目都可以使用 Rietveld 并且使用 python Subversion 服务器。当然，它同样支持其它的Subversion服务器。

  

5. JCR
JCR 或者叫做 JCodeReview 也是一个基于WEB界面的最初设计给Reivew Java 语言的一个工具。当然，现在，它可以被用于其它的非Java的代码。

JCR 主要想协助：

<!--[if !supportLists]-->· <!--[endif]-->审查者。所有的代码更改都会被高亮，以及大多数语言的语法高亮。Code extracts 可以显示代码评审意见。如果你正在Review Java的代码，你可以点击代码中的类名来查看相关的类的声明。

<!--[if !supportLists]-->· <!--[endif]-->项目所有者。可以 轻松创建并配置需要Review的项目，并不需要集成任何的软件配置管理系统（SCM）。

<!--[if !supportLists]-->· <!--[endif]-->流程信仰者。 所有的评语都会被记录在数据库中，并且会有状态报告，以及各种各样的统计。

<!--[if !supportLists]-->· <!--[endif]-->架构师和开发者。 这个系统也可以让我们查看属于单个文件的评语，这样有利于我们重构代码。

JCR 主要面对的是大型的项目，或是非常正式的代码评审，从这方面看来，他并不像上面的那些工具。

 

Jupiter：最后我们要提一下Jupiter，这是另一个代码review的工具你可以去考虑使用的，它是一个Eclipse IDE 的插件。