作為敏捷開發(fā)的一系列重要實踐，單元測試、持續(xù)集成、CodeReview……CodeReview是我們?nèi)粘ｉ_發(fā)中的一個重要環(huán)節(jié)。理想狀況下每次提交會必須先經(jīng)過Review，通過之后才能提交。提交之后系統(tǒng)會自動構(gòu)建并執(zhí)行自動化測試，來保證持續(xù)集成以及版本的穩(wěn)定性。

目前我們在項目中使用P4做為版本管理工具，使用Jenkins進行自動構(gòu)建，使用Reviewboard管理CodeReview。Review使用Pre-commit Review的方式，每次開發(fā)提交必須先自測，然后通過P4插件提交Review Quset，等組員都Review通過之后再進行提交。

為什么要CodeReview

個人感覺Review對一個項目開發(fā)特別是多人的大型項目開發(fā)來說還是必不可少的，雖然很多人會說Review會降低開發(fā)效率。磨刀不誤砍柴工，雖然開發(fā)前期的時間好像變長了也更繁瑣了，但是能讓代碼寫的更扎實以后的問題更少，降低技術(shù)債務(wù)，總體來說還是節(jié)省時間的，并且對整個項目成員的成長也是有極大的好處的。以下總結(jié)了一些CodeReview的好處：

版本的穩(wěn)定性更強。相比直接提交，提交者會更小心，檢查者也會多一層把關(guān)，更容易減少Bug的產(chǎn)生。一個Bug的修復時間是隨著Bug的發(fā)現(xiàn)時間指數(shù)增長的，發(fā)現(xiàn)的越慢需要修復的成本越高，產(chǎn)生的問題約嚴重。

代碼的設(shè)計更好。通過Review開發(fā)者會更了解整個項目，Review的時候各個模塊的同學也勢必會互相討論，這樣一些設(shè)計會更全面兼容性更強，也更不容易出現(xiàn)重復冗余的問題。

代碼質(zhì)量更好。因為需要被Review，代碼通常會寫的更符合代碼規(guī)范，注釋更清晰，變量名函數(shù)名起的更好。

組員的交流更強。因為閱讀他人代碼講解自己的代碼，每個成員都需要溝通和討論。這樣一方面能大幅提升組員的表達總結(jié)能力，另一方面也能提升項目組的氛圍，而不是每天默默開發(fā)相互都不了解。當有任務(wù)變動的時候也更容易交叉替代，讓開發(fā)變的更靈活。

個人能力提升更強。對程序員來說，很大的一個問題就是個人得不到成長，始終做一塊的內(nèi)容，經(jīng)常做重復性勞動。通過Review每個人都可以了解更多的內(nèi)容，能力得到全面提升。資深的能力強的同學可以指導新同學，新同學也可以通過Review資深同學的代碼更好的學習。

如何使用Reviewboard的部署和配置

首先下載并安裝RBTools-1.0.exe和diffutils-2.8.7-1.exe(用來生產(chǎn)Diff文件)。

把diff加到PATH里，一般是這個路徑"C

rogram Files (x86)GnuWin32"，如果報diff找不到需要重啟P4。

更新配置文件，在P4根目錄：
?

添加P4插件：
?

或者在目錄Client/P4Tools目錄下直接導入工具：
?

在P4中創(chuàng)建一條Pending，例如Reviewboard測試，然后在Pending上右鍵選擇我們添加的工具，Reviewboard：
?

如果成功了會有輸出Review request #6 posted的提示。如果文件沒有修改，或者這條Pending已經(jīng)有了會提示相應(yīng)的錯誤信息。如果成功還會輸出兩個路勁，一個是這次review request的地址，一個是diff的地址，例如：
?

這里會出現(xiàn)登陸錯誤的問題，需要關(guān)閉Publicly accessible指定用戶，這里有些奇怪：
?

填寫這條Quest的相關(guān)信息，例如描述，內(nèi)容，以及誰來review這三個地方，誰來review可以選擇某個人也可以選擇一個組，這一步可以在.reviewboardrc文件中設(shè)置成自動設(shè)置，不需要人工設(shè)置，也可以寫腳本控制：
?

當填寫完畢并自測之后就可以點擊Publish發(fā)布，提交之后會自動發(fā)送郵件通知：
?

在主面板就可以看到OUTGOING自己提交但未發(fā)布的，二手游戲賬號出售INCOMING，OPEN別人審核過的，ToMe別人發(fā)布給我審核的：

然后針對diff可以點前面的ID寫備注，對代碼的修改意見。
?

然后ShipIt。如果有修改意見則這條quest不會通過，會自動轉(zhuǎn)給開發(fā)者，并發(fā)送郵件：
?

如果不通過提交方會受到一條不通過的提示，否則可以看到已經(jīng)通過，如果都通過即可提交了。這一步需要自己開發(fā)插件，在提交的時候自動檢查是否通過，只有通過才能上傳：
?

以上就是reviewboard和P4的大致集成流程。不過在實際使用過程中也有一些需要討論的點。首先就是雖然整個流程是大部分是自動的，但是實際在review的時候只靠看diff文件的差異還是很難review出問題的。沒有上下文看的人可能不明白，只能review出一下代碼規(guī)范，保護等錯誤。在這上面我們最終還是靈活一些，對于大功能，新開發(fā)的系統(tǒng)還是當面詳細review，對迭代修復bug的內(nèi)容才會直接通過diff文件review。另外就是如果每次提交都會產(chǎn)生ReviewQuest觸發(fā)郵件通知，并且不通過就不能提交的話，可能會影響進度以及打斷其他人的工作。這點上我們是通過限制Review的成員，增加隨機性即可以保證每個人都能相互review有不會每個人的提交讓所有人都review來解決，另外也可以通過限制提交時間的方式緩解。此外還有其他一些問題，這里就不進行深入討論了。

總結(jié)

以上是生活随笔為你收集整理的如何使用Reviewboard进行代码Review？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。