代碼審核（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 <commit>，接着重新提交Gerrit，再進行Gerrit審查入庫。
Gerrit入門實戰-高級修補
如果單個提交打回，則可交互式回滾：git rebase -i <commit>，修改指定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流於形式。
從個推實際使用效果看，Gerrit在核心代碼質量控制、知識傳承、團隊培養等方面都具備很高的實用價值，推薦給廣大開發團隊用。