如何在團隊中做好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 綜合對比
|
工具 |
許可權 控制 |
UI 互動 |
原始碼 管理 |
可維護 |
資料 統計 |
工具 配套 |
|---|---|---|---|---|---|---|
|
Gerrit |
⭐ ⭐ ⭐ ⭐ ⭐ |
⭐ ⭐ |
⭐ ⭐ ⭐ |
⭐ ⭐ |
⭐ ⭐ ⭐ ⭐ |
⭐ ⭐ |
|
GitLab社群版 |
⭐ ⭐ ⭐ |
⭐ ⭐ ⭐ ⭐ ⭐ |
⭐ ⭐ ⭐ ⭐ ⭐ |
⭐ ⭐ ⭐ ⭐ ⭐ |
⭐ ⭐ ⭐ ⭐ ⭐ |
⭐ ⭐ ⭐ ⭐ ⭐ |
|
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實施環節
image
CodeReview建議是放在程式碼提交測試前，也就是開發人員完成程式碼開發及自測後將程式碼提交到測試分支時進行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、對於放行的非質量問題，需持續跟進 |
這樣規範，主要是為了：
- 控制提交Code Review的程式碼的粒度
- 控制單次Code Review的時間
- 提升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的效率，我們在規範裡是要求參與的工程師：
- Developer控制提交Code Review的粒度，或者控制每個Commit的粒度
- Developer要準確清晰的描述所提交的程式碼
- Reviewer&Approver要在規定時間內完成Code Review
這些情況純粹靠人工是無法檢驗的，還是需要有一定的資料統計。
如果用Gerrit，可以查詢Gerrit的資料庫，裡面會有Code Review的資訊，
如果用GitLab，可以通過WebHook或者restful API獲取Code Review資訊
我們可以做成報表，來展示Code Review的情況：
- 每人每週Code Review所消耗的時間
- 每人每週被Code Review所消耗的平均時間
- 超過規定時間的Code Review情況
- 程式碼提交描述字數過少的情況
- 等等（根據自己的需要來）
以上情況只是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-