寫代碼這么多年我一直覺得 code review 是最能體現(xiàn)團(tuán)隊技術(shù)氛圍的一件事。代碼寫得好不好review 別人代碼時一針見血說明你對自己寫的東西有沒有深入思考過。但現(xiàn)實很骨感項目趕進(jìn)度的時候Review 往往是最先被犧牲的環(huán)節(jié)。我見過太多團(tuán)隊嘴上說一定要 review實際合并請求掛了兩三天沒人看或者 Reviewer 只回一句LGTM就合進(jìn)去了。這些場景背后都是同一個問題人肉 review 的成本和效果不成正比。于是我開始折騰自動代碼審查測試過好幾款商業(yè)工具和開源項目也在 CI 里折騰過各種靜態(tài)掃描方案。今天想聊的是我目前在用的一個開源項目叫open-code-review。它不是那種玄乎的 AI 魔法也不是單純的 linter而是把靜態(tài)分析、規(guī)則引擎和代碼托管平臺的交互串起來的一套自動化審查工具。說白了它就是幫你把代碼審查里那些重復(fù)性、機(jī)械性的部分交給機(jī)器讓人把精力聚焦在真正需要判斷力的地方。這篇文章會從項目設(shè)計的思路聊起講清楚它內(nèi)部的規(guī)則機(jī)制、接入方式、在 GitLab/GitHub 上的實戰(zhàn)效果以及我踩過的一些坑。如果你正在糾結(jié)要不要給團(tuán)隊上自動代碼審查用現(xiàn)成的商業(yè)版還是自己搭這篇應(yīng)該能給你一個比較完整的參考。1. 項目整體設(shè)計與思路拆解1.1 代碼審查的痛點到底在哪先說個我觀察到的現(xiàn)象。很多團(tuán)隊并非不想做代碼審查而是Review的過程有天然的結(jié)構(gòu)性問題。第一個痛點是時效性。一個合并請求提出之后早上的代碼下午才有人看下午的代碼第二天才有人回應(yīng)等到所有討論結(jié)束分支可能已經(jīng)落后主分支幾十個提交了。這個時間差會導(dǎo)致兩個后果一是 Reviewer 需要在腦子里重新理解一次上下文二是開發(fā)者會傾向于在 review 期間繼續(xù)堆代碼最后合并請求膨脹到幾百行連作者自己都不想看。第二個痛點是注意力分配。人腦在檢查代碼時真正有價值的其實是這段邏輯對不對這個設(shè)計是否合理這種高層次的判斷。但現(xiàn)實中大部分 review 討論消耗在了這里空行多了這個變量命名不規(guī)范為什么不用現(xiàn)成的工具函數(shù)這類機(jī)械問題上。不是說這些問題不重要但它們完全不需要一個資深工程師花時間去盯。第三個痛點是標(biāo)準(zhǔn)不一致。同一個團(tuán)隊里有的人對代碼風(fēng)格極其敏感有的人只關(guān)心功能是否正確。一個文件經(jīng)過不同人 review得到的反饋風(fēng)格可能完全不一樣這在團(tuán)隊規(guī)范尚未沉淀成文檔的初創(chuàng)團(tuán)隊里尤其明顯。open-code-review 想解決的就是后面這兩類問題把機(jī)械檢查自動化把標(biāo)準(zhǔn)統(tǒng)一固化進(jìn)規(guī)則引擎同時用機(jī)器評論的方式跟人工 review 形成互補而不是取代。1.2 這個項目到底做了什么從項目命名就能看出來它的核心是開放——規(guī)則可配置、流程可接入、平臺可擴(kuò)展。我實際用下來它的定位介于傳統(tǒng) linter 和商業(yè)智能審查工具之間。傳統(tǒng) linter 比如 ESLint、Pylint 這類只管單個文件范圍內(nèi)的語法和風(fēng)格問題它們跑在本地或 CI 里輸出一份報告就完事了。它們不懂哪個提交改了哪些文件這種版本上下文也不會主動去對應(yīng)平臺里發(fā)評論。商業(yè)智能審查工具一般集成度高、開箱即用但規(guī)則是黑盒出了問題你很難定位它為什么報這一條而且價格對中小團(tuán)隊不太友好。open-code-review 走的是中間路線。它會讀取合并請求的變更內(nèi)容在變更的代碼上做分析然后以機(jī)器人的身份把問題直接作為評論發(fā)到對應(yīng)的代碼行上。整個過程的規(guī)則完全暴露給你你可以看到每條檢查項是依據(jù)什么邏輯觸發(fā)的也可以隨時調(diào)整閾值和開關(guān)。具體來說這個項目的核心模塊包括變更提取模塊對接代碼托管平臺 API拉取合并請求的 diff 數(shù)據(jù)規(guī)則引擎內(nèi)置一批開箱即用的檢查規(guī)則同時支持自定義規(guī)則配置評論發(fā)送模塊把審查結(jié)果按文件按行寫入評論區(qū)報告生成模塊輸出一份整體的審查摘要便于在 CI 日志里查看我之前在幾個內(nèi)部項目里接入了一輪整體感受是輕容器鏡像很小配置文件是 YAML塞進(jìn) GitLab CI 或者 GitHub Actions 里只要十幾分鐘就能跑完首輪。1.3 為什么推薦組合式架構(gòu)而不是一個腳本搞定剛開始我也想得很簡單寫個 Python 腳本拉 diff然后調(diào)一段規(guī)則判斷最后 POST 評論到 API。聽起來半天就能搞定。但真正做起來會發(fā)現(xiàn)一個問題這個腳本會越寫越復(fù)雜。一開始只是檢查新增代碼里有沒有 TODO 標(biāo)記后來想加禁止直接在生產(chǎn)代碼里使用 console.log再后來想加文件是否超過 500 行是否有重復(fù)度高的相似代碼段每個需求都是獨立維度如果全寫在一個大腳本里最終的維護(hù)成本會高到你想重寫。open-code-review 的架構(gòu)思路是把這些能力拆成模塊規(guī)則之間解耦。每條規(guī)則只負(fù)責(zé)一件事輸入是某個文件的某一行或某一段代碼輸出是一條或零條問題記錄。這樣新增規(guī)則的時候不需要動其他代碼只需要往規(guī)則目錄里放一個文件并在配置文件里聲明啟用即可。這也是我想給所有準(zhǔn)備折騰類似工具的人一個建議任何自動化審查工具的架構(gòu)都應(yīng)該按照數(shù)據(jù)采集、分析判斷、結(jié)果回寫三層去設(shè)計。分層越清晰后面加功能越省力。2. 核心細(xì)節(jié)解析與實操要點2.1 規(guī)則引擎的設(shè)計思路與典型規(guī)則規(guī)則引擎是整個項目的核心也是我最喜歡研究的部分。它內(nèi)置了幾類規(guī)則我分別說一下它們的檢查邏輯。第一類是關(guān)鍵詞掃描規(guī)則。比如在代碼里搜索TODO、FIXME、HACK這些標(biāo)記它們往往意味著開發(fā)者留下了一個未完成的事務(wù)。這個掃描不是簡單地在整個文件里找字符串而是只針對本次變更新增的行做匹配所以不會把歷史上遺留的 TODO 全都報一遍只會提示你這次新增的代碼里又引入了新的 TODO請確認(rèn)是否合理。第二類是編碼規(guī)范規(guī)則。以 Python 項目為例它會檢查新增代碼里的命名風(fēng)格比如函數(shù)名是不是小寫下劃線、類名是不是駝峰式也會檢查常見的函數(shù)參數(shù)長度超過閾值單行代碼過長這類問題。這類規(guī)則跟 PyLint 有重疊但它的優(yōu)勢是能站在 diff 的粒度上工作只提示變化的部分不會把整個項目的存量問題一次性拋給你。第三類是安全隱患規(guī)則。比如檢測代碼里是否拼接了 SQL 語句而非使用參數(shù)化查詢是否在日志里打印了包含password、token、secret等關(guān)鍵字的變量值是否存在把敏感信息硬編碼進(jìn)代碼的嫌疑。這類規(guī)則的價值在于它能在代碼評審之前先替人眼掃一遍最容易出問題的幾個點。第四類是工程結(jié)構(gòu)規(guī)則。檢查單次變更涉及的文件數(shù)量是否過多、單個文件的新增行數(shù)是否過大、是否引入了新的第三方依賴但未更新依賴鎖定文件等等。我自己就在規(guī)則里加過一條禁止在共享公共模塊里直接使用print()輸出調(diào)試信息因為它會污染標(biāo)準(zhǔn)輸出流。用它的規(guī)則配置接口實現(xiàn)起來并不復(fù)雜大致是把這條規(guī)則聲明成匹配函數(shù)名print且調(diào)用點位于特定目錄下的組合條件。2.2 規(guī)則配置文件的要點解析open-code-review 使用 YAML 作為配置格式根目錄下默認(rèn)的配置文件類似這樣project: language: python base_branch: main rules: enabled: - todo_check - forbidden_function_check - large_diff_check - sql_injection_check disabled: [] thresholds: max_added_lines: 250 max_file_count: 10 ignore_paths: - docs/** - tests/test_data/**這里有三個關(guān)鍵概念要理解。第一個是base_branch。它決定了變更的對比基準(zhǔn)差分動作會拿當(dāng)前分支跟這個基準(zhǔn)分支做對比從而得到精確的變更列表。默認(rèn)設(shè)成主干分支名如果你的團(tuán)隊用的是master或者trunk要同步改過來否則提取出來的變更集會跟你預(yù)期完全不一樣。第二個是thresholds閾值配置。max_added_lines: 250的含義是單次變更新增超過 250 行時觸發(fā)提醒。這個值需要根據(jù)團(tuán)隊實際節(jié)奏調(diào)整。如果你們的合并請求普遍在 100 行以內(nèi)設(shè)置成 250 就太寬松了規(guī)則基本不觸發(fā)。反過來如果團(tuán)隊經(jīng)常有大規(guī)模重構(gòu)的合并請求設(shè)得太小會產(chǎn)生大量噪音評論。第三個是ignore_paths忽略規(guī)則。這個非常實用。項目里總有一些不需要審查的目錄比如docs/文檔目錄、tests/test_data/測試數(shù)據(jù)目錄、還有自動生成的代碼。不忽略這些路徑的話每次提交都會在文檔改幾個字時觸發(fā)一堆無關(guān)緊要的評論。2.3 與代碼托管平臺集成的方式作為一個自動代碼審查工具它必須要跟代碼托管平臺深度結(jié)合才有意義。目前它支持 GitHub、GitLab 以及 Gitea 這三類常見的平臺。從實現(xiàn)上看集成方式是通過平臺提供的 REST API 完成的。以 GitLab 為例它會讀取合并請求的 iidInternal ID然后調(diào)用項目的 commits API 獲取本次 MR 的所有提交再調(diào)用/compare接口獲取與目標(biāo)分支的 diff 內(nèi)容。拿到 diff 之后逐文件逐行做規(guī)則分析最后通過 note API 把每條問題以評論的形式寫在對應(yīng)代碼行上。這里有個值得注意的技術(shù)細(xì)節(jié)diff 文件里的行號跟實際文件的全局行號不是一回事。diff 格式里每段都有 -l,s l,s 頭部表示舊文件和新文件的起始行號與區(qū)塊長度。如果你直接拿 diff 里的行號去拼評論位置發(fā)到平臺上的評論會掛在不正確的代碼行上這是非常容易踩坑的地方。open-code-review 的處理方法是做一次行號映射解析增量段頭部維護(hù)一個diff 中的行號到實際新文件中的行號的轉(zhuǎn)換表再根據(jù)每條規(guī)則命中的代碼內(nèi)容反向定位。這個過程如果你自己在腳本里實現(xiàn)一定要先寫單測覆蓋各種頭部格式不然不同 diff 風(fēng)格下很容易出現(xiàn)偏移。3. 實操過程與核心環(huán)節(jié)實現(xiàn)3.1 本地運行環(huán)境準(zhǔn)備我先說一下我本地的部署嘗試。項目是用 Go 寫的編譯后是一個單二進(jìn)制文件非常方便在 CI 和本地之間復(fù)用。為了不污染開發(fā)環(huán)境我直接用 Docker 跑了一次驗證git clone https://github.com/example/open-code-review.git cd open-code-review docker build -t open-code-review:local .鏡像構(gòu)建完成后需要準(zhǔn)備一個包含平臺訪問令牌的環(huán)境變量文件。以 GitLab 為例你需要生成一個具備api權(quán)限的 Personal Access Tokenexport OCR_GITLAB_URLhttps://gitlab.example.com export OCR_GITLAB_TOKENglpat-xxxxxxx export OCR_GITLAB_PROJECT_ID42 export OCR_MR_IID15然后在項目倉庫根目錄創(chuàng)建.open-code-review.yaml配置文件并執(zhí)行docker run --rm \ -e OCR_GITLAB_URL \ -e OCR_GITLAB_TOKEN \ -e OCR_GITLAB_PROJECT_ID \ -e OCR_MR_IID \ -v $(pwd)/.open-code-review.yaml:/config.yaml \ open-code-review:local --config /config.yaml這里我重點解釋一下為什么要以環(huán)境變量的方式傳項目標(biāo)識而不是寫在配置里。因為在實際場景里同一個配置文件要復(fù)用到多個項目倉庫中如果項目標(biāo)識寫死在 YAML 里每個團(tuán)隊都要復(fù)制一份配置文件。用環(huán)境變量注入后配置文件可以沉淀為團(tuán)隊模板。3.2 GitLab CI 接入配置實戰(zhàn)本地運行驗證通過之后就可以把工具接到 GitLab CI 里了。我推薦的做法是把它做成流水線里的一個獨立階段放在測試階段之前這樣可以盡早發(fā)現(xiàn)問題。下面是一段我實際使用的.gitlab-ci.yml配置整理出來供參考code-review: stage: review image: docker:latest variables: DOCKER_DRIVER: overlay2 services: - docker:dind script: - docker build -t open-code-review . - docker run --rm -e OCR_GITLAB_URL${CI_SERVER_URL} -e OCR_GITLAB_TOKEN${GITLAB_TOKEN} -e OCR_GITLAB_PROJECT_ID${CI_PROJECT_ID} -e OCR_MR_IID${CI_MERGE_REQUEST_IID} -v ${CI_PROJECT_DIR}/.open-code-review.yaml:/config.yaml open-code-review --config /config.yaml only: - merge_requests有幾個地方需要特別說明。第一CI_MERGE_REQUEST_IID這個變量只有流水線由合并請求事件觸發(fā)時才會被賦值。如果你手動執(zhí)行流水線或者流水線是在分支提交時跑的這個變量會是空字符串工具會因為拿不到 MR 編號而退出。所以別忘記在only里限制merge_requests事件這是很多初用者最容易忽略的一步。第二GITLAB_TOKEN需要你在 GitLab 的 CI/CD Variables 里配置Scope 選Masked保護(hù)一下。注意不要把它寫在代碼倉庫的配置文件里任何一個能看倉庫內(nèi)容的人都能把它提取出來。第三用docker:dind服務(wù)來支持 Docker 構(gòu)建是一種比較重的方案。如果你的 GitLab Runner 已經(jīng)配置了 shell executor建議直接先把二進(jìn)制編譯好做成項目公共鏡像然后在流水線里用image: open-code-review:1.2.0直接引用這樣每次跑流水線就不用重復(fù)構(gòu)建速度會快很多。3.3 GitHub Actions 接入方式更簡單如果你們工作流在 GitHub 上接入會更順滑。GitHub Actions 對這類在 PR 上發(fā)評論的工具支持極好核心原因是它內(nèi)置了GITHUB_TOKEN和豐富的 events 上下文。name: open-code-review on: pull_request: types: [opened, synchronize] permissions: contents: read pull-requests: write jobs: review: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 with: fetch-depth: 0 - name: Run open-code-review uses: your-org/open-code-review-actionv1 env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} with: config: .open-code-review.yaml我一開始接入時沒有寫fetch-depth: 0這個參數(shù)結(jié)果吃了大虧。工具分析 diff 需要訪問完整的main分支歷史而默認(rèn) checkout 只拉取當(dāng)前 PR 的最新代碼和最小歷史最終導(dǎo)致對比結(jié)果錯亂工具報了一堆莫名其妙的錯誤位置。還有一點permissions里的pull-requests: write是必須顯式聲明的。GitHub 從 2023 年起收緊了GITHUB_TOKEN的默認(rèn)權(quán)限如果不聲明機(jī)器人發(fā)的評論會被拒絕報 403 錯誤。這些都屬于開始跑起來才會發(fā)現(xiàn)的問題我放在后面的排查清單里詳細(xì)展開。3.4 從零配置一套自定義審查規(guī)則除了內(nèi)置規(guī)則open-code-review 還支持自定義規(guī)則。對團(tuán)隊來說這個過程其實是把團(tuán)隊約定沉淀成自動化檢查的好機(jī)會。這個項目提供了基于 JSON Path 的自定義規(guī)則接口比如我想檢查項目內(nèi)是否禁止直接調(diào)用requests.get()而必須走統(tǒng)一封裝的 HTTP 客戶端我可以寫一條自定義規(guī)則custom_rules: - name: no_direct_requests_get message: 請使用項目的 http_client 封裝發(fā)起網(wǎng)絡(luò)請求不要直接調(diào)用 requests.get severity: warning match: language: python expr: | Call(attrAttribute(attrName(idget), valueName(idrequests)))這里的expr用的是類似 AST 匹配的模式它能把代碼解析成抽象語法樹之后做結(jié)構(gòu)化匹配而不是簡單的文本搜索。這意味著你不用擔(dān)心注釋里寫著requests.get被誤傷也不用擔(dān)心字符串類型里包含同樣內(nèi)容被誤判。這種結(jié)構(gòu)級匹配比正則表達(dá)式可靠得多也是它作為審查工具比較專業(yè)的地方。如果你之前只寫過簡單的grep式檢查剛開始用 AST 匹配會有學(xué)習(xí)成本但一旦熟悉了就會發(fā)現(xiàn)它的表達(dá)能力和準(zhǔn)確性上了一個臺階。4. 常見問題與排查技巧實錄4.1 評論位置錯亂最常見的坑我第一次在真實項目里啟用 open-code-review 時遇到的最大問題是評論位置不對。比如新增了 10 行代碼理論上規(guī)則命中應(yīng)該定位在第 8 行的位置結(jié)果評論掛在了第 3 行有的甚至跑到了文件的頭部。排查了一圈發(fā)現(xiàn)問題出在 diff 的解析上。在 GitLab 的完整 diff 響應(yīng)中new_line和new_lines字段的值不是連續(xù)的因為在變更塊中間可能夾雜著上下文行和平臺自身的標(biāo)記。比如一個文件新增了 20 行但 diff 響應(yīng)中出現(xiàn)的new_line可能是[1, 2, 3, 10, 11, 12, 13, 14]這種不連續(xù)的序列因為它只包含有內(nèi)容變化的行不包含變更塊前后的上下文。如果你直接拿命中規(guī)則的 diff 索引去當(dāng)作行號用一定會錯位。open-code-review 內(nèi)部是先用變更塊頭部的 -l,s l,s 建立映射然后逐行累加偏移量確保每條評論的落點準(zhǔn)確。假如你是自己實現(xiàn)類似的工具建議在解析 diff 階段就建立完整的映射表而不是在規(guī)則分析階段臨時推算。4.2 誤報太多導(dǎo)致團(tuán)隊免疫工具剛上線時最容易出現(xiàn)的問題就是所有人都被機(jī)器人評論轟炸最后大家都免疫了看到機(jī)器人評論就直接忽略審閱體驗反而變得更糟。我自己遇到的誤報來源主要有三類。第一類是規(guī)則閾值設(shè)得太激進(jìn)。比如max_added_lines默認(rèn)閾值設(shè)成 250但團(tuán)隊里很多人習(xí)慣在測試文件里一次性加十幾條用例每用例大約 20 行一次測試提交輕松超過 250 行。對代碼變更來說這完全合理但對測試代碼來說觸發(fā)閾值就是在制造噪音。解決辦法是把測試目錄加入ignore_paths或者針對測試文件降低規(guī)則的觸發(fā)動機(jī)。第二類是命名規(guī)范規(guī)則在 Python 和 JavaScript 混用項目里的沖突。同一個倉庫里后端 Python 代碼用snake_case前端 JS 代碼用camelCase如果規(guī)則沒有區(qū)分語言前端代碼會瘋狂觸發(fā)命名規(guī)則。open-code-review 支持按文件類型應(yīng)用規(guī)則比如rules_overrides: - paths: - frontend/** language: javascript enable_snake_case_check: false enable_camel_case_check: true第三類是約定型的公司內(nèi)部代碼被規(guī)則誤傷。比如我們公司內(nèi)部統(tǒng)一封裝了一個日志組件log內(nèi)部有l(wèi)og.println()之類的調(diào)試方法但有條規(guī)則恰好在檢查 禁止使用 console.log 時把log.println也匹配進(jìn)去了。這個問題最終通過自定義規(guī)則的允許名單解決了?？刂普`報的核心原則跟調(diào)告警閾值一樣要讓每條評論都有足夠高的準(zhǔn)確率。寧可不報一個真實問題也不要報三條里只有一條有用的。團(tuán)隊對工具的信心一旦建立起來后面配合度會高很多。4.3 CI 超時拖慢流水線接入自動代碼審查之后工作流多了一個新環(huán)節(jié)CI 總時間難免會變長。我遇到過一輪改造直接把整個流水線從 6 分鐘拖到了 11 分鐘。問題出在沒有做增量運算。open-code-review 在掃描時默認(rèn)會對每個 MR 做全量文件掃描雖然規(guī)則會過濾掉沒有變更的文件但工具在啟動階段仍然會初始化倉庫的全部內(nèi)容。對于大型 monorepo這個初始化的時間成本相當(dāng)可觀。優(yōu)化方案有兩個。最直接的是在配置里加scan_only_changed_files: true讓工具只對變更文件做規(guī)則檢查。第二個方案是為工具建立增量緩存這次掃描過的文件如果在上次審查后沒有變更直接跳過。GitHub Actions 有actions/cacheGitLab CI 可以對指定目錄做 cache。我用的是第二套方案把緩存目錄放在/tmp/ocr_cache下并用分支名作為 cache key效果很明顯。variables: OCR_CACHE_DIR: /tmp/ocr_cachecache: key: $CI_COMMIT_REF_SLUG paths: - /tmp/ocr_cache4.4 權(quán)限配置不生效還有一次失效發(fā)生在 GitLab 的 Bot 賬號權(quán)限上。我給機(jī)器人賬號開了developer角色按理說可以在 MR 上發(fā)評論。但實際運行時 API 返回 403查日志發(fā)現(xiàn)是創(chuàng)建 note 的接口權(quán)限不足。GitLab 的權(quán)限模型在這里有個細(xì)節(jié)開發(fā)者角色可以去評論 MR但如果 MR 設(shè)置了只有項目成員可以評論并且機(jī)器人賬號不是 MR 的參與者則仍會被拒絕。解決路徑有兩個一是把機(jī)器人賬號提升為 maintainer 角色二是在 MR 級別的設(shè)置里放行機(jī)器人賬號。大多數(shù)團(tuán)隊選擇前者因為機(jī)器人賬號本來就是服務(wù)賬號權(quán)限高一點問題不大。4.5 問題速查表我把踩過的坑整理成了一個速查表方便后續(xù)排查時直接翻閱?，F(xiàn)象常見原因解決動作評論掛在不正確的代碼行上diff 行號映射未轉(zhuǎn)換檢查頭部解析邏輯建立新舊行號映射流水線因工具報錯而失敗在非 merge request 事件觸發(fā)了任務(wù)在 CI 配置里限制only: merge_requestsAPI 返回 403Token 權(quán)限不足或未聲明 write 權(quán)限檢查 Token scope補上pull-requests: write權(quán)限CI 總時間明顯變長全量掃描所有文件開啟scan_only_changed_files配置緩存路徑相同問題被反復(fù)評論MR 反復(fù) push 觸發(fā)多次審查在工具配置里去重邏輯記錄已經(jīng)評論過的消息哈希忽略規(guī)則未生效忽略路徑是目錄但未加通配符確認(rèn)docs/**寫法而不是docs/5. 從工具到流程團(tuán)隊落地的一些心得自動代碼審查工具本質(zhì)上是一種流程基礎(chǔ)設(shè)施它不是一個裝完就完事的獨立軟件需要跟團(tuán)隊已有的開發(fā)節(jié)奏融合。我個人的建議是分階段引入。第一個月先只做告警型規(guī)則比如命名規(guī)范、調(diào)試語句殘留這些低風(fēng)險高確定性的事項。這個階段目的是讓團(tuán)隊熟悉機(jī)器人的存在體會到自動檢查省了我不少事。第二個月再加入偏向安全類的規(guī)則比如 SQL 注入、硬編碼密鑰這類問題這些問題開發(fā)者自己容易忽略但影響面大機(jī)器人提出之后認(rèn)可度會很高。第三個月再考慮加入復(fù)雜度分析、文件規(guī)模檢查這類規(guī)則這類問題比較主觀需要跟團(tuán)隊討論確認(rèn)閾值最好在周會上過一遍示例再統(tǒng)一上線。另外機(jī)器人評論的語氣也值得調(diào)教。我給工具配了一套自定義模板把錯誤改成建議把你改成我們比如建議優(yōu)先使用項目封裝的http_client來做網(wǎng)絡(luò)請求這里直接調(diào)用requests.get雖然能跑通但在超時重試和日志追蹤上會缺失一層統(tǒng)一處理。如果確實需要直接使用麻煩在注釋里說明一下原因。這種語氣比冷冰冰地說禁止使用更容易讓團(tuán)隊成員接受也更符合團(tuán)隊內(nèi)部的技術(shù)氛圍。工具雖然是機(jī)器人但在團(tuán)隊協(xié)作里表達(dá)方式往往決定了反饋被接受的程度。如果你想在自己團(tuán)隊里推進(jìn)自動化代碼審查我建議從最困擾團(tuán)隊的那個具體問題出發(fā)。不必一步到位把全部規(guī)則都配上也不必將它做成阻斷門禁。它更像一個冷靜的代碼執(zhí)筆人在每次合并前幫你把容易疏漏的細(xì)節(jié)再看一遍。代碼審查這件事機(jī)器的歸機(jī)器人的歸人。把重復(fù)勞動交給工具之后真正的 Review 才終于可以把力氣花在這個設(shè)計好不好這個抽象合不合理這些值得花力氣的地方上。希望這篇文章能幫你把團(tuán)隊代碼審查的自動化之路走得更順。