背景

Code Review 是大家日常開發過程中很常見的流程，當然也不排除一些團隊為了快速上線，只要功能測試沒問題就直接省去了 Code Review。

我個人覺得再忙的團隊 Code Review 還是很有必要的（甚至可以事后再 Review），好處很多：

• ? 跳出個人開發的思維誤區，更容易發現問題
• ? 增進團隊交流，提高整體的技術氛圍
• ? 團隊水平檢測器，不管是審核者還是被審核的，review 幾次后大概就知道是什么水平了

通常 Code Review 有兩種場景，一種是公司內部，還有就是開源社區。

開源社區

先說開源社區，最近也在做 cim^[1] 項目里做 Review，同時也在 Pulsar、OpenTelemetry、StarRocks 這些項目里做過 Reviewer。

以下是一些我參與 Code Review 的一些經驗：

先提 issue

在提交 PR 進行 Code Review 之前最好先提交一個 issue 和社區討論下，你的這個改動社區是否接受。

我見過一些事前沒有提前溝通，然后提交了一個很復雜的 PR，會導致維護者很難 Review，同時也會打擊參與者的積極性。

所以強烈建議一些復雜的修改一定先要提前和社區溝通，除非這是一些十拿九穩的問題。

個人 CI

一些大型項目往往都有完善的 CI 流程來保證代碼質量，通常都有以下的校驗：

• ? 各種測試流程（單元測試、集成測試）
• ? 代碼 Code Style 檢測
• ? 安全、依賴檢測等

如果一個 PR 連 CI 都沒跑過，其實也沒有提前 Review 的必要了，所以在提 PR 之前都建議先在自己的 repo 里將主要的 CI 都跑過再提交 PR。

這個在 Pulsar 的官方貢獻流程^[2]里也有單獨提到。

圖片

同時在 PR 模板^[3]里也有提到，建議先在自己的 fork 的 repo 里完成 CI 之后再提交到 upstream。

圖片

這個其實也很簡單，我們只要給自己的 repo 提交一個 PR，然后在 repo 設置中開啟 Action，之后就會觸發 CI 了。

圖片

如果自己的 PR 還需要頻繁的提交修改，那建議可以先修改為 draft，這樣可以提醒維護者稍后再做 Review。

同時也不建議提交一個過大的 PR，盡量控制在 500 行改動以內，這樣才方便 Review。

Review 代碼

圖片

Github 有提供代碼對比頁面，但也只是簡單的代碼高亮，沒法像 IDE 這樣提供函數跳轉等功能。

圖片

所以對于 Reviewer 來說，最好是在本地 IDE 中添加 PR 的 repo，這樣就可以直接切換到 PR 的分支，然后再本地跟代碼，也更好調試。

有相關的修改建議可以直接在 github 頁面上進行評論，這樣兩者結合起來 Review，效率會更高。

Review 代碼其實不比寫代碼輕松，所以對免費幫你做 Review 的要多保持一些瑞思拜。

AI Review

現在 Github 已經支持 copilot 自動 Review 了，它可以幫我們總結變更，同時對一些參加的錯誤提供修改建議。

圖片

使用它還是可以幫我們省不少事情，推薦開啟。

企業內部

在企業內部做 Code Review 流程上要簡單許多，畢竟溝通成本要低一些，往往都是達成一致之后才會開始開發，所以重點就是 Review 的過程了。

既然是在公司內部，那就要發揮線下溝通的優勢了；當然在開始前還是建議在內部的代碼工具里比如說 gitlab 中提交一個 MR，先讓參會人員都提前看看大概修改了哪些內容，最好是提前在 gitlab 中評論，帶著問題開會討論。

實際 Review 過程應該盡量關注業務邏輯與設計，而不是代碼風格、格式等細枝末節的問題。

提出修改意見的時候也要對事不對人，我見過好幾次在 Review 現場吵起來的場景，就是代入了一些主觀情緒，被 Review 的覺得自己能力被質疑，從而產生了一些沖突。

Code Review 做得好的話整個團隊都會一起進步，對個人來說參與一些優質開源項目的 Code Review 也會學到很多東西。

用鏈接

[1] cim: https://github.com/crossoverJie/cim/pull/170

[2] 官方貢獻流程: https://pulsar.apache.org/contribute/personal-ci/

[3] PR 模板: https://github.com/apache/pulsar/blob/master/.github/PULL_REQUEST_TEMPLATE.md