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