ReviewBoard代码评审实践总结

代码评审

代码评审（CodeReview），顾名思义是对代码进行评审，是软件工程的活动之一。

经过代码评审能够保证代码质量，促进团队知识共享……好处多多。

版本控制与代码评审

软件工程的各个活动老是离不开工具的支持。

代码评审工具首先必须和版本控制工具相结合的。

如今主流的两种版本控制工具：SVN和GIT。

GIT有个Google开发的代码评审工具Gerrit，能够在提交前进行代码评审，评审经过以后才容许提交到版本库。

其次，代码托管平台GitLab（号称是GitHub的开源实现）也能够用来进行代码评审（把代码fork过去，用pull request的方式实现代码评审）。

若是版本控制工具是GIT，固然优先选择用Gerrit或者GitLab来尝试作代码评审了。

可是若是版本控制工具是SVN呢？这目前尚未发现很好的解决方案。

因此问题来了，在技术选型上，该选择什么工具来进行代码评审呢？

代码评审工具选型

关于代码评审，有不少支持工具，能够查看：  简单实用的Code Review工具

开源的代码评审工具备：  ReviewBoard、  Facebook Phabricator、  Codestriker、  Groogle、  Rietveld、  JCR（Java Code Reviewer）、  Jupiter、  ReviewClipse

商业版的代码评审工具备：  Atlassian Crucible、  Jetbrains Upsource

曾了解过上述大多数工具的使用，曾试过Crucible、Jupiter、ReviewBoard，最终综合考量（如：流行度、易用度、文档完善度）选择了ReviewBoard。

ReviewBoard简介

ReviewBoard是个开源的、可扩展的、友好的基于Web的代码评审工具，是用Python框架Django开发的。

ReviewBoard的官方网站：https://www.reviewboard.org，其title为：  Take the pain out of code review | Review Board

Take the pain out of code review 能够翻译为：从代码评审的痛苦中解脱出来

ReviewBoard的源码托管在GitHub上：  https://github.com/reviewboard/reviewboard

ReviewBoard的源码也是经过ReviewBoard来进行评审的：  https://reviews.reviewboard.org/

ReviewBoard的DEMO：  http://demo.reviewboard.org/，能够经过DEMO简单体验下ReviewBoard的基本使用

ReviewBoard官方指南介绍

要了解ReviewBoard，最好的方式莫过于阅读官方指南：  https://www.reviewboard.org/docs/，ReviewBoard的官方指南有：

User Guide（用户指南）， Administration Guide（管理员指南），Web API Guide（Web API指南），Extending Review Board（扩展ReviewBoard）和 Frequently Asked Questions（常见问答FAQ）。

用户指南的提纲：开始（包括代码评审的介绍、通常工做流、帐户设置）、使用评审请求（评审请求的建立、修改、发布、关闭等）、评审、搜索、使用MarkDown。

管理员指南的提纲：安装、升级、优化、管理员UI、配置、扩展和站点管理。

Web API是RESTful架构，使得ReviewBoard能够用各类编程语言来集成。

ReviewBoard安装及建立站点

ReviewBoard的安装在互联网上有不少博文分享，笔者的建议是  以官方指南为准，同时能够参考互联网上的博文分享

例如，2.0版本在linux下安装指南：  https://www.reviewboard.org/docs/manual/2.0/admin/installation/linux/

在安装完以后，是建立ReviewBoard站点：  https://www.reviewboard.org/docs/manual/2.0/admin/installation/creating-sites/

能够建立多个ReviewBoard站点

笔者安装过程当中曾出现的问题及解决方式以下：

python链接mysql时 出现DeprecationWarning: the sets module is deprecated 警告

SVN出现“error while loading shared libraries”错误

AttributeError: 'module' object has no attribute 'HAVE_DECL_MPZ_POWM_SEC'

Reviewboard时区问题

使用ReviewBoard进行代码评审

代码评审（CodeReview）通常有两种形式：pre-commit-review，post-commit-review。  
pre-commit-review是指代码提交到代码库前进行代码评审；  
post-commit-review是指代码提交到代码库后进行代码评审。

ReviewBoard同时支持以上两种形式，代码的评审主要经过ReviewRequest（评审请求）来进行的。

其中pre-commit-review的工做流为：

• 在代码修改后，提交人建立代码评审请求

• 相应的评审人经过评审请求对代码进行评审，若是评审不经过，提交人能够更新该评审请求

• 评审经过以后，提交人将代码提交至版比库

固然，笔者始终认为代码评审的最好方式是提交前评审，这样可以很好的保证提交到版本库的代码都是通过评审的。

使用ReviewBoard客户端或Eclipse插件

在Web界面建立/更新评审请求的过程是比较繁琐的，好在有相应的工具简化了这个过程：

RBtools是ReviewBoard官方提供的命令行客户端，可使用命令行进行评审请求的相关操做；

eReviewBoard是ReviewBoard的Eclipse插件；

TaoReviewBoard是淘宝开发的ReviewBoard的Eclipse插件。

笔者根据使用经历，整理出以下eReviewBoard和TaoReviewBoard功能对比表格：

功能	Tao-ReviewBoard（开源版）	eReviewBoard
pre-commit-review	√	√
post-commit-review	√	×
版本控制工具	目前只支持SVN	支持SVN、CVS、GIT
建立代码评审请求	√	√
更新代码评审请求	√	√
diff展现（比较编辑器中）	×	√
关闭或从新打开评审请求	×	√
建立或更新评审请求是否方便	能够在多处右击 能够跨Project 能够直接选择文件来建立评审请求       （方便）	只支持在Project上右击 不能跨Project 先列出变动文件再从中选取文件来建立评审请求 （不方便）
安装过程	安装方便 jar包放到plugins/dropins目录便可	基于Mylvy和SCM Eclipse Plugin（Subclipse/Egit/CVS） 安装时若是须要联网下载相关依赖，较耗时 安装参考： eReviewBoard简要介绍及安装

SVN与ReviewBoard集成，实现post-commit-review

曾经尝试过用pre-commit-review进行代码评审，在实施或推广之时，遇到以下问题：

代码提交人在评审请求经过以后还须要再提交代码至版本库，同时没法确保被评审的代码和提交的代码的一致性

没有实如今代码评审请求评审经过后自动提交代码（以提交人的帐号）至版本库（如同Gerrit那样）

总之，尚未相似Gerrit那样的成熟方案

因此，选择了post-commit-review，关于post-commit-review，能够参考以下文档：

svn post-commit脚本样例：  reviewboard源码中用户贡献的样例

rbt post 命令官方指南

svn集成ReviewBoard，让post-commit hook后台运行

最后，欢迎吐槽！