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後臺運行

最後，歡迎吐槽！