Gerrit程式碼Review入門

程式碼稽核（Code Review）是軟體研發質量保障機制中非常重要的一環，但在實際專案執行過程中，卻因為種種原因被Delay甚至是忽略。在實踐中，給大家推薦一款免費、開放原始碼的程式碼審查軟體Gerrit。

1. Why Code Review

Code Review是什麼？

Code Review最直觀的解釋即看程式碼。常規的做法為自己看，有時程式碼邏輯問題可能自己看不出來，需要找同事一起看，在大家知識體系相對平均的情況下可能需要花錢專門的公司幫助檢視。

Code Review需要看哪些？對於剛入職場或者剛接觸到Coding的新人來說，程式碼風格是比較重要的一塊。除此之外，編碼規範及程式碼結構寫法，框架和工具的選型，具體專案的業務邏輯，安全隱患，效能問題等都可以通過review的方式發現。Code Review從前往後大致分為結對程式設計，提交程式碼後，測試之前，發版之前，發版之後等幾個階段，越往後，Code Review的效果越差，修復的成本也越來越高。

為什麼一定要做入庫前Code Review？

首先，程式碼審查的最大的功用是純社會性的。如果你在程式設計，而且知道將會有同事檢查你的程式碼，你程式設計態度就完全不一樣了。你寫出的程式碼將更加整潔，有更好的註釋和程式結構。

其次，偷懶是人的天性，從節約成本的角度考慮，大家一般會選擇在測試之前無限制的Delay Code Review。入庫前做Code Review便是成本和效果之間最佳平衡點，它能及時發現問題，進行修改後確保程式碼質量。

最後，程式碼審查能傳播知識。在很多開發團隊裡，經常每個人負責一個核心模組，每個人都只關注自己的模組。除非是同事的模組影響了自己的程式，他們從不相互交流。這種情況的後果是，每個模組只有一個人熟悉裡面的程式碼。如果這個人休假或辭職了，其他人則束手無策。通過程式碼審查，至少會有兩個人熟悉這些程式——作者，以及審查者。審查者並不能像程式的作者一樣對程式十分了解，但至少他會熟悉程式的設計和架構，這是極其重要的。

2. Gerrit簡介

Gerrit是Google為Android系統研發量身定製的一套免費開源的程式碼稽核系統，它在傳統的原始碼管理協作流程中強制性引入程式碼稽核機制，通過人工程式碼稽核和自動化程式碼驗證過程，將不符合要求的程式碼遮蔽在程式碼庫之外，確保核心程式碼多人校驗、多人互備和自動化構建核驗。

Gerrit之前的系統架構：

Gerrit之後的系統架構：

通過Gerrit機制將程式碼做分隔。

Gerrit適用性

幾乎任何需要正式釋出的專案都應當使用Gerrit來進行程式碼審查，如果Team中有新人，必須使用Gerrit確保程式碼質量。

Gerrit效果

整體上來說，個推使用的標準配置為Gerrit+Jenkins+Sonar，整個系統搭建完成後得到的效果為：100% Code Style問題避免入庫，80% 設計問題避免入庫，40% 邏輯錯誤避免入庫，20% 安全隱患避免入庫，100% 人員互備。

3. Gerrit入門實戰

Gerrit部署和執行

JDK環境配置：

java -jar gerrit-2.12.war init -d review_site

Gerrit人員角色配置

使用OpenID登入，第一個登入的使用者為admin，建立dev帳號、review帳號和verify帳號，建立dev、review和verify使用者組並新增相應使用者，注意設定Username，程式碼同步時需要用到。

建立第一個專案，配置許可權管理

新增project，選擇 Inherit From All-Projects，當然也可以自定義Parent Project。

新增Verified標籤支援，這裡修改All-Project 專案的project.config，所有繼承自All-Project的專案自動新增Verified 標籤，也可針對專案自定義是否verify。

建立使用者組：

新增相關使用者許可權：

將程式碼庫同步到本地（SSH/Http）

HTTP 方式：

HTTP Password 密碼在 賬戶 - ->> Settings –>> HTTP Password 處獲取。

SSH方式：

新增SSH Public Key。

Clone程式碼到本地

commit-msg，提供自動寫入change-Id 至git log內功能。

提交第一個change

Gerrit上進行程式碼審查，確認入庫

Verify：

工程裡面接入了jenkins自動verify，結果可在上圖紅框內展示verify結果。

review程式碼，提交入庫。

原生程式碼庫更新，獲取最新入庫程式碼

程式碼submit後通過git pull - - rebase 更新程式碼。

Gerrit入門實戰-初級修補

如果所有程式碼提交均被打回，可以進行暴力回滾：git reset ，接著重新提交Gerrit，再進行Gerrit審查入庫。

Gerrit入門實戰-高階修補

如果單個提交打回，則可互動式回滾：git rebase -i ，修改指定commit點：git commit –amend，完成所有commit點處理：git rebase –continue，然後重新提交Gerrit，最後Gerrit審查入庫。

Rebase前：

Rebase後：

rebase在同一個點上修改，不會產生稽核點，多個commit點同時存在是尤其有用。

Gerrit經驗談

第一，Git別名繫結，新增別名欄位，通過git review master這樣簡單語法提交到master源端分支，可以省去很多工作。修改系統目錄或者專案目下的.gitconfig 檔案，新增

也可通過git config –global alias.review 命令修改：

第二，工具只是一部分，更重要的是人與人當面的溝通交流，大家討論一個好的解決方案，才能更好的解決問題。沒有交流，工具也就失去了意義。

最後，關於review積壓問題，要避擴音交積壓，程式碼稽核過程要及時完成，避免 Code Review流於形式

轉：http://geek.csdn.net/news/detail/85681