一、Code Review的好處

想要做好Code Review，必須讓參與的工程師充分認識到Code Review的好處

1、互相學習，彼此成就

無論是高手雲集的架構師團隊，還是以CURD爲主的業務開發團隊，大家的技術能力、經驗都是有差異的。

通過Code Review，對於同樣的功能實現，有經驗的工程師可以給經驗尚淺的工程師提供合理的優化建議。經驗尚淺的工程師可以通過閱讀優質代碼，快速學習相關技術運用的最佳實踐。如果大家技術實力相當，可能就是互相刷新思想了。

你有一個蘋果，我有一個蘋果，彼此交換一下，我們仍然是各有一個蘋果；但你有一種思想，我有一種思想，彼此交換，我們就都有了兩種思想，甚至更多。

2、知識共享，自動互備

在大部分團隊，尤其是採用服務化架構以及微服務架構的團隊，通常都是1個開發人員負責多個服務/項目（Project），如果沒有Code Review，那麼項目中所涉及的架構知識，或者業務知識，就只存在於項目執行過程中產出的架構文檔，以及核心流程、功能的說明文檔了。

文檔可以幫助其他工程師瞭解服務/項目的情況，但通常其他工程師不會主動去閱讀這些文檔，等到真的要維護別的工程師寫的代碼，文檔的完整性往往沒有最初的效果好了，文檔跟代碼實現的匹配度也會下降。

Code Review的過程，就是根據提交者的描述閱讀代碼的邏輯，看代碼實現是否跟描述一致。在這個時候，Reviewer就必須閱讀文檔，知識的傳播性就更好，也基本上不會出現只有1個人瞭解某個項目的情況了。

3、統一風格，提升質量

如果要給代碼質量分一下等級的話，那應該是：

可以編譯通過->可以正常運行->可以測試通過->容易閱讀->容易維護。那麼，通過Code Review的代碼最起碼可以達到易閱讀這個級別。

要做到易閱讀，可不是說只要有Code Review這個環節就可以了，還要有相關的規範，讓大家按照同樣的工程風格、編碼風格去構建項目和編寫代碼。統一風格一方面是讓大家無論是維護項目還是閱讀代碼，不用互相適應各自的編碼習慣，另外也是給Reviewer一個Code Review的基本依據。

發現Bug不是Code Review的必需品，而是附屬品。至於那些低級的問題/bug交給代碼掃描工具就可以了，這不是Code Review的職責。

二、推動Code Review落地執行

1、選定工具

可以用來做Code Review的工具很多，這裏主要介紹相對主流的Gerrit、GitLab

• Gerrit

Gerrit是Google開源的代碼審查工具，Gerrit也是一個基於Git構建的版本管理工具，Gerrit支持將其他Git倉庫的代碼跟Gerrit自己的倉庫做同步。所有的代碼審查的操作以及權限控制都是在Gerrit自己的倉庫上進行的。

Gerrit是面向代碼審查來構建的，所以在代碼審查的權限控制，以及功能上都是非常完善的。Gerrit是可以強制Code Review的，支持Develop、Reviewer、Approver三種角色支持對每個Project配置不同的Code Review的人員以及權限。

如果要根據Gerrit的數據做一些統計報表，就直接訪問Gerrit的數據庫，如果功能上不滿足要求，反正是開源的，有Java研發團隊就可以自己定製

總之，Gerrit的Code Review功能是非常完善的，缺點可能就是UI、交互太老了以及平臺的管理功能較弱。

• GitLab家族

GitLab是基於Git構建的源代碼管理系統，基於GitLab構建的 GitLab.com 是僅次於 GitHub.com 的在線源代碼管理平臺。

GitLab分GitLab CE（社區版）和 GitLab EE（企業版）兩個版本，開源的社區版功能相對會弱一點，但是免費使用，可以自由部署、定製、維護。企業版功能強大，但是需要收費的。

GitLab可以通過MergeRequest來Review代碼，也可以做到強制CodeReview，社區版支持Develop、Reviewer兩種角色，企業版支持Develop、Reviewer、Approver三種角色，可以給給項目/組分配不同的角色(Master、Developer)來控制Merge代碼的權限。

如果需要根據GitLab的數據做一些統計報表，GitLab提供了非常友好的restful API，如果要定製化，建議是通過API來做定製化的工具，不受編程語言限制。

GitLab的Code Review的功能沒有Gerrit功能完善，但是GitLab附帶的文檔功能、以及GitLab完善的管理後臺都要比Gerrit更好，如果要做CI/CD，GitLab的社區版幾乎是最佳選擇

• Gerrit VS GitLab 綜合對比

工具	權限控制	UI 交互	源碼管理	可維護性	數據 統計	工具 配套
Gerrit	:star::star: :star::star::star:	:star::star:	:star::star::star:	:star::star:	:star::star::star::star:	:star::star:
GitLab 社區版	:star::star::star:	:star::star: :star::star: :star:	:star::star::star::star::star:	:star::star::star::star::star:	:star::star::star::star::star:	:star::star::star::star::star:
GitLab 企業版	:star::star::star::star:	:star::star::star::star::star:	:star::star::star::star::star:	:star::star::star::star::star:	:star::star::star::star::star:	:star::star::star::star:

Gerrit強項只有Code Review的控制，GitLab的功能更全面，但GitLab的企業版是收費的。所以，綜合來說，我更推薦GitLab社區版

基於GitLab的Code Review教程：https://ken.io/note/gitlab-code-review-tutorial

2、制定開發規範

沒有規則，就沒有執行。規則中首當其衝的就是開發規範。規範中建議包含：

• 工程規範（工程結構，分層方式及命名等等）

• 命名規範（接口、類、方法名、變量名等）

• 代碼格式（括號、空格、換行、縮進等）

• 註釋規範（規定必要的註釋）

• 日誌規範（合理的記錄必要的日誌）

• 各種推薦與不推薦的代碼示例

如果團隊人數較少，項目的工程複雜度較低，可以自行制定規範。畢竟適合團隊的就是最好的。如果團隊有一定規模，且還會不斷擴張，還是建議根據大廠的規範進行制定，或者是直接採用。

3、制定流程規範

• 確定Code Review實施環節

Code Review建議是放在代碼提交測試前，也就是開發人員完成代碼開發及自測後將代碼提交到測試分支時進行Code Review。畢竟，如果測試通過後再進行Code Review，如果需要代碼變更，勢必會增加測試的工作量，甚至影響項目進度。亦或是頂着項目上線的壓力，乾脆“以後再說”了

以通用的Git Workflow來說，那就是把Code Review放在Feature分支合併到Develop分支時了。

• 制定角色行爲規範

角色	規則
Developer	1、一次提交的功能必須是完整的 2、 默認細粒度提交（以獨立的方法/功能/模塊爲單位）。如需粗粒度提交，需提前跟Reviewer溝通確認 3、Commit Message中要清晰描述變更的主題 必要時，可以以鏈接或者文件的形式附上需求文檔/設計文檔
Reviewer	1、不允許自我Review並Merge代碼 2、Review不通過打回前需跟Developer說明原因並達成一致 3、Review不通過需明確填寫打回的原因 4、單次Review時長需控制在2分鐘~2小時內完成（特殊情況請說明原因）
Approver	1、審批不通過需註明原因 2、審批時長需要控制在1小時以內 3、對於放行的非質量問題，需持續跟進

這樣規範，主要是爲了：

1. 控制提交Code Review的代碼的粒度

2. 控制單次Code Review的時間

3. 提升Commit/MergeRequest描述的質量，減少溝通成本

這樣，我們就可以通過細粒度高頻次的方式儘可能利用工程師碎片化的時間進行Code Review，一定程度上保證Code Review的效率。

畢竟，粗粒度甚至是集中式的Code Review，時間上難以把控。發現了問題的時候，修復的成本也往往更高。

3、分享與統計

有了工具、開發規範、流程規範，就可以指引參與的工程師參與Code Review，那麼我們也要對Code Review的過程以及結果進行檢驗，畢竟不進行檢查/驗收的規則，是無法達到預期效果的。

Code Review畢竟不是數學題，我們無法通過簡單的計算去驗證。所以我們要通過側面驗證，來幫助Code Review的執行

• 定期分享

我們是期望Code Review可以讓工程師之間互相學習的，那麼對於一次Code Review通常只有參與的2-3個工程師有互相學習的機會，那麼在這個過程中學到的知識，定期的分享出來，既可以加強知識的流動，又可以檢查大家究竟有沒有在Code Review過程中學習到知識，或者有沒有認真的進行Code Review

至於分享的內容，可以是開發規範中的範例代碼，也可以是規範中的正例代碼，也可以是針對某個功能實現的最佳算法/最佳實踐，也可以是Code Review過程中的爭議代碼，也可以是自己踩過的坑。

總之，Code Review之後的代碼分享，不但可以加強知識的流動，還可以檢驗Code Review的效果。

• 數據統計

爲了在一定程度上保證Code Review的效率，我們在規範裏是要求參與的工程師：

1. Developer控制提交Code Review的粒度，或者控制每個Commit的粒度

2. Developer要準確清晰的描述所提交的代碼

3. Reviewer&Approver要在規定時間內完成Code Review

這些情況純粹靠人工是無法檢驗的，還是需要有一定的數據統計。如果用Gerrit，可以查詢Gerrit的數據庫，裏面會有Code Review的信息， 如果用GitLab，可以通過WebHook或者restful API獲取Code Review信息

我們可以做成報表，來展示Code Review的情況：

1. 每人每週Code Review所消耗的時間

2. 每人每週被Code Review所消耗的平均時間

3. 超過規定時間的Code Review情況

4. 代碼提交描述字數過少的情況

5. 等等（根據團隊的需求來）

以上情況只是Code Review的側面反饋，用來幫我們發現Code Review執行過程中可能出現的問題， 不過，出現問題並不意味着Code Review的質量/效率一定受到了影響。

比如，工程師A被Code Review的耗時是團隊內最高，有可能是有某次代碼是週五晚上提交的Code Reviw，這單次Code Review的耗時就會超過48小時。也有可能是對應的Reviewer是團隊新人，要通過相關業務項目瞭解對應Project的承擔的職責及代碼，這是個學習的過程，自然耗時加長。

又比如工程師B提交的代碼描述文字過少，可能就是中間件團隊對某些基礎組件進行升級，或者安全團隊要求升級某個依賴的開源組件，以修復某個安全漏洞。

但是通過這種的數據，可以讓Code Review的情況直觀的展示出來。來發現大家執行過程中需要優化的事項， 不斷幫助大家完善規則，做好執行。

三、保證Code Review質量的關鍵

1、工程師對研發規範的認真學習

無論Code Review的工具以及流程是怎麼樣的，都少不了開發規範作爲支撐，畢竟我們期望Code Review達到的效果之一就是，團隊中的工程師可以寫出像規範中描述那樣的高質量代碼。

工程師對研發規範的掌握程度，決定了自己編寫代碼的質量，也決定了被自己Review通過的代碼的質量。所以，無論如何，加強對研發規範的學習和理解，都是保證Code Review質量的重中之重

2、資深工程師的認真對待

Code Review目的是幫助工程師交流和學習進步的。無論是技術能力還是編碼習慣，亦或是業務知識。無論規則怎麼制定，終究還是需要參與的工程師來執行，如果大家互相睜一隻眼閉一隻眼，互相降低要求，那麼執行的效果一定會打折扣。

雖說三人行必有我師，但收益最大的一定是經驗(技能/業務知識)尚淺的工程師，收益最低的一定是團隊中最資深的工程師。而恰恰經驗尚淺的工程師的收益大部分都要來自資深工程師的付出。

所以，一定要跟資深工程師最好溝通，讓他們嚴格要求，不能對經驗尚淺的工程師放水，以幫助他們提升編碼能力以及業務知識。

這也可以減少甚至避免他們爲經驗尚淺的工程師的代碼“善後”。

四、備註

附錄

• Java開發手冊：https://github.com/alibaba/p3c

• 基於GitLab的Code Review教程：https://ken.io/note/gitlab-code-review-tutorial

• Google代碼風格指南：https://zh-google-styleguide.readthedocs.io

• Jenkins+Sonar執行代碼掃描：https://ken.io/note/jenkins-maven-java-sonar-integration

題圖作者： athree23

授權協議：CC0協議