兩個(gè)月前我翻了下團(tuán)隊(duì)在過(guò)去一年的代碼審查記錄看到一個(gè)讓我后背發(fā)涼的事實(shí)全年的 merge request 通過(guò)率 98%平均每條 MR 的評(píng)論數(shù)不到 2 條。這意味著我們掛在嘴邊的嚴(yán)格的 Code Review 流程真實(shí)運(yùn)行下來(lái)的效果幾乎等于零。更扎心的是我在幾個(gè)技術(shù)交流群里問(wèn)了一圈發(fā)現(xiàn)這種現(xiàn)象不是個(gè)別團(tuán)隊(duì)的問(wèn)題而是普遍現(xiàn)象。后來(lái)我花了整整兩個(gè)月從頭梳理審查流程、重構(gòu)工具鏈、調(diào)整團(tuán)隊(duì)協(xié)作方式最后沉淀出這套 open-code-review 的實(shí)踐方案。這里先把概念說(shuō)清楚open-code-review 不是一個(gè)現(xiàn)成的商業(yè)工具而是我在實(shí)際團(tuán)隊(duì)里整理出來(lái)的一套開(kāi)放式代碼審查實(shí)踐方案包含審查規(guī)則、流程設(shè)計(jì)、自動(dòng)化與 AI 輔助配置、以及團(tuán)隊(duì)協(xié)作約定。它核心的主張只有一句話代碼審查的本質(zhì)不是審批門禁而是以代碼為載體的信息同步和知識(shí)傳遞。想清楚這件事整個(gè)流程的搭建邏輯就完全不一樣了。這篇文章不是理論宣講是我把一套從形式化審查變成有效協(xié)作的完整過(guò)程記錄下來(lái)包括踩過(guò)的坑、改過(guò)的方案、以及最終穩(wěn)定運(yùn)行的配置希望對(duì)正在被 Code Review 折磨的團(tuán)隊(duì)有一點(diǎn)參考價(jià)值。1. 傳統(tǒng) Code Review 名存實(shí)亡的根因我們都在審但沒(méi)人真正在讀先別急著談工具和流程我把傳統(tǒng)審查方式失效的原因拆透。因?yàn)橹挥姓业讲≡詈竺孀龅姆桨覆挪粫?huì)又是換湯不換藥。1.1 通過(guò)率接近 100% 的審查流程本質(zhì)上就是零審查我拉了一下團(tuán)隊(duì)過(guò)去一年的數(shù)據(jù)總共合并了 1200 多個(gè) MR被拒絕過(guò)的不到 20 個(gè)而在這 20 個(gè)里大部分是 CI 失敗被系統(tǒng)攔截的不是被評(píng)審人打回的。平均每個(gè) MR 的評(píng)論數(shù)量不到 2 條這 2 條里還有一半是LGTMOK這種沒(méi)有任何信息量的回復(fù)。這種情況出現(xiàn)在大多數(shù)團(tuán)隊(duì)里原因其實(shí)特別簡(jiǎn)單評(píng)審人根本沒(méi)有足夠的時(shí)間去仔細(xì)讀代碼。一個(gè)典型的工作日里一名后端工程師同時(shí)掛著兩三個(gè)開(kāi)發(fā)任務(wù)還要響應(yīng)線上問(wèn)題、參加需求評(píng)審會(huì)留給他看 MR 的時(shí)間可能只有上午半小時(shí)。在這半小時(shí)里他要消化一個(gè)改動(dòng) 800 行的 MR——相當(dāng)于每分鐘要看 27 行代碼并發(fā)現(xiàn)問(wèn)題。你覺(jué)得他能看出什么問(wèn)題來(lái)大部分人的應(yīng)對(duì)策略就是瞄一眼 diff看看有沒(méi)有明顯的低級(jí)錯(cuò)誤然后點(diǎn)通過(guò)。所以我說(shuō)通過(guò)率 100% 的本質(zhì)是零審查不是說(shuō)大家不專業(yè)是流程設(shè)計(jì)有問(wèn)題。我們把一個(gè)需要深度思考的活動(dòng)壓縮到了一個(gè)不合理的時(shí)長(zhǎng)和顆粒度里結(jié)果自然就是走過(guò)場(chǎng)。1.2 門禁思維讓審查變成了對(duì)抗我觀察到一個(gè)更隱蔽的問(wèn)題很多團(tuán)隊(duì)把 Code Review 定位成質(zhì)量門禁通過(guò)才允許合入。這個(gè)定位一旦形成開(kāi)發(fā)和評(píng)審之間的關(guān)系就變成了審查者和被審查者溝通方式也會(huì)跟著變形。開(kāi)發(fā)這邊的心理是別給我挑刺趕緊過(guò)了我好合代碼評(píng)審那邊的心理是我得挑點(diǎn)問(wèn)題出來(lái)不然顯得我沒(méi)看。前一種心態(tài)讓開(kāi)發(fā)者不愿意發(fā)起討論寧可自己默默把代碼改成評(píng)審人可能喜歡的樣子也不愿意把真實(shí)的設(shè)計(jì)權(quán)衡講出來(lái)后一種心態(tài)讓評(píng)審人為了找問(wèn)題而找問(wèn)題于是評(píng)論的方向從怎么讓代碼更好變成了你這里不對(duì)。對(duì)抗關(guān)系的直接后果就是有價(jià)值的討論根本不會(huì)發(fā)生。我在一些知名開(kāi)源項(xiàng)目里看過(guò)非常高質(zhì)量的評(píng)審討論比如某些框架的 PR 里作者和維護(hù)者對(duì)一行代碼能來(lái)回討論幾十條評(píng)論每次討論都能把方案的邊界、權(quán)衡、演進(jìn)方向聊透。這種討論之所以會(huì)發(fā)生是因?yàn)殡p方都沒(méi)有把對(duì)方當(dāng)敵人而是當(dāng)成一個(gè)共同把代碼做對(duì)的協(xié)作者。開(kāi)源社區(qū)天然具備這種開(kāi)放討論的氛圍而大多數(shù)公司的內(nèi)部審查流程反而不具備。1.3 信息同步才是審查真正該做的事后來(lái)我開(kāi)始琢磨一個(gè)本質(zhì)問(wèn)題Code Review 到底在解決什么問(wèn)題表面上看是發(fā)現(xiàn) bug、把關(guān)質(zhì)量但往深了說(shuō)是信息同步。改動(dòng)代碼的人腦子里裝著完整的上下文為什么這么改、為什么不那么改、這個(gè)方案和哪個(gè)歷史約束沖突過(guò)、哪里有坑。評(píng)審人如果不了解這些上下文就只能看表面反過(guò)來(lái)評(píng)審人的價(jià)值在于他提供了開(kāi)發(fā)者的盲區(qū)——那個(gè)你沒(méi)注意到的邊界條件、那條被你忽略的既有約定。舉個(gè)例子我見(jiàn)過(guò)一個(gè) MR開(kāi)發(fā)把一段查詢邏輯從同步改成了異步單看代碼沒(méi)有任何問(wèn)題但評(píng)審人知道調(diào)用鏈上游有一個(gè)超時(shí)時(shí)間很短的網(wǎng)關(guān)異步化之后數(shù)據(jù)返回來(lái)的時(shí)候連接早斷了。這種知識(shí)只有人知道機(jī)器查不出來(lái)如果評(píng)審只是一句沒(méi)問(wèn)題這個(gè) bug 上線后大概率要讓運(yùn)維背鍋。開(kāi)放式審查要做的就是把這個(gè)信息同步的過(guò)程從給結(jié)論變成聊上下文。結(jié)論是單向的、一次性的上下文是雙向的、可沉淀的。這也是后面所有設(shè)計(jì)的最底層邏輯讓審查變成討論而不是審判。2. 開(kāi)放式審查的核心設(shè)計(jì)讓代碼討論像開(kāi)源社區(qū)一樣發(fā)生對(duì) open-code-review 的整體理念有了概念之后下面聊聊我在實(shí)際操作中怎么把這個(gè)理念落到每天的工作流里。2.1 行內(nèi)評(píng)論把批評(píng)落到具體代碼行而不是籠統(tǒng)的感受第一個(gè)改變是從評(píng)論形式入手的。傳統(tǒng)審查里大家喜歡在 MR 底部寫(xiě)總結(jié)性意見(jiàn)比如這次改動(dòng)整體設(shè)計(jì)不太合理邏輯有些復(fù)雜建議調(diào)整。這種意見(jiàn)最大的問(wèn)題是評(píng)審人自己其實(shí)沒(méi)想清楚哪里不合理就拋了個(gè)模糊的感受過(guò)去開(kāi)發(fā)收到反饋后還得猜一來(lái)一回溝通成本極高。有時(shí)候開(kāi)發(fā)猜錯(cuò)了方向改了一遍之后評(píng)審人又說(shuō)不是這個(gè)意思這種內(nèi)耗最消磨人的耐心。我后來(lái)強(qiáng)制團(tuán)隊(duì)改用行內(nèi)評(píng)論所有意見(jiàn)必須掛到具體的代碼行上。這個(gè)規(guī)則像是一個(gè)強(qiáng)制思考的裝置當(dāng)你想說(shuō)這里設(shè)計(jì)不合理的時(shí)候你得先找到具體哪一行讓你產(chǎn)生了這種感覺(jué)。找到之后你往往會(huì)發(fā)現(xiàn)自己的真實(shí)意見(jiàn)其實(shí)是這里把狀態(tài)判斷和數(shù)據(jù)更新耦合在一起了后續(xù)加需求時(shí)容易漏改這樣一說(shuō)反饋就有了可落地性。行內(nèi)評(píng)論還有一層好處它天然形成了一條討論線其他評(píng)審人可以看到完整上下文不會(huì)出現(xiàn)兩個(gè)評(píng)審人針對(duì)同一個(gè)地方給出兩條互相矛盾的意見(jiàn)。這在多人協(xié)作的團(tuán)隊(duì)里非常關(guān)鍵不然開(kāi)發(fā)端同時(shí)收到這里應(yīng)該拆開(kāi)和這里應(yīng)該合并兩個(gè)意見(jiàn)的時(shí)候心態(tài)很容易崩。2.2 提問(wèn)式溝通一個(gè)改寫(xiě)話術(shù)就能改變協(xié)作氛圍第二個(gè)改變是話術(shù)。我在團(tuán)隊(duì)里搞過(guò)一次特別小的實(shí)驗(yàn)要求所有人在給評(píng)審意見(jiàn)時(shí)不允許直接下結(jié)論必須用提問(wèn)的方式表達(dá)。比如把你這里寫(xiě)錯(cuò)了改成這里的狀態(tài)流轉(zhuǎn)我有點(diǎn)沒(méi)看明白可以解釋一下嗎把你這個(gè)設(shè)計(jì)有問(wèn)題改成為什么不用現(xiàn)有的 xx 方法是我漏了什么約束嗎。實(shí)驗(yàn)效果出乎意料的好。原因是提問(wèn)式表達(dá)天然帶有開(kāi)放性開(kāi)發(fā)收到問(wèn)題后的第一反應(yīng)是解釋而不是防御。被質(zhì)疑和被請(qǐng)教之間有一個(gè)重要的心理差異前者會(huì)讓人先進(jìn)入防御狀態(tài)再考慮問(wèn)題本身后者會(huì)讓人先思考問(wèn)題再組織回答。很多原本可能引發(fā)爭(zhēng)論的意見(jiàn)用提問(wèn)方式說(shuō)出來(lái)就變成了一次方案探討。執(zhí)行的過(guò)程中我建議不要做得太機(jī)械不是禁止一切確認(rèn)式表達(dá)而是提醒大家注意比例。如果一個(gè) MR 里全是命令式的改為 xx溝通氛圍很快就冷下去了如果至少一半的評(píng)論是提問(wèn)式的整個(gè)討論就活了。2.3 異步節(jié)奏把催命式 改成留足思考時(shí)間的異步協(xié)作做 Code Review 的時(shí)機(jī)也很重要。很多團(tuán)隊(duì)的習(xí)慣是MR 提出來(lái)之后馬上在群里 評(píng)審人然后每隔一小時(shí)問(wèn)一次看了沒(méi)。這種催命式協(xié)作看似高效實(shí)際上逼著評(píng)審人在沒(méi)有完整上下文的狀態(tài)下倉(cāng)促答復(fù)質(zhì)量能高才怪。真正的深度閱讀需要一個(gè)不被打斷的時(shí)間塊如果評(píng)審人腦子里還掛著別的事情不要說(shuō)邏輯漏洞了有時(shí)候連明顯的命名問(wèn)題都會(huì)被跳過(guò)。我給團(tuán)隊(duì)定的規(guī)則是MR 提出后設(shè)置默認(rèn) 4 小時(shí)響應(yīng)期評(píng)審人在這個(gè)窗口內(nèi)可以隨時(shí)接收但不要求立即響應(yīng)開(kāi)發(fā)在 4 小時(shí)內(nèi)沒(méi)收到反饋可以主動(dòng)提醒一次而不是每半小時(shí)催一次。這個(gè)節(jié)奏讓評(píng)審人能安排出整塊的時(shí)間來(lái)認(rèn)真讀代碼也讓開(kāi)發(fā)從等待審批的焦慮里解放出來(lái)可以在等待期間繼續(xù)做下一個(gè)任務(wù)。當(dāng)然這不是讓評(píng)審無(wú)限期拖延這里有兩個(gè)兜底機(jī)制第一MR 的標(biāo)簽系統(tǒng)會(huì)自動(dòng)標(biāo)記等待評(píng)審超過(guò) 8 小時(shí)技術(shù)負(fù)責(zé)人會(huì)介入?yún)f(xié)調(diào)第二阻塞性的問(wèn)題可以升級(jí)為語(yǔ)音溝通不要求一定要在評(píng)論區(qū)討論完。異步協(xié)作的度就在這里給足空間但不放任。3. 從規(guī)范到工具一套可復(fù)制的 open-code-review 落地配置理念說(shuō)完了到實(shí)操環(huán)節(jié)。Code Review 這件事光靠嘴上約定是撐不起來(lái)的必須把規(guī)則固化到工具鏈里讓流程自動(dòng)發(fā)生。下面是我最終沉淀下來(lái)的一套配置可以直接抄。3.1 審查規(guī)則矩陣先劃分清楚什么必須人審、什么機(jī)器審、什么不審落地第一步我給團(tuán)隊(duì)畫(huà)了一張審查規(guī)則矩陣核心目的是讓每個(gè) MR 的評(píng)審人能明確知道自己的審查重點(diǎn)在哪里以及哪些事情根本不用人看。這張表很重要它解決了評(píng)審人注意力往哪兒放的問(wèn)題。審查類型對(duì)象責(zé)任人目的基礎(chǔ)規(guī)范格式、Lint 檢查、類型檢查機(jī)器CI把低級(jí)問(wèn)題擋在評(píng)審之前邏輯正確性核心業(yè)務(wù)代碼、狀態(tài)流轉(zhuǎn)、邊界處理指定評(píng)審人發(fā)現(xiàn)真實(shí) bug 和設(shè)計(jì)問(wèn)題架構(gòu)合理性大型改動(dòng)、跨模塊改動(dòng)技術(shù)負(fù)責(zé)人參與把控系統(tǒng)整體方向約定一致性命名、目錄結(jié)構(gòu)、接口設(shè)計(jì)全員保持代碼庫(kù)風(fēng)格統(tǒng)一無(wú)需審查依賴版本小升級(jí)、純文案修改、生成代碼無(wú)減少無(wú)意義的審查負(fù)擔(dān)這張表掛在團(tuán)隊(duì)文檔里之后最明顯的變化是大家終于不用為一個(gè)新增的工具函數(shù)到底要不要走完整審查吵架了。以前每次遇到這種模糊地帶都要反復(fù)確認(rèn)這個(gè)要不要評(píng)審人看現(xiàn)在表里寫(xiě)得清清楚楚省下來(lái)的精力全用在了真正需要人的地方。3.2 小步提交MR 越小審查質(zhì)量越高第二個(gè)原則是強(qiáng)制性的MR 的規(guī)模要與審查深度成反比。我把 MR 的合理規(guī)模定為 200 行左右含測(cè)試。上限設(shè)在 400 行超過(guò) 400 行的 MR 必須拆分成多個(gè)子 MR或者約定至少有兩個(gè)評(píng)審人參與。這個(gè)規(guī)定一開(kāi)始阻力非常大很多組員覺(jué)得拆分 MR 很麻煩尤其是那種牽一發(fā)動(dòng)全身的改動(dòng)感覺(jué)拆開(kāi)之后反而多了一堆合并工作。但執(zhí)行一個(gè)月后幾乎所有人都認(rèn)可了。原因很簡(jiǎn)單小 MR 的上下文容易裝載評(píng)審人不需要在大腦里維護(hù)一個(gè)龐大的狀態(tài)表能真正把邏輯理清楚另外小 MR 合并沖突概率低開(kāi)發(fā)之間的相互阻塞也少了反而是大 MR 經(jīng)常在合并時(shí)跟別人撞車改沖突就改半天。我在 CI 里加了一個(gè)腳本MR 新增行數(shù)超過(guò) 400 行時(shí)自動(dòng)打標(biāo)簽并提醒拆分從技術(shù)手段上保證這個(gè)規(guī)則不會(huì)被突破。這種自動(dòng)化約束比群公告管用得多人記不住規(guī)則工具能記住。3.3 CI 層攔截機(jī)器先審一輪人的精力留給真正的設(shè)計(jì)問(wèn)題現(xiàn)在的工具鏈已經(jīng)完全可以做到讓機(jī)器先審一輪再讓人去讀代碼。我在項(xiàng)目里配置了這樣一組流水線# .github/workflows/open-code-review.yml name: open-code-review on: pull_request: types: [opened, synchronize, ready_for_review] jobs: static-check: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - name: Install dependencies run: npm ci - name: Lint and format check run: npm run lint npx prettier --check . - name: Type check run: npm run typecheck - name: Test with coverage run: npm run test -- --coverage - name: Security scan run: npx audit-ci --moderate這條流水線的效果是格式問(wèn)題、類型錯(cuò)誤、低等級(jí)安全漏洞、測(cè)試覆蓋不足這類問(wèn)題全部在評(píng)審人介入之前被攔截掉。評(píng)審人打開(kāi) MR 時(shí)看到的 diff不需要在縮進(jìn)和分號(hào)上浪費(fèi)任何時(shí)間可以直接進(jìn)入邏輯層面。除了這些常規(guī)靜態(tài)檢查我還接了一層 AI 輔助審查把 PR diff 自動(dòng)發(fā)給大模型做一輪輕量級(jí)掃描重點(diǎn)看常見(jiàn)的空指針、越界、資源泄漏、并發(fā)隱患輸出建議掛在 PR 下面。AI 的建議并不總對(duì)但它的價(jià)值在于把一部分重復(fù)性、模式化的問(wèn)題先圈出來(lái)讓人的審查注意力集中到更重要的設(shè)計(jì)問(wèn)題上。關(guān)于 AI 接入后遇到的坑后面有一節(jié)專門講這里先不展開(kāi)。4. 落地踩坑實(shí)錄從形式化到有效審查之間隔著真實(shí)距離再好的方案落地過(guò)程中一定會(huì)有幺蛾子。我把這兩個(gè)月里踩的比較典型的幾個(gè)坑和對(duì)應(yīng)的修正寫(xiě)出來(lái)給后來(lái)的人排雷。4.1 第一個(gè)坑規(guī)則定得太細(xì)團(tuán)隊(duì)直接放棄抵抗第一版 open-code-review 規(guī)則我寫(xiě)了二十多條從 MR 標(biāo)題格式、提交信息規(guī)范到每個(gè)目錄的職責(zé)邊界全做了約束。執(zhí)行了兩周團(tuán)隊(duì)里的怨氣值肉眼可見(jiàn)地攀升甚至有兩個(gè)同事明確表示這么寫(xiě)代碼不如不寫(xiě)。復(fù)盤之后我意識(shí)到問(wèn)題出在過(guò)度設(shè)計(jì)上。規(guī)則是輔助工具不是目的本身。當(dāng)規(guī)則多到需要開(kāi)發(fā)花額外的精力去記憶和遵守時(shí)它就開(kāi)始消耗團(tuán)隊(duì)的認(rèn)知資源和積極性了。而且規(guī)則的邊際效益是遞減的最核心的三條規(guī)則能解決 80% 的問(wèn)題剩下的 20% 用二十條規(guī)則去摳性價(jià)比極低。修正方案很粗暴砍掉三分之二的規(guī)則只保留最有價(jià)值的核心項(xiàng)——MR 必須帶行內(nèi)評(píng)論、必須跑過(guò) CI、超過(guò) 400 行必須有第二個(gè)評(píng)審人。其他細(xì)節(jié)全部降級(jí)為建議用文檔里的最佳實(shí)踐章節(jié)來(lái)承載。砍完之后流程負(fù)擔(dān)立刻降下來(lái)了大家執(zhí)行規(guī)則的意愿反而提高了。4.2 第二個(gè)坑AI 審查接入后人的參與度反而下降了我是在第二周接入 AI 輔助審查的。第一個(gè)月的確很爽AI 能掃出不少空指針和邊界問(wèn)題PR 的機(jī)器已審標(biāo)簽讓團(tuán)隊(duì)有一種質(zhì)量有保障的錯(cuò)覺(jué)。但一個(gè)月后我再統(tǒng)計(jì)數(shù)據(jù)發(fā)現(xiàn)人的行內(nèi)評(píng)論數(shù)反而下降了 30%真正在設(shè)計(jì)、擴(kuò)展性、可維護(hù)性這些深層次問(wèn)題上提出討論的比例越來(lái)越低。原因其實(shí)不難理解大家看到 AI 已經(jīng)審過(guò)了潛意識(shí)里覺(jué)得機(jī)器看過(guò)了應(yīng)該沒(méi)啥大問(wèn)題人的審查動(dòng)機(jī)被削弱了。這是一個(gè)非常典型的自動(dòng)化陷阱——工具代替人做了一部分事情之后人不是把省下來(lái)的精力投入到更深層的問(wèn)題上而是直接選擇了偷懶。人這種東西能省力的時(shí)候是一定會(huì)省力的這是本能。修正方法是把人機(jī)分工的邊界重新劃清楚AI 的掃描結(jié)果只是參考不算正式審查意見(jiàn)同時(shí)要求每個(gè) MR 的評(píng)審人必須至少提出一條設(shè)計(jì)層面的問(wèn)題或者確認(rèn)說(shuō)明否則視為未完成審查。我甚至加了一個(gè)小的數(shù)據(jù)追蹤每周給團(tuán)隊(duì)看一眼本周人的有效評(píng)論 vs AI 評(píng)論的比例讓問(wèn)題暴露在陽(yáng)光下。這樣把人的責(zé)任底線重新立了起來(lái)AI 變成輔助而不是替代。4.3 第三個(gè)坑大型 PR 的注意力稀釋即使在200 行最佳、400 行上限的規(guī)則約束下還是偶爾會(huì)出現(xiàn)一個(gè) 800 行的大 PR。這種 MR 通常是需求本身就繞不開(kāi)的大改動(dòng)比如底層依賴升級(jí)、數(shù)據(jù)庫(kù)遷移、權(quán)限體系重構(gòu)。按規(guī)則拆分吧有時(shí)候確實(shí)拆不開(kāi)硬拆反而破壞整個(gè)改動(dòng)的原子性。大 PR 的致命問(wèn)題在于注意力稀釋評(píng)審人從頭看到尾看到第 500 行時(shí)已經(jīng)忘了第 80 行的上下文到第 700 行時(shí)基本處于看字不認(rèn)識(shí)字的狀態(tài)最后只能草草通過(guò)。這種評(píng)審比不評(píng)審更危險(xiǎn)因?yàn)樗o了團(tuán)隊(duì)一種虛假的安全感——這個(gè)改動(dòng)我們審過(guò)了沒(méi)問(wèn)題但實(shí)際上什么問(wèn)題都沒(méi)發(fā)現(xiàn)。對(duì)大型改動(dòng)我定了兩條補(bǔ)充規(guī)則一是必須拆分子任務(wù)提交也就是大 PR 內(nèi)部按模塊拆成多個(gè) commit每個(gè) commit 保證可獨(dú)立審查二是超過(guò) 600 行時(shí)強(qiáng)制分配兩個(gè)評(píng)審人分別負(fù)責(zé)不同模塊。執(zhí)行下來(lái)大型 PR 的討論質(zhì)量明顯好于從前雖然還是不如小 MR 那么干凈但至少不會(huì)再出現(xiàn)看字不認(rèn)識(shí)字然后閉眼通過(guò)的情況了。4.4 復(fù)盤后的流程修正兩個(gè)月里我做了三次流程調(diào)整。第一次砍規(guī)則、第二次劃清人機(jī)邊界、第三次針對(duì)大 PR 設(shè)計(jì)分級(jí)評(píng)審機(jī)制。每次調(diào)整的依據(jù)不是拍腦袋而是看數(shù)據(jù)行內(nèi)評(píng)論數(shù)量、意見(jiàn)采納率、MR 從提交到合并的平均時(shí)長(zhǎng)、以及團(tuán)隊(duì)滿意度。到第六周左右數(shù)據(jù)終于穩(wěn)定在一個(gè)讓我滿意的水平指標(biāo)調(diào)整前調(diào)整后平均 MR 大小450 行185 行有設(shè)計(jì)層面討論的 MR 占比8%61%平均評(píng)審響應(yīng)時(shí)長(zhǎng)26 小時(shí)6 小時(shí)因評(píng)審發(fā)現(xiàn)問(wèn)題而回退的 MR3%17%這個(gè)對(duì)比讓我確認(rèn)了一件事流程設(shè)計(jì)不是越重越好而是越聚焦越好。找到真正影響質(zhì)量的那幾個(gè)關(guān)鍵杠桿比鋪一大堆規(guī)則有效得多。所謂開(kāi)放式審查不是放開(kāi)規(guī)則而是把規(guī)則用在刀刃上剩下的空間留給人的判斷和討論。5. 讓 Code Review 變成團(tuán)隊(duì)長(zhǎng)期資產(chǎn)的一些進(jìn)階經(jīng)驗(yàn)最后分享幾個(gè)讓我覺(jué)得當(dāng)初折騰這套方案值了的長(zhǎng)期收益以及一些更進(jìn)階的玩法。這些不是一開(kāi)始就能看到的是在流程穩(wěn)定運(yùn)行兩三個(gè)月之后慢慢浮出來(lái)的。5.1 把審查評(píng)論沉淀成團(tuán)隊(duì)知識(shí)庫(kù)我發(fā)現(xiàn)每一次高質(zhì)量的審查討論其實(shí)都是很好的技術(shù)文檔素材。比如有人問(wèn)這里為什么不直接用緩存而是裸查數(shù)據(jù)庫(kù)評(píng)審人解釋了當(dāng)前業(yè)務(wù)場(chǎng)景下緩存一致性成本過(guò)高、加上這個(gè)接口的 QPS 根本到不了需要緩存的量級(jí)這個(gè)討論本身就是一條非常有價(jià)值的架構(gòu)決策記錄。后來(lái)我讓組員每周花半小時(shí)整理本周最有價(jià)值的審查討論脫敏后歸檔到團(tuán)隊(duì)的知識(shí)庫(kù)。幾個(gè)月下來(lái)這個(gè)審查集錦成了新員工入職培訓(xùn)的重要材料很多典型坑新人看完就不需要再踩一遍了。以前新人的培養(yǎng)基本靠口頭傳幫帶效率低而且信息損耗大現(xiàn)在有了這些真實(shí)案例新人自己就能完成很大一部分的避坑教育。5.2 用審查記錄反向校準(zhǔn)技術(shù)債務(wù)地圖審查記錄里還藏著技術(shù)債務(wù)的指向性信號(hào)。哪個(gè)模塊的 MR 經(jīng)常被評(píng)審人提同樣的意見(jiàn)哪類問(wèn)題反復(fù)出現(xiàn)這些數(shù)據(jù)比任何靜態(tài)掃描工具都能更真實(shí)地反映系統(tǒng)的薄弱環(huán)節(jié)。靜態(tài)掃描只能告訴你這里有個(gè)潛在 bug 模式但它沒(méi)法告訴你團(tuán)隊(duì)在這個(gè)模塊上反復(fù)犯同一類錯(cuò)誤這件事。我把季度審查數(shù)據(jù)按模塊聚合了一下發(fā)現(xiàn)支付模塊的并發(fā)處理相關(guān)意見(jiàn)占了全團(tuán)隊(duì)同類意見(jiàn)的半數(shù)以上。基于這個(gè)信號(hào)我們組織了一次專門針對(duì)支付模塊并發(fā)模型的專項(xiàng)重構(gòu)從那之后這個(gè)模塊相關(guān)的評(píng)審意見(jiàn)數(shù)量下降了約百分之四十。審查數(shù)據(jù)反過(guò)來(lái)指導(dǎo)架構(gòu)演進(jìn)這個(gè)玩法是我一開(kāi)始沒(méi)預(yù)料到的但它帶來(lái)的價(jià)值幾乎不亞于審查本身。5.3 從代碼審查走向設(shè)計(jì)評(píng)審當(dāng)代碼審查文化穩(wěn)定之后我發(fā)現(xiàn)團(tuán)隊(duì)開(kāi)始自然而然地要求設(shè)計(jì)先行了。改動(dòng)比較大的需求開(kāi)發(fā)會(huì)先寫(xiě)一個(gè)簡(jiǎn)短的設(shè)計(jì)說(shuō)明把它當(dāng)作一個(gè)虛擬 MR 發(fā)給相關(guān)同事用和代碼審查一樣的行內(nèi)評(píng)論機(jī)制來(lái)討論設(shè)計(jì)本身。這不需要任何額外的工具配置就是復(fù)用現(xiàn)有的 MR 流程只是把提交代碼提前成了提交設(shè)計(jì)文檔。這其實(shí)是我最想看到的場(chǎng)景當(dāng)團(tuán)隊(duì)習(xí)慣了建設(shè)性的、開(kāi)放式的討論方式這套方法就不光適用于代碼了它可以順滑地遷移到系統(tǒng)設(shè)計(jì)評(píng)審、接口協(xié)議討論、甚至團(tuán)隊(duì)流程的制定上。代碼審查只是土壤結(jié)出來(lái)的果實(shí)是整個(gè)團(tuán)隊(duì)的協(xié)作水位。從最初的形式化過(guò)場(chǎng)到現(xiàn)在的討論氛圍我個(gè)人的體會(huì)是起作用的不是某一個(gè)單一的工具或者規(guī)則而是把審查定位從門禁改成協(xié)作之后整個(gè)流程自然生長(zhǎng)出來(lái)的樣子。如果你也在被低質(zhì)量、或者被抵觸的 Code Review 折磨先別急著換工具不妨想想你們對(duì)審查的定義是不是本身就出了問(wèn)題。開(kāi)放式的討論比封閉式的審批獲得好代碼的概率要高得多。