背景

Code Review 是大家日常開發(fā)過程中很常見的流程，當(dāng)然也不排除一些團(tuán)隊(duì)為了快速上線，只要功能測(cè)試沒問題就直接省去了 Code Review。

我個(gè)人覺得再忙的團(tuán)隊(duì) Code Review 還是很有必要的（甚至可以事后再 Review），好處很多：

• ? 跳出個(gè)人開發(fā)的思維誤區(qū)，更容易發(fā)現(xiàn)問題
• ? 增進(jìn)團(tuán)隊(duì)交流，提高整體的技術(shù)氛圍
• ? 團(tuán)隊(duì)水平檢測(cè)器，不管是審核者還是被審核的，review 幾次后大概就知道是什么水平了

通常 Code Review 有兩種場(chǎng)景，一種是公司內(nèi)部，還有就是開源社區(qū)。

開源社區(qū)

先說開源社區(qū)，最近也在做 cim^[1] 項(xiàng)目里做 Review，同時(shí)也在 Pulsar、OpenTelemetry、StarRocks 這些項(xiàng)目里做過 Reviewer。

以下是一些我參與 Code Review 的一些經(jīng)驗(yàn)：

先提 issue

在提交 PR 進(jìn)行 Code Review 之前最好先提交一個(gè) issue 和社區(qū)討論下，你的這個(gè)改動(dòng)社區(qū)是否接受。

我見過一些事前沒有提前溝通，然后提交了一個(gè)很復(fù)雜的 PR，會(huì)導(dǎo)致維護(hù)者很難 Review，同時(shí)也會(huì)打擊參與者的積極性。

所以強(qiáng)烈建議一些復(fù)雜的修改一定先要提前和社區(qū)溝通，除非這是一些十拿九穩(wěn)的問題。

個(gè)人 CI

一些大型項(xiàng)目往往都有完善的 CI 流程來保證代碼質(zhì)量，通常都有以下的校驗(yàn)：

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

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

這個(gè)在 Pulsar 的官方貢獻(xiàn)流程^[2]里也有單獨(dú)提到。

圖片

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

圖片

這個(gè)其實(shí)也很簡(jiǎn)單，我們只要給自己的 repo 提交一個(gè) PR，然后在 repo 設(shè)置中開啟 Action，之后就會(huì)觸發(fā) CI 了。

圖片

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

同時(shí)也不建議提交一個(gè)過大的 PR，盡量控制在 500 行改動(dòng)以內(nèi)，這樣才方便 Review。

Review 代碼

圖片

Github 有提供代碼對(duì)比頁面，但也只是簡(jiǎn)單的代碼高亮，沒法像 IDE 這樣提供函數(shù)跳轉(zhuǎn)等功能。

圖片

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

有相關(guān)的修改建議可以直接在 github 頁面上進(jìn)行評(píng)論，這樣兩者結(jié)合起來 Review，效率會(huì)更高。

Review 代碼其實(shí)不比寫代碼輕松，所以對(duì)免費(fèi)幫你做 Review 的要多保持一些瑞思拜。

AI Review

現(xiàn)在 Github 已經(jīng)支持 copilot 自動(dòng) Review 了，它可以幫我們總結(jié)變更，同時(shí)對(duì)一些參加的錯(cuò)誤提供修改建議。

圖片

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

企業(yè)內(nèi)部

在企業(yè)內(nèi)部做 Code Review 流程上要簡(jiǎn)單許多，畢竟溝通成本要低一些，往往都是達(dá)成一致之后才會(huì)開始開發(fā)，所以重點(diǎn)就是 Review 的過程了。

既然是在公司內(nèi)部，那就要發(fā)揮線下溝通的優(yōu)勢(shì)了；當(dāng)然在開始前還是建議在內(nèi)部的代碼工具里比如說 gitlab 中提交一個(gè) MR，先讓參會(huì)人員都提前看看大概修改了哪些內(nèi)容，最好是提前在 gitlab 中評(píng)論，帶著問題開會(huì)討論。

實(shí)際 Review 過程應(yīng)該盡量關(guān)注業(yè)務(wù)邏輯與設(shè)計(jì)，而不是代碼風(fēng)格、格式等細(xì)枝末節(jié)的問題。

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

Code Review 做得好的話整個(gè)團(tuán)隊(duì)都會(huì)一起進(jìn)步，對(duì)個(gè)人來說參與一些優(yōu)質(zhì)開源項(xiàng)目的 Code Review 也會(huì)學(xué)到很多東西。

用鏈接

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

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

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