1. 為什么大多數(shù)團(tuán)隊(duì)的Code Review都在走過(guò)場(chǎng)1.1 那些年我們開(kāi)過(guò)的形式主義PR我剛開(kāi)始帶團(tuán)隊(duì)那會(huì)兒最頭疼的不是需求排期不是上線(xiàn)故障而是催人 code review。每次迭代發(fā)版前我都要在群里挨個(gè)這個(gè)PR誰(shuí)幫忙看一眼結(jié)果通常是三種回復(fù)我沒(méi)空我看過(guò)了沒(méi)什么問(wèn)題你先合吧出了問(wèn)題再說(shuō)。后來(lái)我統(tǒng)計(jì)了一下團(tuán)隊(duì)里合并的PR平均停留時(shí)間是 3.8 天其中真正花在審查上的時(shí)間不足 20 分鐘。最諷刺的是線(xiàn)上事故里有一大半恰恰出現(xiàn)在那些快速通過(guò)的改動(dòng)上。這就是典型的形式主義Code Review流程在走但大腦沒(méi)上線(xiàn)PR在掛但沒(méi)人真正看評(píng)論在刷但全是LGTM這種沒(méi)有信息量的表態(tài)。我開(kāi)始認(rèn)真思考一件事代碼審查到底怎樣才能從走過(guò)場(chǎng)變成真正能攔住缺陷、沉淀知識(shí)、提升團(tuán)隊(duì)整體水平的機(jī)制也是在那段時(shí)間我接觸并實(shí)踐了一套被我稱(chēng)為open-code-review的開(kāi)源化代碼審查工作流方案。它不是某個(gè)單一工具而是圍繞開(kāi)放、透明、可度量三個(gè)原則把自動(dòng)化檢查、人工審查、流程反饋三層打通的組合方案。1.2 Code Review的隱性?xún)r(jià)值往往被團(tuán)隊(duì)嚴(yán)重低估很多人對(duì)代碼審查的理解停留在找bug這個(gè)層面這也是它容易被砍掉的原因——反正有測(cè)試反正有CI反正線(xiàn)上出了問(wèn)題再說(shuō)。但我在實(shí)際推行open-code-review之后發(fā)現(xiàn)代碼審查真正值錢(qián)的地方有三層第一層是缺陷攔截。靜態(tài)檢查、單測(cè)覆蓋能攔住一部分問(wèn)題但邏輯錯(cuò)誤、邊界遺漏、業(yè)務(wù)理解偏差只有人眼能發(fā)現(xiàn)。這一層價(jià)值最直接但也最容易被自動(dòng)化工具部分替代。第二層是知識(shí)擴(kuò)散。每一次審查都是一次小型的代碼教學(xué)。新人通過(guò)看老手的修改方式理解團(tuán)隊(duì)規(guī)范服務(wù)端的人通過(guò)審查前端PR了解整體架構(gòu)這種隱性知識(shí)的傳遞效率遠(yuǎn)高于專(zhuān)門(mén)的技術(shù)分享。很多團(tuán)隊(duì)單點(diǎn)故障嚴(yán)重某個(gè)核心模塊只有一個(gè)人能維護(hù)核心原因之一就是平時(shí)沒(méi)有足夠的代碼審查去擴(kuò)散上下文。第三層是設(shè)計(jì)約束。審查過(guò)程中資深的同學(xué)會(huì)追問(wèn)為什么不用現(xiàn)有的工具類(lèi)這個(gè)抽象是不是過(guò)度設(shè)計(jì)了這里引入新的依賴(lài)是否必要。這些看似啰嗦的討論其實(shí)是在維護(hù)代碼庫(kù)的長(zhǎng)期可維護(hù)性。一套沒(méi)有審查約束的代碼庫(kù)半年后基本都會(huì)演變成大泥球。如果只把代碼審查當(dāng)成一個(gè)質(zhì)量關(guān)卡那它很容易被跳過(guò)也很容易在發(fā)版壓力下被妥協(xié)。但如果把它當(dāng)成團(tuán)隊(duì)工程能力的放大器那這套機(jī)制就值得認(rèn)真投入。2. 三種主流代碼審查模式我為什么最后選了半異步Pull Request2.1 面對(duì)面審查效率高但不可追溯回到方案選型。在設(shè)計(jì)open-code-review之前我研究過(guò)代碼審查的幾種主流形態(tài)。第一種是面對(duì)面審查Over-the-shoulder review兩個(gè)人坐在一起作者逐段講解審查者看著屏幕提問(wèn)。這種方式的優(yōu)點(diǎn)是溝通效率極高上下文交代完整很多問(wèn)題幾分鐘就能達(dá)成共識(shí)。但它的短板也很明顯不可追溯。討論的過(guò)程沒(méi)有留痕結(jié)論散落在聊天記錄里后續(xù)想復(fù)盤(pán)為什么這里這樣改完全找不到依據(jù)。而且它需要兩個(gè)人同時(shí)有空在分布式辦公的大環(huán)境下幾乎無(wú)法常態(tài)化。所以這種模式只適合關(guān)鍵模塊的專(zhuān)項(xiàng)評(píng)審不適合作為日常流程。2.2 Gerrit式集中審查嚴(yán)謹(jǐn)?shù)T(mén)檻偏高第二種是Gerrit式的集中審查模式。所有變更先進(jìn)一個(gè)待審查隊(duì)列用git push refs/for/master這樣的方式提交審查者通過(guò)Web界面逐行評(píng)論通過(guò)多個(gè)Reviewer的Score后才能入庫(kù)。這種模式在Android等大型開(kāi)源項(xiàng)目里應(yīng)用廣泛嚴(yán)謹(jǐn)度極高適合對(duì)代碼質(zhì)量有極高要求的場(chǎng)景。但它的問(wèn)題是學(xué)習(xí)成本太高。團(tuán)隊(duì)里大多數(shù)人習(xí)慣了GitHub的PR工作流切換到Gerrit后push refs/for這套概念和Change-IdScore體系需要一到兩周的適應(yīng)期。對(duì)于中小團(tuán)隊(duì)這個(gè)遷移成本往往大過(guò)了收益。2.3 GitHub/GitLab式Pull Request權(quán)衡下的最優(yōu)解第三種就是大家最熟悉的Pull Request模式。分支開(kāi)發(fā)完推送到遠(yuǎn)端發(fā)起合并請(qǐng)求審查者在Diff頁(yè)面逐行評(píng)論支持內(nèi)聯(lián)回復(fù)、多人協(xié)審、CI狀態(tài)集成。它在靈活性、可追溯性、工具生態(tài)之間取得了最好的平衡這也是open-code-review最終采用的底座。三種模式對(duì)比下來(lái)Pull Request模式對(duì)我的團(tuán)隊(duì)最合適。我們?cè)诒Ａ鬚R機(jī)制的基礎(chǔ)上重點(diǎn)解決三個(gè)被大多數(shù)團(tuán)隊(duì)忽略的問(wèn)題審查前自動(dòng)化閘門(mén)太弱、審查中缺少范圍引導(dǎo)、審查后沒(méi)有度量反饋。整套方案的搭建可以分三部分來(lái)講。3. 從零搭建open-code-review工作流分層架構(gòu)與落地步驟3.1 第一層把能自動(dòng)化的事情全部交給機(jī)器這套工作流的第一層是人機(jī)分工中的機(jī)。很多團(tuán)隊(duì)的上線(xiàn)流程里只有一個(gè)簡(jiǎn)單的CI——跑通測(cè)試就算完。結(jié)果審查者打開(kāi)PR時(shí)一半精力浪費(fèi)在這個(gè)空格為什么不對(duì)這里有個(gè)明顯的ESLint警告這類(lèi)機(jī)器一眼就能識(shí)別的問(wèn)題上。這不僅浪費(fèi)人工還會(huì)讓審查者產(chǎn)生疲勞降低對(duì)真正嚴(yán)重問(wèn)題的敏感度。open-code-review的第一層設(shè)計(jì)原則是凡是能從規(guī)則層面定義的問(wèn)題全部在提交時(shí)就擋住。具體拆開(kāi)是三道閘門(mén)第一道是格式與風(fēng)格統(tǒng)一。不管團(tuán)隊(duì)用Prettier、Black還是gofmt必須在CI里執(zhí)行檢查并強(qiáng)制失敗。不要爭(zhēng)論哪種風(fēng)格更好沒(méi)有意義統(tǒng)一就是最大的意義。第二道是靜態(tài)代碼檢查。ESLint、SonarQube、Checkstyle這些工具按團(tuán)隊(duì)的規(guī)范庫(kù)配置好圈復(fù)雜度超標(biāo)、明顯的空指針隱患、未使用的變量全部在審查前拉黑。第三道是測(cè)試與覆蓋率門(mén)禁。核心模塊的行覆蓋率低于80%、全量測(cè)試有失敗PR不允許合并。這里用GitHub Actions做一個(gè)最小化示例我在團(tuán)隊(duì)里實(shí)際用的就是這套思路name: open-code-review-ci on: pull_request: types: [opened, synchronize, reopened] jobs: quality-gate: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - uses: actions/setup-nodev4 with: node-version: 20 - name: Install dependencies run: npm ci - name: Lint check run: npm run lint - name: Type check run: npm run type-check - name: Unit test with coverage run: npm run test:coverage - name: Enforce coverage threshold run: | npx jest --coverage --coverageThreshold{global:{lines:80,statements:80}}需要特別說(shuō)明的是覆蓋率門(mén)禁這個(gè)參數(shù)要謹(jǐn)慎設(shè)。我見(jiàn)過(guò)一些團(tuán)隊(duì)把要求提到100%結(jié)果大家開(kāi)始寫(xiě)毫無(wú)斷言的湊數(shù)用例覆蓋率數(shù)字很好看的背后是大量無(wú)效測(cè)試。在我們的實(shí)踐里核心包和工具庫(kù)要求90%業(yè)務(wù)代碼要求75%到80%這是一個(gè)既不縱容也不逼迫的平衡點(diǎn)。3.2 第二層給人工審查者一張限定范圍的地圖自動(dòng)化閘門(mén)跑完后PR才真正進(jìn)入人工審查環(huán)節(jié)。但這里有個(gè)常常被忽略的效率殺手審查者打開(kāi)一個(gè)5000行的Diff不知道重點(diǎn)看哪里只能從頭到尾硬讀。讀到最后精力已經(jīng)渙散后半部分的代碼基本是看過(guò)但沒(méi)看透。open-code-review的第二層原則是用結(jié)構(gòu)化信息縮小人工審查的注意力范圍。具體做法有三個(gè)一是嚴(yán)格使用PR模板強(qiáng)制作者交代背景、改動(dòng)范圍、影響面、自測(cè)情況。這個(gè)模板不是擺設(shè)它讓作者在發(fā)起審查前先自己過(guò)一遍改動(dòng)也讓審查者在開(kāi)始前就知道這是改了個(gè)什么東西、為什么改、動(dòng)了哪些模塊。二是用CODEOWNERS文件明確每個(gè)模塊的負(fù)責(zé)人。代碼改動(dòng)會(huì)自動(dòng)通知對(duì)應(yīng)模塊的owner來(lái)審查避免出現(xiàn)核心邏輯被路徑最外層的人走了個(gè)形式。這是一個(gè)被嚴(yán)重低估的簡(jiǎn)單配置# .github/CODEOWNERS /src/core/ tiger-wang lisa-chen /src/api/ tiger-wang james-liu /docs/ lisa-chen三是把審查范圍引導(dǎo)當(dāng)成工具配置來(lái)做。GitHub本身會(huì)展示改動(dòng)文件列表我建議大家按照核心邏輯 - 邊界條件 - 接入點(diǎn) - 測(cè)試用例的順序去讀Diff而不是從頭滾到尾。核心邏輯決定這個(gè)改動(dòng)是否成立邊界條件決定是否會(huì)在特定輸入下爆炸接入點(diǎn)決定它會(huì)不會(huì)破壞現(xiàn)有功能最后看測(cè)試是否覆蓋了前面提到的關(guān)鍵分支。3.3 第三層用數(shù)據(jù)反饋驅(qū)動(dòng)流程改進(jìn)這一層是open-code-review里最關(guān)鍵也最容易被忽略的部分。大多數(shù)團(tuán)隊(duì)的代碼審查沒(méi)有數(shù)據(jù)反饋全靠感覺(jué)判斷最近review好像挺快/挺慢。而我們的做法是在流程跑完一段時(shí)間后回看四類(lèi)指標(biāo)讓問(wèn)題自己浮出來(lái)。第一類(lèi)是評(píng)審時(shí)效PR從發(fā)起到第一次有效評(píng)論的平均時(shí)間。如果這個(gè)時(shí)間超過(guò)一個(gè)工作日說(shuō)明團(tuán)隊(duì)在審查上的優(yōu)先級(jí)安排有問(wèn)題可以考慮給PR設(shè)置SLA提醒機(jī)器人。第二類(lèi)是評(píng)論密度平均每個(gè)PR的評(píng)論條數(shù)和有效討論線(xiàn)程數(shù)。太低說(shuō)明大家還在走過(guò)場(chǎng)太高說(shuō)明作者的設(shè)計(jì)溝通能力或者代碼質(zhì)量有系統(tǒng)性問(wèn)題。第三類(lèi)是缺陷逃逸率已經(jīng)合并的改動(dòng)在后續(xù)測(cè)試甚至線(xiàn)上暴露出的bug數(shù)量。這是最能衡量審查質(zhì)量的核心指標(biāo)。第四類(lèi)是改動(dòng)撤回率因?yàn)閷彶椴煌ㄟ^(guò)而打回重寫(xiě)的PR比例。這些數(shù)據(jù)可以用工具自動(dòng)拉取匯總。GitHub API本身就能獲取PR的創(chuàng)建時(shí)間、評(píng)論時(shí)間、合并時(shí)間寫(xiě)個(gè)小腳本就能生成周報(bào)。我這邊用的是Python腳本每周一把上周的review數(shù)據(jù)拉出來(lái)生成一個(gè)簡(jiǎn)單的趨勢(shì)表格貼在團(tuán)隊(duì)周會(huì)上用。不需要復(fù)雜的BI系統(tǒng)一張Excel透視表都?jí)蛴藐P(guān)鍵是讓團(tuán)隊(duì)看見(jiàn)趨勢(shì)知道哪里在惡化。4. 讓審查從看過(guò)到看透一份可復(fù)制的審查清單4.1 業(yè)務(wù)邏輯與邊界條件用異常分支反推代碼第三層機(jī)制搭建完之后接下來(lái)要解決的是審查者本身的能力問(wèn)題。我見(jiàn)過(guò)很多認(rèn)真的同學(xué)所謂認(rèn)真審查就是從頭到尾把每行代碼讀一遍讀完之后覺(jué)得好像沒(méi)啥問(wèn)題就通過(guò)了。這種審查最大的盲區(qū)在于它順著作者的思路走很容易被帶進(jìn)作者預(yù)設(shè)的邏輯里卻忽略了那些沒(méi)被覆蓋到的分支。我在團(tuán)隊(duì)里推行了一套反向?qū)彶榈乃悸贰玫揭欢魏诵倪壿嬒葎e看作者是怎么寫(xiě)的而是先問(wèn)自己如果輸入是空值會(huì)怎樣如果用戶(hù)連續(xù)點(diǎn)兩次會(huì)怎樣如果這個(gè)接口被并發(fā)調(diào)用會(huì)怎樣如果外部依賴(lài)超時(shí)了會(huì)怎樣把這些問(wèn)題列出來(lái)再回頭去看代碼有沒(méi)有處理這些情況。用這套思路去審查大部分空指針、重復(fù)提交、超時(shí)未處理的問(wèn)題都能在PR階段被攔住。邊界條件審查重點(diǎn)關(guān)注四類(lèi)常見(jiàn)場(chǎng)景集合和字符串為空或超長(zhǎng)、數(shù)字為0或負(fù)數(shù)、外部接口超時(shí)或返回異常、并發(fā)場(chǎng)景下的競(jìng)態(tài)條件。這四點(diǎn)不是教條是從大量線(xiàn)上事故里提煉出來(lái)的高頻觸發(fā)點(diǎn)。舉個(gè)例子有一次我的團(tuán)隊(duì)在審查一個(gè)優(yōu)惠券發(fā)放接口時(shí)就是因?yàn)閱?wèn)了如果用戶(hù)在同一毫秒內(nèi)提交兩次請(qǐng)求會(huì)怎樣這個(gè)問(wèn)題才發(fā)現(xiàn)了缺少冪等校驗(yàn)的嚴(yán)重缺陷。4.2 安全與數(shù)據(jù)校驗(yàn)每一行輸入都不可信安全審查是最容易被普通開(kāi)發(fā)忽略的部分但它恰恰是代碼審查最有價(jià)值的環(huán)節(jié)。很多漏洞都是在審查階段被發(fā)現(xiàn)的而不是等到上線(xiàn)后被人利用才發(fā)現(xiàn)。我不要求團(tuán)隊(duì)每個(gè)成員都成為安全專(zhuān)家但希望大家養(yǎng)成一個(gè)條件反射凡是涉及到用戶(hù)輸入、外部傳入?yún)?shù)、數(shù)據(jù)庫(kù)查詢(xún)拼接的地方默認(rèn)它是惡意的再看代碼有沒(méi)有擋住。具體來(lái)說(shuō)需要關(guān)注幾個(gè)高頻安全風(fēng)險(xiǎn)點(diǎn)SQL注入風(fēng)險(xiǎn)查詢(xún)語(yǔ)句是否用了參數(shù)綁定而不是字符串拼接X(jué)SS風(fēng)險(xiǎn)用戶(hù)提供的內(nèi)容在渲染到頁(yè)面時(shí)是否做了轉(zhuǎn)義越權(quán)訪(fǎng)問(wèn)接口有沒(méi)有校驗(yàn)當(dāng)前登錄用戶(hù)的權(quán)限敏感信息泄露日志里有沒(méi)有打印token、密碼、身份證號(hào)之類(lèi)的字段依賴(lài)漏洞新引入的npm包或pip包有沒(méi)有經(jīng)過(guò)安全掃描。這里特別要提一個(gè)審查習(xí)慣當(dāng)PR里新引入一個(gè)第三方依賴(lài)時(shí)一定要追問(wèn)一句為什么要引有沒(méi)有更成熟或者更輕量的替代我見(jiàn)過(guò)因?yàn)橐粋€(gè)簡(jiǎn)單的日期格式化需求就引入了一個(gè)完整工具庫(kù)最后發(fā)現(xiàn)這個(gè)庫(kù)帶了十來(lái)個(gè)傳遞依賴(lài)安全掃描直接亮紅燈。審查者的職責(zé)就是不放過(guò)這類(lèi)圖省事的引入。4.3 性能與并發(fā)先問(wèn)會(huì)帶來(lái)多少數(shù)據(jù)量再判斷性能審查并不是要求每個(gè)PR都做壓測(cè)但至少要建立基本的量級(jí)意識(shí)。審查代碼時(shí)我會(huì)習(xí)慣性問(wèn)兩個(gè)問(wèn)題改動(dòng)所在的這個(gè)接口高峰期QPS大概是多少這段邏輯的時(shí)間復(fù)雜度在數(shù)據(jù)增長(zhǎng)十倍之后會(huì)不會(huì)變成瓶頸幾個(gè)常見(jiàn)的性能反模式可以在審查時(shí)重點(diǎn)找一下循環(huán)里查數(shù)據(jù)庫(kù)在for循環(huán)里執(zhí)行查詢(xún)語(yǔ)句這是最典型的性能殺手應(yīng)該批量查出后映射到內(nèi)存里N1查詢(xún)ORM使用不當(dāng)導(dǎo)致列表頁(yè)每個(gè)元素都發(fā)一次查詢(xún)?nèi)頀呙鑵s不帶索引where條件里的字段沒(méi)有建立索引大數(shù)據(jù)量加載到內(nèi)存一次把幾十萬(wàn)條記錄全部load進(jìn)來(lái)再處理。并發(fā)審查更考驗(yàn)經(jīng)驗(yàn)。需要關(guān)注幾個(gè)點(diǎn)共享的可變狀態(tài)有沒(méi)有加鎖UI上重復(fù)提交有沒(méi)有做防抖或禁用分布式場(chǎng)景下的冪等性是否靠token或唯一索引保證緩存更新是更新還是刪有沒(méi)有可能讀到臟數(shù)據(jù)。這些點(diǎn)不要求審查者記得很完整但審查核心交易鏈路時(shí)建議逐一過(guò)一遍。4.4 可維護(hù)性與命名代碼是寫(xiě)給下一次維護(hù)的人看的如果說(shuō)邏輯、安全、性能是審查的硬指標(biāo)那可維護(hù)性就是軟指標(biāo)。很多代碼能跑能上線(xiàn)但改起來(lái)想哭。審查者在看PR時(shí)要有意識(shí)地用一年后這個(gè)人離職了留下的代碼好不好接這個(gè)標(biāo)準(zhǔn)來(lái)判斷?？删S護(hù)性審查的重點(diǎn)是命名是否準(zhǔn)確表達(dá)了意圖一個(gè)變量叫data還是orderDetailMap對(duì)后來(lái)人的理解效率影響是巨大的。函數(shù)是否過(guò)長(zhǎng)一個(gè)函數(shù)超過(guò)30行就要警惕了超過(guò)50行基本可以斷定該拆了。抽象是否過(guò)度不要為了將來(lái)可能復(fù)用而提前造類(lèi)和接口當(dāng)下能用最少的結(jié)構(gòu)把事情表達(dá)清楚才是優(yōu)先考慮。注釋是否有價(jià)值解釋為什么的注釋是好注釋解釋是什么的注釋是廢話(huà)。4.5 測(cè)試質(zhì)量沒(méi)有斷言的測(cè)試等于沒(méi)寫(xiě)最后說(shuō)測(cè)試審查。很多團(tuán)隊(duì)有覆蓋率門(mén)禁大家也確實(shí)寫(xiě)了測(cè)試但寫(xiě)出來(lái)的測(cè)試質(zhì)量堪憂(yōu)。我見(jiàn)過(guò)不少為了覆蓋率而寫(xiě)的測(cè)試斷言只檢查了函數(shù)能跑通沒(méi)有檢查返回值是否正確mock掉了所有外部依賴(lài)但這個(gè)測(cè)試實(shí)際上什么都沒(méi)驗(yàn)證測(cè)試數(shù)據(jù)設(shè)置得極不合理所有分支都走到了同一條路徑。審查測(cè)試時(shí)的三條建議一是斷言必須有意義至少包含一個(gè)對(duì)預(yù)期行為的驗(yàn)證而不是只調(diào)用一下確保不報(bào)錯(cuò)二是看測(cè)試是否覆蓋了關(guān)鍵的分支和邊界條件而不是只看覆蓋率數(shù)字三是測(cè)試命名應(yīng)該描述行為而非描述實(shí)現(xiàn)比如test_should_return_interested_users_when_age_is_over_60就比test_foo有意義得多。5. 實(shí)操中繞不開(kāi)的坑沖突、情緒與效率5.1 評(píng)論語(yǔ)氣對(duì)事不對(duì)人說(shuō)起來(lái)簡(jiǎn)單做起來(lái)要注意寫(xiě)法代碼審查在技術(shù)之外最大的挑戰(zhàn)其實(shí)是人際協(xié)作。一個(gè)PR被駁回了沒(méi)有經(jīng)驗(yàn)的人會(huì)覺(jué)得我辛辛苦苦寫(xiě)的代碼被否定了一旦情緒上來(lái)技術(shù)討論很快就會(huì)變成對(duì)抗。我在落地流程的過(guò)程中花了很大精力去規(guī)范團(tuán)隊(duì)里的評(píng)論寫(xiě)法。核心做法是三個(gè)建議式表達(dá)不說(shuō)你這里寫(xiě)錯(cuò)了而是說(shuō)這里的邊界情況是否考慮過(guò)不說(shuō)這個(gè)實(shí)現(xiàn)太爛了而是說(shuō)這個(gè)實(shí)現(xiàn)換一種方式會(huì)不會(huì)更清晰不說(shuō)必須改而是說(shuō)如果不改的話(huà)后續(xù)維護(hù)時(shí)可能遇到這樣的問(wèn)題。同樣的意見(jiàn)不同的表述方式接受度差別很大。另外要定的一個(gè)規(guī)則是評(píng)論的攻擊面是代碼不是人。我在團(tuán)隊(duì)里明確提過(guò)如果有人對(duì)某個(gè)方案有強(qiáng)烈意見(jiàn)寧可約個(gè)會(huì)說(shuō)清楚也不要在PR評(píng)論區(qū)里吵。評(píng)論區(qū)的文字沒(méi)有語(yǔ)氣很容易被解讀成攻擊一旦開(kāi)始人身攻擊整個(gè)團(tuán)隊(duì)的審查文化就毀了。5.2 大PR拆小400行是一條合理的紅線(xiàn)有一個(gè)數(shù)據(jù)值得分享改動(dòng)量超過(guò)500行的PR單行缺陷率會(huì)顯著上升審查者的有效審查能力會(huì)快速下降。這不是因?yàn)槲覉F(tuán)隊(duì)的開(kāi)發(fā)者能力差而是人腦的處理帶寬有限。PR越大作者越難講清楚自己的改動(dòng)審查者越難保持全神貫注。所以open-code-review流程里有一條規(guī)定單個(gè)PR的改動(dòng)量原則上不超過(guò)400行。如果超過(guò)必須拆分或由技術(shù)負(fù)責(zé)人說(shuō)明理由。這條規(guī)定看起來(lái)很粗暴但它逼著團(tuán)隊(duì)把大的改動(dòng)拆成多個(gè)有邏輯邊界的PR比如先提交工具函數(shù)和基礎(chǔ)類(lèi)型再提交核心邏輯最后提交接入層。每一部分都能被獨(dú)立審查、獨(dú)立回滾整體協(xié)作體驗(yàn)好了非常多。5.3 審查超時(shí)的處理用自動(dòng)化機(jī)制代替人工催辦每個(gè)做技術(shù)負(fù)責(zé)人的同學(xué)應(yīng)該都有過(guò)追著人要求review的經(jīng)歷。催一次兩次還行每次都靠人肉催流程必然不可持續(xù)。open-code-review的做法是把催辦也自動(dòng)化了。GitHub Actions里可以寫(xiě)一個(gè)定時(shí)任務(wù)掃描所有超過(guò)24小時(shí)還沒(méi)有獲得任何評(píng)論的PR自動(dòng)在評(píng)論區(qū)at對(duì)應(yīng)的CODEOWNERS并打上review-needed標(biāo)簽。再超24小時(shí)沒(méi)有動(dòng)靜就自動(dòng)把PR同步到團(tuán)隊(duì)的飛書(shū)或釘釘群。這套機(jī)制運(yùn)行之后PR等待評(píng)審的平均時(shí)間從之前的3.8天降到了不到1天而且我不再需要扮演人肉催辦機(jī)器人的角色了。5.4 AI輔助審查的正確打開(kāi)方式聊到效率就繞不開(kāi)AI。現(xiàn)在不管是GitHub Copilot的Review功能、CodeRabbit還是各種AI審查工具確實(shí)能幫上不少忙。但一定要擺正AI在流程里的位置它是第一道自動(dòng)化的擴(kuò)展而不是替代人工審查的存在。我的經(jīng)驗(yàn)是AI審查最擅長(zhǎng)的是發(fā)現(xiàn)低級(jí)錯(cuò)誤比如變量名拼寫(xiě)錯(cuò)誤、明顯的空指針隱患、遺漏的邊界判斷、不符合團(tuán)隊(duì)lint規(guī)則的地方。這些交給AI非常劃算。但AI判斷不了這個(gè)模塊的業(yè)務(wù)邏輯是否合理這個(gè)重構(gòu)方向是否符合團(tuán)隊(duì)對(duì)長(zhǎng)期架構(gòu)的共識(shí)這個(gè)依賴(lài)引入值不值得。這些需要領(lǐng)域上下文和團(tuán)隊(duì)默契的判斷只能靠人。所以現(xiàn)在的流程里AI審查結(jié)果會(huì)作為第一輪評(píng)論出現(xiàn)在PR里作者自己先過(guò)一遍AI的意見(jiàn)該改的改掉然后人工審查者再看的時(shí)候注意力就集中在AI覆蓋不了的邏輯和設(shè)計(jì)層面。這套組合拳下來(lái)人工審查的精力從掃雷變成了審題效率提升非常明顯。6. 團(tuán)隊(duì)落地后的真實(shí)效果與我的個(gè)人建議6.1 數(shù)據(jù)的變化比我預(yù)想的更快這套流程在我們團(tuán)隊(duì)跑了一個(gè)季度之后幾個(gè)數(shù)字出現(xiàn)了實(shí)打?qū)嵉淖兓?。PR平均評(píng)審周期從3.8天下滑到0.9天線(xiàn)上缺陷逃逸率合并后一個(gè)迭代內(nèi)被發(fā)現(xiàn)的bug數(shù)量下降了大約43%核心服務(wù)的一次發(fā)布回滾率降低了近一半。更讓我欣慰的是新入職三個(gè)月的同學(xué)在審查過(guò)程中提出的有效意見(jiàn)越來(lái)越多說(shuō)明知識(shí)擴(kuò)散的目標(biāo)也在實(shí)現(xiàn)。有兩點(diǎn)要說(shuō)明的是數(shù)字下降不是某一個(gè)工具帶來(lái)的而是整套機(jī)制的合力。自動(dòng)化閘門(mén)攔住了低級(jí)問(wèn)題人工審查專(zhuān)注在高級(jí)問(wèn)題上數(shù)據(jù)反饋?zhàn)寛F(tuán)隊(duì)持續(xù)修正自己的行為習(xí)慣。單拆任何一環(huán)效果都會(huì)大打折扣。6.2 給準(zhǔn)備搭建代碼審查流程的團(tuán)隊(duì)的三點(diǎn)建議第一從小范圍試點(diǎn)開(kāi)始先挑一兩個(gè)核心服務(wù)或核心倉(cāng)庫(kù)跑通流程寫(xiě)出規(guī)范文檔后再推廣到全團(tuán)隊(duì)。一上來(lái)就鋪開(kāi)一定會(huì)遇到各種流程太重的反彈聲音。第二自動(dòng)化先行把格式檢查、靜態(tài)掃描、覆蓋門(mén)禁全部跑起來(lái)后再談人工審查的深度。如果自動(dòng)化還是一片空白人工審查的精力很快就會(huì)被瑣碎問(wèn)題耗光。第三設(shè)置一個(gè)流程觀察期像我們剛才提到的四類(lèi)指標(biāo)跑了至少一個(gè)月再調(diào)整閾值不要今天聽(tīng)別人說(shuō)80%覆蓋好就設(shè)80%明天遇到一次漏網(wǎng)bug就提到95%反復(fù)橫跳會(huì)讓團(tuán)隊(duì)失去對(duì)規(guī)則的信任。6.3 最后分享一個(gè)我一直在用的小技巧把團(tuán)隊(duì)的審查清單直接寫(xiě)進(jìn)PR模板里讓作者和審查者打開(kāi)PR就看到一份自檢表。這份清單不需要很長(zhǎng)就包含最關(guān)鍵的幾項(xiàng)邊界條件是否覆蓋、安全風(fēng)險(xiǎn)是否排查、代碼是否遵循模塊現(xiàn)有模式、測(cè)試是否覆蓋關(guān)鍵分支。作者提交前先自己過(guò)一遍勾選審查者拿到手后順著清單逐項(xiàng)看。這個(gè)做法的妙處在于它變相地把審查者的關(guān)注點(diǎn)提前傳遞給了作者讓很多問(wèn)題在作者自檢階段就被消化掉了。不是每個(gè)人都能一下子成為資深審查者但一張好的清單能讓所有人都按照資深者的關(guān)注點(diǎn)去思考。代碼審查最終級(jí)的狀態(tài)不是審查者多厲害而是整個(gè)團(tuán)隊(duì)在提交代碼前就已經(jīng)用同一個(gè)標(biāo)準(zhǔn)要求過(guò)自己了。這才是open-code-review這套工作流最值錢(qián)的地方。