代碼審查這事兒做過(guò)的團(tuán)隊(duì)都懂它折磨的不只是某一個(gè)人的耐心而是整個(gè)交付鏈路。寫(xiě)代碼的人怕被挑刺審查的人怕漏掉關(guān)鍵點(diǎn)負(fù)責(zé)人怕流程走了個(gè)寂寞。我自己維護(hù)過(guò)幾個(gè)中大型前端項(xiàng)目踩過(guò)不少代碼質(zhì)量的坑后來(lái)沉淀出一套開(kāi)源的、完全自托管的代碼審查方案代號(hào)就叫 open-code-review。它不是一個(gè)單體工具而是一套把靜態(tài)分析、自動(dòng)化規(guī)則、人工走查規(guī)范串成流水線(xiàn)的工程實(shí)踐。這篇文章會(huì)把這套方案的設(shè)計(jì)思路、落地步驟、調(diào)參心得和踩坑記錄一次講透。這套方案解決的核心問(wèn)題很樸素讓機(jī)器先把機(jī)械的活干完把人解放出來(lái)做真正需要判斷力的部分。凡是能用規(guī)則表達(dá)的檢查項(xiàng)——代碼風(fēng)格、重復(fù)代碼、死代碼、明顯的反模式、遺留的FIXME——全部自動(dòng)化凡是需要業(yè)務(wù)理解、架構(gòu)權(quán)衡、邊界推演的部分做成清單化、可跟蹤的人工審查。它適合正在為代碼審查低效發(fā)愁的小團(tuán)隊(duì)也適合想在自己的CI流水線(xiàn)里加一道質(zhì)量閘門(mén)的獨(dú)立開(kāi)發(fā)者。1. 項(xiàng)目的起點(diǎn)為什么我們需要一套開(kāi)放的代碼審查方案1.1 人工審查的困境比想象中嚴(yán)重我剛帶團(tuán)隊(duì)的時(shí)候review代碼基本靠自覺(jué)。后來(lái)復(fù)盤(pán)一個(gè)線(xiàn)上事故發(fā)現(xiàn)根因在代碼審查階段就該被攔下來(lái)但當(dāng)時(shí)所有reviewer都只回了句LGTM沒(méi)人細(xì)看。這不是某個(gè)人偷懶而是人工審查天然有幾道坎。第一道坎是規(guī)模問(wèn)題。一個(gè)功能分支改動(dòng)幾百行加一個(gè)新頁(yè)面改動(dòng)上千行審查者打開(kāi)diff就頭大。真要逐行看下來(lái)一個(gè)中型MR耗掉半天很正常如果當(dāng)天有會(huì)、有線(xiàn)上問(wèn)題要處理審查就會(huì)被無(wú)限順延最后趕在發(fā)版前草草合并。第二道坎是注意力問(wèn)題。審查代碼本質(zhì)上是在做陌生代碼的快速推理人腦能維持高專(zhuān)注的時(shí)間有限?？吹降谖迨畟€(gè)文件的時(shí)候?qū)彶檎邔?duì)前四十九個(gè)文件的印象已經(jīng)開(kāi)始模糊。真正該關(guān)注的并發(fā)問(wèn)題、邊界條件、狀態(tài)流轉(zhuǎn)往往被淹沒(méi)在瑣碎的格式和命名里。第三道坎是經(jīng)驗(yàn)落差。團(tuán)隊(duì)里新人做審查時(shí)不知道看什么、抓不住重點(diǎn)最后只能改改縮進(jìn)和變量命名。有經(jīng)驗(yàn)的老人又可能因?yàn)樘o出的意見(jiàn)高度濃縮新人看不懂也問(wèn)不出口。時(shí)間一長(zhǎng)審查就成了走過(guò)場(chǎng)意見(jiàn)記錄分散在IM聊天里過(guò)后想追溯都找不到。我后來(lái)統(tǒng)計(jì)過(guò)團(tuán)隊(duì)一段時(shí)間的review意見(jiàn)真正由人工發(fā)現(xiàn)的高價(jià)值問(wèn)題占比不到三成剩下七成以上是本來(lái)就能自動(dòng)查出來(lái)的風(fēng)格問(wèn)題、重復(fù)實(shí)現(xiàn)、異常邊界被吞掉這類(lèi)“機(jī)器可識(shí)別”的問(wèn)題。這個(gè)結(jié)論讓我開(kāi)始認(rèn)真考慮能不能把審查里“機(jī)器擅長(zhǎng)”的部分先自動(dòng)化讓人的精力聚焦在機(jī)器做不了的事情上。1.2 open-code-review 的定位機(jī)器先審人再審所以 open-code-review 的核心思想可以概括成四個(gè)字分層審查。先讓工具做一輪全量掃描把客觀(guān)的、可判定的問(wèn)題全部拉出來(lái)并且自動(dòng)貼到MR對(duì)應(yīng)的代碼行上然后人工只需要在這張“過(guò)濾后的清單”上做判斷重點(diǎn)看業(yè)務(wù)邏輯、架構(gòu)合理性、潛在的邊界條件這類(lèi)機(jī)器難以理解的部分。這套方案是開(kāi)放、可自托管的。開(kāi)放指的是兩層含義工具鏈?zhǔn)情_(kāi)源的團(tuán)隊(duì)可以按需替換組件規(guī)則是開(kāi)放的所有檢查規(guī)則都以代碼的形式沉淀在倉(cāng)庫(kù)里誰(shuí)都能提修改意見(jiàn)。自托管則是出于安全和成本的考慮代碼本身是公司的核心資產(chǎn)把整個(gè)倉(cāng)庫(kù)交給外部SaaS平臺(tái)掃描很多團(tuán)隊(duì)在合規(guī)上過(guò)不了關(guān)商業(yè)方案按席位收費(fèi)團(tuán)隊(duì)擴(kuò)張之后成本也偏高。一句話(huà)總結(jié)定位open-code-review 不追求替代人而是做一個(gè)“審查前置過(guò)濾器”把代碼審查從“憑感覺(jué)找人看”變成“機(jī)器先查人再審重點(diǎn)”的標(biāo)準(zhǔn)化流程。它的產(chǎn)物是一次次可跟蹤的MR評(píng)審記錄也是一套可以持續(xù)演進(jìn)的團(tuán)隊(duì)質(zhì)量規(guī)范。2. 整體設(shè)計(jì)與技術(shù)選型把代碼審查這件事拆開(kāi)看2.1 一條審查流水線(xiàn)的五個(gè)層次設(shè)計(jì)這套方案的第一步是把“代碼審查”這件事從抽象拆成具象。我把它分成五個(gè)層次每一層都有明確的工具和輸出物第一層是格式與風(fēng)格層。統(tǒng)一縮進(jìn)、引號(hào)、分號(hào)、命名規(guī)范這些是最沒(méi)爭(zhēng)議的部分也是消耗人工審查最多精力的部分。交給Prettier和ESLint自動(dòng)處理不滿(mǎn)足規(guī)范直接在CI階段報(bào)錯(cuò)根本不讓它流到評(píng)審人眼前。第二層是靜態(tài)缺陷層。檢測(cè)空指針隱患、未使用的變量、可疑的類(lèi)型斷言、危險(xiǎn)的函數(shù)調(diào)用等。ESLint內(nèi)置規(guī)則加上插件規(guī)則集已經(jīng)能覆蓋不少場(chǎng)景SonarQube在這個(gè)層次做交叉驗(yàn)證識(shí)別力更強(qiáng)。第三層是語(yǔ)義與復(fù)雜度層。關(guān)注圈復(fù)雜度、重復(fù)代碼塊、過(guò)長(zhǎng)函數(shù)、過(guò)度嵌套這些都是代碼可維護(hù)性的關(guān)鍵指標(biāo)。SonarQube在這一層提供質(zhì)量門(mén)禁和歷史趨勢(shì)能直觀(guān)看到代碼是越改越亂還是在變好。第四層是團(tuán)隊(duì)規(guī)范層。這一層屬于“機(jī)器里帶有人情味”的部分每個(gè)團(tuán)隊(duì)都有自己的約定比如PR標(biāo)題必須帶模塊前綴、MR改動(dòng)文件數(shù)不能超過(guò)某個(gè)閾值、禁止往主干提交FIXME注釋。通過(guò)Danger JS這種可編程的規(guī)則引擎團(tuán)隊(duì)規(guī)范可以直接變成自動(dòng)化檢查項(xiàng)而不是躺在Wiki里吃灰的文檔。第五層是人工走查層。最終仍需人來(lái)決策的問(wèn)題包括這個(gè)方案是否符合當(dāng)前架構(gòu)演進(jìn)的預(yù)期、是否存在多線(xiàn)程安全風(fēng)險(xiǎn)、接口設(shè)計(jì)是否考慮了后續(xù)擴(kuò)展、異常處理是否覆蓋了真實(shí)業(yè)務(wù)場(chǎng)景。為了讓這些判斷不靠臨場(chǎng)發(fā)揮open-code-review 提供一份可勾選的MR審查清單模板把常見(jiàn)關(guān)注項(xiàng)列全審查者逐項(xiàng)走查后留下結(jié)論。這五層可以類(lèi)比成一輛車(chē)的出廠(chǎng)質(zhì)檢先是產(chǎn)線(xiàn)自動(dòng)化外觀(guān)檢查再上檢測(cè)臺(tái)測(cè)制動(dòng)和排放最后由經(jīng)驗(yàn)豐富的技師路試。每道關(guān)卡篩掉一部分問(wèn)題越往后越需要人的判斷力整體效率就上來(lái)了。2.2 組件選型背后的取舍邏輯很多團(tuán)隊(duì)做自動(dòng)化審查時(shí)容易陷入一個(gè)誤區(qū)想用一個(gè)大而全的工具搞定所有問(wèn)題。我試過(guò)幾個(gè)商業(yè)SaaS方案功能確實(shí)強(qiáng)但最終都卡在了數(shù)據(jù)和成本上。所以選型時(shí)定了幾條原則必須是開(kāi)源可自托管的、必須能對(duì)接現(xiàn)有代碼托管平臺(tái)、必須允許通過(guò)代碼定義規(guī)則。在這個(gè)原則下open-code-review 的核心組件如下需求主力工具備選方案選擇理由審查評(píng)論統(tǒng)一出口ReviewDog自研API腳本支持GitHub/GitLab/Gitea能在MR對(duì)應(yīng)行貼評(píng)論多種reporter可切換靜態(tài)質(zhì)量與趨勢(shì)SonarQubeCodeQL、Semgrep自托管部署成熟質(zhì)量門(mén)禁和趨勢(shì)圖完善團(tuán)隊(duì)自定義規(guī)則Danger JS自寫(xiě)CI腳本用JS/TS寫(xiě)規(guī)則團(tuán)隊(duì)上手成本低和Node技術(shù)棧貼合代碼格式統(tǒng)一Prettier ESLintStandardJS生態(tài)成熟配置靈活可按團(tuán)隊(duì)習(xí)慣定制MR流程規(guī)范GitLab CI / 模板腳本鉤子CI觸發(fā)維度多可以精準(zhǔn)控制只在MR事件時(shí)跑審查ReviewDog 的選擇值得多說(shuō)一句。它的關(guān)鍵能力是把靜態(tài)分析工具的輸出轉(zhuǎn)換成MR上的行級(jí)評(píng)論比如ESLint報(bào)了個(gè)錯(cuò)誤ReviewDog會(huì)自動(dòng)把評(píng)論貼到對(duì)應(yīng)的代碼行旁邊。這個(gè)體驗(yàn)上的提升極其重要審查者不用再打開(kāi)日志文件逐個(gè)位置去對(duì)開(kāi)發(fā)者也能在熟悉的MR界面直接回應(yīng)。SonarQube 的價(jià)值在于歷史視角。單次掃描只能告訴你這次有多少個(gè)問(wèn)題而SonarQube能展示問(wèn)題數(shù)是上升還是下降哪個(gè)模塊是重災(zāi)區(qū)。質(zhì)量門(mén)禁直接和CI結(jié)果掛鉤不達(dá)標(biāo)就不給合并這個(gè)硬約束讓代碼質(zhì)量從“彈性指標(biāo)”變成了“強(qiáng)制門(mén)檻”。至于為什么沒(méi)用更復(fù)雜的AI代碼審查做主力我的觀(guān)點(diǎn)是AI現(xiàn)階段適合做輔助提示不適合做硬性門(mén)禁。誤報(bào)太多會(huì)觸發(fā)“狼來(lái)了”效應(yīng)讓團(tuán)隊(duì)對(duì)審查結(jié)果麻木。open-code-review 里給AI留了一個(gè)可選接入位但它不在默認(rèn)的失敗條件中更像一個(gè)“增值評(píng)審員”。3. 落地實(shí)操?gòu)牧愦罱ㄒ惶卓捎玫膶彶榄h(huán)境3.1 環(huán)境準(zhǔn)備一臺(tái)服務(wù)器和一套Docker編排open-code-review 對(duì)硬件的要求不高代碼倉(cāng)庫(kù)規(guī)模不大時(shí)一臺(tái)2核4G的服務(wù)器就跑得動(dòng)整套服務(wù)。如果倉(cāng)庫(kù)很大、提交很頻繁建議到4核8G主要瓶頸在SonarQube的JVM進(jìn)程和分析任務(wù)上。以下部署方式基于Docker Compose這也是目前維護(hù)成本最低的方式。準(zhǔn)備階段要做三件事裝好Docker和Compose、準(zhǔn)備一個(gè)代碼托管平臺(tái)的賬號(hào)令牌、規(guī)劃好存儲(chǔ)目錄。令牌建議用機(jī)器人賬號(hào)申請(qǐng)權(quán)限只需要讀取倉(cāng)庫(kù)和提交流水線(xiàn)評(píng)論這一檔不要用個(gè)人賬號(hào)的完整令牌避免權(quán)限過(guò)大。docker-compose.yml 大概長(zhǎng)這樣核心就是SonarQube加上PostgreSQL其他組件都跑在CI里不常駐version: 3.8 services: postgres: image: postgres:15 environment: POSTGRES_USER: sonar POSTGRES_PASSWORD: sonar_pass POSTGRES_DB: sonar volumes: - sonar_pg:/var/lib/postgresql/data restart: unless-stopped sonarqube: image: sonarqube:10.5-community container_name: sonarqube depends_on: - postgres environment: SONAR_JDBC_URL: jdbc:postgresql://postgres:5432/sonar SONAR_JDBC_USERNAME: sonar SONAR_JDBC_PASSWORD: sonar_pass ports: - 9000:9000 volumes: - sonar_data:/opt/sonarqube/data - sonar_logs:/opt/sonarqube/logs restart: unless-stopped volumes: sonar_pg: sonar_data: sonar_logs:啟動(dòng)之后瀏覽器訪(fǎng)問(wèn)服務(wù)IP的9000端口用默認(rèn)賬號(hào) admin/admin 登錄第一時(shí)間改掉默認(rèn)密碼。接著在SonarQube里創(chuàng)建一個(gè)項(xiàng)目拿到項(xiàng)目的project key和token這兩個(gè)值后面配置CI任務(wù)時(shí)要用到。這里有個(gè)小經(jīng)驗(yàn)PostgreSQL 的數(shù)據(jù)目錄一定要掛到宿主機(jī)卷里否則容器一重建所有掃描歷史全部清零質(zhì)量趨勢(shì)圖表直接變成一張白紙。我第一次部署就因?yàn)橥祽袥](méi)掛卷升級(jí)容器版本時(shí)把半年的歷史數(shù)據(jù)全弄丟了只能重頭積累。3.2 規(guī)則配置讓審查器學(xué)會(huì)團(tuán)隊(duì)的習(xí)慣環(huán)境起來(lái)之后最難也最花時(shí)間的環(huán)節(jié)是規(guī)則配置。很多團(tuán)隊(duì)在第一步就翻車(chē)原因是把規(guī)則集直接設(shè)為“全家桶”所有插件全開(kāi)于是第一次掃描冒出來(lái)幾千個(gè)問(wèn)題看著就泄氣項(xiàng)目直接被放棄了。正確的姿勢(shì)是“先收斂再放權(quán)”。第一版配置只開(kāi)最重要、最沒(méi)有爭(zhēng)議的規(guī)則控制在團(tuán)隊(duì)一天能清理完的范圍內(nèi)。跑幾天等存量問(wèn)題清得差不多再逐步放開(kāi)更多規(guī)則。這個(gè)過(guò)程本質(zhì)上是在和團(tuán)隊(duì)約定“什么是好代碼”的基線(xiàn)基線(xiàn)定得越低規(guī)則的公信力就越容易建立。ESLint配置我一般長(zhǎng)這樣核心是繼承推薦的規(guī)則集再針對(duì)團(tuán)隊(duì)歷史問(wèn)題追加少數(shù)規(guī)則{ root: true, extends: [ eslint:recommended, plugin:typescript-eslint/recommended, prettier ], parser: typescript-eslint/parser, plugins: [typescript-eslint], rules: { no-console: warn, typescript-eslint/no-explicit-any: warn, typescript-eslint/explicit-function-return-type: off }, ignorePatterns: [dist/, node_modules/, coverage/] }no-console設(shè)成 warn 而不是 error是因?yàn)殚_(kāi)發(fā)調(diào)試確實(shí)需要日志直接禁掉只會(huì)逼著大家寫(xiě)一個(gè)繞過(guò)規(guī)則的 debug 函數(shù)。explicit-function-return-type直接 off這種規(guī)則對(duì)業(yè)務(wù)代碼的收益很低開(kāi)著只會(huì)制造噪音。規(guī)則配置的核心不是越多越好而是每條規(guī)則都要經(jīng)得起“這條能攔下什么真實(shí)問(wèn)題”的追問(wèn)。SonarQube側(cè)的重點(diǎn)是質(zhì)量門(mén)禁。我通常建議設(shè)置四個(gè)維度新增代碼覆蓋率不低于80%、新增Bug數(shù)量為0、新增安全漏洞為0、新增Code Smell級(jí)別不高于A(yíng)。覆蓋率的門(mén)檻看團(tuán)隊(duì)基礎(chǔ)如果項(xiàng)目剛起步測(cè)試很少可以先定60%再逐步往上提。關(guān)鍵是把“增量”設(shè)為目標(biāo)存量垃圾可以慢慢還新增的必須達(dá)標(biāo)這樣團(tuán)隊(duì)不會(huì)產(chǎn)生對(duì)抗情緒。Danger JS的規(guī)則則完全是團(tuán)隊(duì)自定義的“流程紅綠燈”。下面是我常用的dangerfile片段import { danger, fail, warn } from danger const modifiedFiles danger.git.modified_files const createdFiles danger.git.created_files const changedFiles [...modifiedFiles, ...createdFiles] if (changedFiles.length 30) { warn(這個(gè)MR改動(dòng)的文件超過(guò)30個(gè)建議拆分成多個(gè)小PR否則審查質(zhì)量很難保證) } if (danger.git.diff.includes(FIXME) || danger.git.diff.includes(HACK)) { fail(禁止將FIXME/HACK標(biāo)記隨代碼合入主干請(qǐng)先處理或關(guān)聯(lián)跟蹤issue) } const titleRegex /^(feat|fix|docs|refactor|test|chore)(\(.\))?:/ if (!titleRegex.test(danger.github.pr.title)) { fail(PR標(biāo)題不符合約定格式例如 feat(user): 增加用戶(hù)注冊(cè)接口) }這三條規(guī)則分別約束了改動(dòng)規(guī)模、代碼遺留標(biāo)記、提交規(guī)范。注意力的度需要拿捏我見(jiàn)過(guò)有人把規(guī)則寫(xiě)得極其嚴(yán)格從縮進(jìn)到空行全管結(jié)果開(kāi)發(fā)提PR頻繁被機(jī)器人打回怨聲載道。Danger規(guī)則的設(shè)計(jì)原則是“只攔會(huì)導(dǎo)致返工或線(xiàn)上風(fēng)險(xiǎn)的問(wèn)題”風(fēng)格問(wèn)題讓Linter去管這里只管流程和倉(cāng)庫(kù)衛(wèi)生。3.3 接入CI讓每一次提交都被自動(dòng)審查規(guī)則配好之后所有能力要串到CI流水線(xiàn)里才能真正產(chǎn)生約束力。我以GitLab CI為例GitHub用戶(hù)思路完全一樣把reporter參數(shù)從gitlab-mr-discussion換成github-pr-review即可。下面是.gitlab-ci.yml的核心片段stages: - verify code-review: stage: verify image: node:18-slim rules: - if: $CI_PIPELINE_SOURCE merge_request_event before_script: - npm ci script: - npx eslint src --format checkstyle eslint_report.xml || true - REVIEWDOG_GITLAB_API_TOKEN$REVIEWDOG_TOKEN reviewdog -fcheckstyle -nameeslint -reportergitlab-mr-discussion -levelwarn - npx danger ci variables: REVIEWDOG_GITLAB_API_TOKEN: sonar-scan: stage: verify image: sonarsource/sonar-scanner-cli:10 rules: - if: $CI_PIPELINE_SOURCE merge_request_event script: - sonar-scanner -Dsonar.projectKeymy_project -Dsonar.sourcessrc -Dsonar.host.urlhttp://your-server:9000 -Dsonar.token$SONAR_TOKEN -Dsonar.pullrequest.key$CI_MERGE_REQUEST_IID -Dsonar.pullrequest.branch$CI_MERGE_REQUEST_SOURCE_BRANCH_NAME -Dsonar.pullrequest.base$CI_MERGE_REQUEST_TARGET_BRANCH_NAME有兩個(gè)細(xì)節(jié)值得展開(kāi)。第一ESLint命令末尾加了|| true這是為了避免ESLint發(fā)現(xiàn)錯(cuò)誤以非零狀態(tài)退出導(dǎo)致后續(xù)ReviewDog還沒(méi)來(lái)得及把問(wèn)題貼到MR上流水線(xiàn)就停了。真正攔截合并的動(dòng)作放在SonarQube質(zhì)量門(mén)禁上ReviewDog負(fù)責(zé)“把問(wèn)題展示給人看”兩者分工不同。第二ReviewDog只對(duì)diff涉及的行發(fā)表評(píng)論不會(huì)把整個(gè)倉(cāng)庫(kù)的歷史問(wèn)題全部刷到當(dāng)前MR里這個(gè)行為由工具自動(dòng)處理但前提是給SonarQube傳了pullrequest相關(guān)的參數(shù)它才知道要按MR范圍做增量分析。這里再補(bǔ)一句關(guān)于評(píng)價(jià)標(biāo)準(zhǔn)的經(jīng)驗(yàn)自動(dòng)化審查的最終目標(biāo)是把CI變成一條“有觀(guān)點(diǎn)、可解釋、不煩躁”的流水線(xiàn)。我見(jiàn)過(guò)同行把門(mén)禁配到極致任何警告都不放過(guò)結(jié)果團(tuán)隊(duì)每天花大量時(shí)間跟機(jī)器人搏斗真正的設(shè)計(jì)討論反而變少了。工具是服務(wù)人的不是給開(kāi)發(fā)流程添堵的這個(gè)底線(xiàn)要守住。4. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄4.1 審查結(jié)果沒(méi)人看了誤報(bào)率太高這是open-code-review落地過(guò)程中遇到最多的一個(gè)問(wèn)題。第一周大家還會(huì)點(diǎn)開(kāi)ReviewDog的評(píng)論看看第二周開(kāi)始直接把MR頁(yè)面的機(jī)器人評(píng)論折疊因?yàn)闄C(jī)器人說(shuō)的十句話(huà)里有八句是廢話(huà)。排查思路很明確把告警按照“嚴(yán)重級(jí)別”和“是否會(huì)影響線(xiàn)上行為”兩個(gè)維度重新排隊(duì)。級(jí)別為error的問(wèn)題保留在門(mén)禁里warn級(jí)別的問(wèn)題要么刪掉規(guī)則要么存到一個(gè)獨(dú)立的整理清單里不要在MR評(píng)論里刷屏。同時(shí)開(kāi)啟白名單機(jī)制對(duì)第三方SDK的調(diào)用、自動(dòng)生成的代碼目錄直接跳過(guò)檢查這些位置的告警沒(méi)有可操作性報(bào)出來(lái)只會(huì)消耗信任。我給團(tuán)隊(duì)的規(guī)矩是一條審查規(guī)則如果在兩周內(nèi)沒(méi)有攔下任何真實(shí)問(wèn)題那么它就屬于無(wú)效噪音必須下線(xiàn)。工具和團(tuán)隊(duì)之間需要不斷做“信任校準(zhǔn)”只有機(jī)器每次說(shuō)話(huà)都靠譜大家下一次才會(huì)認(rèn)真看評(píng)論。4.2 CI任務(wù)超時(shí)流水線(xiàn)卡成蝸牛接入自動(dòng)化審查之后最直接的問(wèn)題是流水線(xiàn)變慢了。SonarQube全量掃描一個(gè)中等規(guī)模的前端項(xiàng)目首次跑可能要十幾分鐘后續(xù)有增量緩存會(huì)快一些但對(duì)“每次提交十幾分鐘”的體驗(yàn)團(tuán)隊(duì)很難接受尤其是在冒煙測(cè)試、單元測(cè)試都要排隊(duì)跑的階段。解決辦法是拆分觸發(fā)粒度。ESLint和Danger這種輕量任務(wù)每次MR更新都跑它們是秒級(jí)的SonarQube做兩檔處理merge request事件下只對(duì)增量代碼做分析并配置在后臺(tái)執(zhí)行不阻塞流水線(xiàn)commit到主干時(shí)再做一次完整掃描用于更新質(zhì)量趨勢(shì)。另外給SonarQube的JVM堆內(nèi)存調(diào)大一些默認(rèn)配置偏保守2核4G服務(wù)器上建議至少把SONAR_RUNTIME_OPTS里的-Xmx調(diào)到2GB以上分析速度提升明顯。時(shí)間規(guī)劃上還有個(gè)技巧把單元測(cè)試和代碼審查放到同一個(gè)階段并行跑而不是串行排隊(duì)。GitLab CI里只要不聲明needs依賴(lài)同階段的job默認(rèn)并行執(zhí)行總時(shí)長(zhǎng)只取決于最慢的那個(gè)任務(wù)而不是所有任務(wù)的和。4.3 制度很完美團(tuán)隊(duì)就是不執(zhí)行工具層面全部跑通之后真正決定這套方案成敗的是團(tuán)隊(duì)習(xí)慣的遷移。一開(kāi)始推進(jìn)時(shí)我的做法是把審查結(jié)果直接納入MR合并的硬性條件SonarQube質(zhì)量門(mén)禁不通過(guò)點(diǎn)不了合并按鈕Danger規(guī)則報(bào)錯(cuò)流水線(xiàn)紅叉掛著。這個(gè)硬約束把“可做可不做”變成了“不做就發(fā)不了版”。但硬約束不能解決所有問(wèn)題還會(huì)引發(fā)逆反心理。我同步做了一件事把代碼審查的反饋閉環(huán)縮短。任何人提交MR后機(jī)器人幾分鐘內(nèi)給出問(wèn)題列表人工review在一個(gè)工作日內(nèi)完成。意見(jiàn)太多時(shí)允許先合并再補(bǔ)齊技術(shù)債但必須關(guān)聯(lián)一個(gè)跟蹤issue。這樣既保住了發(fā)版節(jié)奏又沒(méi)有把質(zhì)量問(wèn)題變成不可見(jiàn)的歷史賬。還有一個(gè)小技巧是“機(jī)器人先說(shuō)話(huà)”。在MR描述里固定讓機(jī)器人貼一段自動(dòng)生成的質(zhì)量摘要包括改動(dòng)文件數(shù)、新增問(wèn)題數(shù)、覆蓋率變化、是否有遺留標(biāo)記。質(zhì)量信息在人類(lèi)評(píng)審開(kāi)始之前就展示出來(lái)開(kāi)發(fā)者在等評(píng)審的空檔期就會(huì)自己先把低級(jí)問(wèn)題清掉后面人看的時(shí)候自然輕松很多。4.4 常見(jiàn)問(wèn)題速查表現(xiàn)象可能原因排查思路解決建議ReviewDog沒(méi)有在MR評(píng)論API Token權(quán)限不足或reporter參數(shù)寫(xiě)錯(cuò)先本地手動(dòng)跑一次reviewdog看是否能正常獲取diff檢查token權(quán)限是否含api確認(rèn)CI環(huán)境的CI_MERGE_REQUEST_IID存在SonarQube掃描結(jié)果為空project key或source路徑配置錯(cuò)誤查看CI job原始日志中的報(bào)錯(cuò)逐項(xiàng)核對(duì)sonar.projectKey、sonar.sources、sonar.token質(zhì)量門(mén)禁一堆存量問(wèn)題沒(méi)有區(qū)分新增和全部在SonarQube項(xiàng)目配置里查看New Code定義把Leak Period設(shè)置為“上次版本迭代”只考核增量代碼Danger一直沒(méi)有輸出dangerfile語(yǔ)法錯(cuò)誤或觸發(fā)條件不符本地執(zhí)行npx danger ci --text-only驗(yàn)證檢查rules條件里的事件類(lèi)型確保MR事件傳入流水線(xiàn)過(guò)慢SonarQube執(zhí)行全量分析查看SonarQube日志分析耗時(shí)改為MR只做增量分析主干才做全量掃描并行跑各job團(tuán)隊(duì)不點(diǎn)機(jī)器人評(píng)論評(píng)論太多太碎全是低價(jià)值信息統(tǒng)計(jì)一下機(jī)器人評(píng)論的類(lèi)型分布收斂規(guī)則集把無(wú)害告警轉(zhuǎn)為靜默聚合只在門(mén)禁攔截時(shí)上報(bào)5. 寫(xiě)在最后的個(gè)人體會(huì)open-code-review 這套方案做下來(lái)我最大的體會(huì)是代碼審查工具化不是要取代人的判斷而是要把人的判斷力留給真正難的問(wèn)題。機(jī)器擅長(zhǎng)的是在幾千行代碼里穩(wěn)定地、無(wú)情緒地篩出符合或違反規(guī)則的那一列而團(tuán)隊(duì)真正需要的是在MR被淹沒(méi)之前讓一個(gè)人能專(zhuān)注地回答“這個(gè)方案到底行不行”。最后分享一個(gè)小處理我在最后一道人工審查環(huán)節(jié)里始終保留一個(gè)開(kāi)放問(wèn)題——請(qǐng)?jiān)u審者給出至少一條可執(zhí)行的建設(shè)性意見(jiàn)而不是簡(jiǎn)單回復(fù)“通過(guò)”。如果所有人都覺(jué)得代碼完美那大概率是審查沒(méi)有深入。這個(gè)要求沒(méi)辦法靠機(jī)器人強(qiáng)制執(zhí)行但當(dāng)我們把審查變成一種習(xí)慣而不是一種任務(wù)時(shí)團(tuán)隊(duì)的代碼底座會(huì)越來(lái)越穩(wěn)。后續(xù)你可以在自己的技術(shù)棧里繼續(xù)擴(kuò)展這套方案比如接入更多語(yǔ)言的Linter、把審查規(guī)則做成npm包在多個(gè)項(xiàng)目間共享、甚至在倉(cāng)庫(kù)內(nèi)沉淀一份“歷史踩坑手冊(cè)”供新人快速建立上下文。技術(shù)工具會(huì)換代但“先機(jī)器篩查、再人審重點(diǎn)”的思路放在任何團(tuán)隊(duì)都值得一試。