如何在團隊中作好Code Review

1、Code Review的好處

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

一、互相學習，彼此成就

不管是高手雲集的架構師團隊，仍是以CURD爲主的業務開發團隊，你們的技術能力、經驗都是有差別的。

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

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

二、知識共享，自動互備

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

文檔能夠幫助其餘工程師瞭解服務/項目的狀況，但一般其餘工程師不會主動去閱讀這些文檔，等到真的要維護別的工程師寫的代碼，文檔的完整性每每沒有最初的效果好了，文檔跟代碼實現的匹配度也會降低。

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

三、統一風格，提高質量

若是要給代碼質量分一下等級的話，那應該是：
能夠編譯經過->能夠正常運行->能夠測試經過->容易閱讀->容易維護。那麼，經過Code Review的代碼最起碼能夠達到易閱讀這個級別。

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

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

2、推進Code Review落地執行

一、選定工具

能夠用來作Code Review的工具不少，這裏主要介紹相對主流的Gerrit、GitLab

• Gerrit

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

Gerrit是面向代碼審查來構建的，因此在代碼審查的權限控制，以及功能上都是很是完善的。
Gerrit是能夠強制CodeReview的，支持Develop、Reviewer、Approver三種角色支持對每一個Project配置不一樣的CodeReview的人員以及權限。

若是要根據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	⭐ ⭐ ⭐ ⭐ ⭐	⭐ ⭐	⭐ ⭐ ⭐	⭐ ⭐	⭐ ⭐ ⭐ ⭐	⭐ ⭐
GitLab社區版	⭐ ⭐ ⭐	⭐ ⭐ ⭐ ⭐ ⭐	⭐ ⭐ ⭐ ⭐ ⭐	⭐ ⭐ ⭐ ⭐ ⭐	⭐ ⭐ ⭐ ⭐ ⭐	⭐ ⭐ ⭐ ⭐ ⭐
GitLab企業版	⭐ ⭐ ⭐ ⭐	⭐ ⭐ ⭐ ⭐ ⭐	⭐ ⭐ ⭐ ⭐ ⭐	⭐ ⭐ ⭐ ⭐ ⭐	⭐ ⭐ ⭐ ⭐ ⭐	⭐ ⭐ ⭐ ⭐

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

基於GitLab的CodeReview教程： https://ken.io/note/gitlab-co...

二、制定開發規範

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

• 工程規範（工程結構，分層方式及命名等等）
• 命名規範（接口、類、方法名、變量名等）
• 代碼格式（括號、空格、換行、縮進等）
• 註釋規範（規定必要的註釋）
• 日誌規範（合理的記錄必要的日誌）
• 各類推薦與不推薦的代碼示例

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

Java開發手冊： https://github.com/alibaba/p3c
Google代碼風格指南： https://zh-google-styleguide.... （涵蓋：C++、Python等）

三、制定流程規範

• 肯定Code Review實施環節

CodeReview建議是放在代碼提交測試前，也就是開發人員完成代碼開發及自測後將代碼提交到測試分支時進行Code Review。畢竟，若是測試經過後再進行Code Review，若是須要代碼變動，勢必會增長測試的工做量，甚至影響項目進度。亦或是頂着項目上線的壓力，乾脆「之後再說」了

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

• 制定角色行爲規範

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

這樣規範，主要是爲了：

1. 控制提交Code Review的代碼的粒度
2. 控制單次Code Review的時間
3. 提高Commit/MergeRequest描述的質量，減小溝通成本

這樣，咱們就能夠經過細粒度高頻次的方式儘量利用工程師碎片化的時間進行Code Review，必定程度上保證Code Review的效率。

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

四、分享與統計

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

Code Review畢竟不是數學題，咱們沒法經過簡單的計算去驗證。因此咱們要經過側面驗證，來幫助Code Review的執行

• 按期分享

咱們是指望CodeReview可讓工程師之間互相學習的，那麼對於一次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的耗時是團隊內最高，有多是有某次代碼是週五晚上提交的CodeReviw，這單次CodeReview的耗時就會超過48小時。也有多是對應的Reviewer是團隊新人，要經過相關業務項目瞭解對應Project的承擔的職責及代碼，這是個學習的過程，天然耗時加長。

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

可是經過這種的數據，可讓Code Review的狀況直觀的展現出來。來發現你們執行過程當中須要優化的事項， 不斷幫助你們完善規則，作好執行。

3、保證Code Review質量的關鍵

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

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

工程師對研發規範的掌握程度，決定了本身編碼代碼的質量，也決定了本身Review經過的代碼的質量。因此，不管如何，增強對研發規範的學習和理解，都是保證Code Review質量的重中之重

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

Code Review目的是幫助工程師交流和學習進步的。不管是技術能力仍是編碼習慣，亦或是業務知識。不管規則怎麼制定，終究仍是須要參與的工程師來執行，若是你們互相睜一隻眼閉一隻眼，互相下降要求，那麼執行的效果必定會打折扣。

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

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

這也能夠減小甚至避免他們爲經驗尚淺的工程師的代碼「善後」。

4、備註

附錄

• Java開發手冊：https://github.com/alibaba/p3c
• 基於GitLab的CodeReview教程：https://ken.io/note/gitlab-co...
• Google代碼風格指南：https://zh-google-styleguide....
• Jenkins+Sonar執行代碼掃描：https://ken.io/note/jenkins-m...

---

本文首發於個人我的博客：https://ken.io/note/how-to-do-code-review-in-a-team