如何在團隊中做好Code Review

一、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是可以強制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 綜合對比

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

基于GitLab的CodeReview教程：https://ken.io/note/gitlab-code-review-tutorial

2、制定開發規范

沒有規則，就沒有執行，規則中首當其沖的就是開發規范，

規范中建議包含：

• 工程規范（工程結構，分層方式及命名等等）
• 命名規范（介面、類、方法名、變數名等）
• 代碼格式（括號、空格、換行、縮進等）
• 注釋規范（規定必要的注釋）
• 日志規范（合理的記錄必要的日志）
• 各種推薦與不推薦的代碼示例

如果團隊人數較少，專案的工程復雜度較低，可以自行制定規范，畢竟適合團隊的就是最好的，

如果團隊有一定規模，且還會不斷擴張，還是建議根據大廠的規范進行制定，或者是直接采用，

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

3、制定流程規范

• 確定Code Review實施環節

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

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

• 制定角色行為規范

這樣規范，主要是為了：

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

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

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

3、分享與統計

有了工具、開發規范、流程規范，就可以指引參與的工程師參與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的情況直觀的展示出來，來發現大家執行程序中需要優化的事項， 不斷幫助大家完善規則，做好執行，

三、保證Code Review質量的關鍵

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

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

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

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

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

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

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

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

四、備注

附錄

• Java開發手冊：https://github.com/alibaba/p3c
• 基于GitLab的CodeReview教程：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

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

標籤：其他

上一篇：Git與GitHub 學習筆記

下一篇：Windows下Git的使用