1. 為什么“代碼評(píng)審”這件事值得單獨(dú)造一個(gè)輪子第一次聽到“open-code-review”這個(gè)名字很多人下意識(shí)會(huì)覺得代碼評(píng)審不就是提個(gè) PR、拉幾個(gè)人點(diǎn)個(gè) Approve 嗎GitHub、GitLab 這些平臺(tái)早就內(nèi)置了為什么還要單獨(dú)搞一個(gè)開源項(xiàng)目我一開始也是這個(gè)反應(yīng)。但真正在團(tuán)隊(duì)里帶過十幾人規(guī)模的協(xié)作、經(jīng)歷過“評(píng)審流于形式”之后你會(huì)發(fā)現(xiàn)平臺(tái)自帶的評(píng)審功能解決的是“流程有沒有走完”而不是“代碼到底有沒有被認(rèn)真看過”。這兩件事之間隔著一整個(gè)工程文化。open-code-review 這類項(xiàng)目的核心定位是把代碼評(píng)審從“平臺(tái)的一個(gè)按鈕”變成“一套可自托管、可定制、可沉淀知識(shí)的工作流”。它要解決的真實(shí)痛點(diǎn)有這么幾個(gè)第一評(píng)審意見散落在各個(gè) PR 的評(píng)論區(qū)里過兩個(gè)月沒人記得當(dāng)初為什么這么改第二評(píng)審標(biāo)準(zhǔn)完全靠人腦記憶新人不知道團(tuán)隊(duì)到底在意什么第三評(píng)審數(shù)據(jù)無(wú)法沉淀成團(tuán)隊(duì)資產(chǎn)誰(shuí)評(píng)審質(zhì)量高、哪類問題反復(fù)出現(xiàn)全靠感覺。這套東西適合誰(shuí)來參考我認(rèn)為是三類人一是中小團(tuán)隊(duì)的技術(shù)負(fù)責(zé)人想搭建一套輕量但可控的評(píng)審機(jī)制二是想深入理解代碼評(píng)審工程化的開發(fā)者三是任何對(duì)“協(xié)作工具如何影響團(tuán)隊(duì)行為”這個(gè)話題感興趣的人。我下面會(huì)從整體設(shè)計(jì)思路、核心機(jī)制拆解、落地實(shí)操、問題排查幾個(gè)角度把這類項(xiàng)目講透。需要提前說明的是open-code-review 作為一個(gè)開源項(xiàng)目具體實(shí)現(xiàn)細(xì)節(jié)會(huì)隨版本演進(jìn)我講的是這類工具通用的設(shè)計(jì)邏輯和我在實(shí)際搭建、使用過程中總結(jié)出來的經(jīng)驗(yàn)涉及具體配置的地方你完全可以按自己團(tuán)隊(duì)的實(shí)際情況調(diào)整。2. 整體設(shè)計(jì)思路評(píng)審工具到底該管什么2.1 從“評(píng)審動(dòng)作”到“評(píng)審資產(chǎn)”的思維轉(zhuǎn)變大多數(shù)團(tuán)隊(duì)對(duì)代碼評(píng)審的理解停留在動(dòng)作層面提交代碼、指定評(píng)審人、等待通過、合并。這個(gè)鏈條本身沒問題問題在于它是一次性的。評(píng)審結(jié)束后討論內(nèi)容就沉到 PR 歷史里除非有人專門去翻否則永遠(yuǎn)不會(huì)再被看到。open-code-review 這類項(xiàng)目的設(shè)計(jì)出發(fā)點(diǎn)就是把這個(gè)一次性動(dòng)作變成可積累的資產(chǎn)。具體來說它通常會(huì)把評(píng)審過程拆成幾個(gè)可獨(dú)立管理的維度評(píng)審規(guī)則什么算合格、評(píng)審記錄誰(shuí)在什么時(shí)候提了什么意見、評(píng)審統(tǒng)計(jì)問題分布、響應(yīng)時(shí)長(zhǎng)、通過率。這三個(gè)維度分開管理的好處是規(guī)則可以獨(dú)立演進(jìn)記錄可以獨(dú)立檢索統(tǒng)計(jì)可以獨(dú)立分析。我見過太多團(tuán)隊(duì)把這三樣?xùn)|西全塞進(jìn) PR 評(píng)論里結(jié)果就是規(guī)則沒人維護(hù)、記錄沒人檢索、統(tǒng)計(jì)根本做不了。從工程角度看這種拆分意味著數(shù)據(jù)模型要設(shè)計(jì)得足夠干凈。評(píng)審規(guī)則最好用結(jié)構(gòu)化配置比如 YAML 或 JSON而不是自然語(yǔ)言描述評(píng)審記錄要能關(guān)聯(lián)到具體的代碼行和提交哈希統(tǒng)計(jì)維度要能按人、按模塊、按時(shí)間段聚合。這些設(shè)計(jì)決策看起來是技術(shù)細(xì)節(jié)實(shí)際上直接決定了這套工具能不能真正被團(tuán)隊(duì)用起來。2.2 自托管與可定制為什么不能完全依賴平臺(tái)有人會(huì)問既然平臺(tái)已經(jīng)提供了評(píng)審功能為什么還要自托管一套我的經(jīng)驗(yàn)是平臺(tái)功能是“通用最優(yōu)解”而團(tuán)隊(duì)需要的是“局部最優(yōu)解”。舉個(gè)例子某個(gè)團(tuán)隊(duì)可能規(guī)定所有涉及數(shù)據(jù)庫(kù) schema 變更的代碼必須由 DBA 角色的人評(píng)審但平臺(tái)的角色體系里根本沒有“DBA”這個(gè)評(píng)審維度。再比如有些團(tuán)隊(duì)希望評(píng)審意見能自動(dòng)同步到內(nèi)部知識(shí)庫(kù)平臺(tái)也不會(huì)提供這種集成。open-code-review 這類項(xiàng)目的價(jià)值就在于它把評(píng)審的“控制權(quán)”交還給團(tuán)隊(duì)。你可以定義自己的評(píng)審規(guī)則、自己的角色體系、自己的通知渠道、自己的數(shù)據(jù)存儲(chǔ)方式。這種自由度對(duì)于有特殊流程要求的團(tuán)隊(duì)來說是剛需。當(dāng)然自由度也意味著維護(hù)成本你需要自己部署、自己配置、自己保證可用性。所以我的建議是如果團(tuán)隊(duì)規(guī)模在五人以下平臺(tái)自帶功能基本夠用一旦超過十人或者有明確的合規(guī)、審計(jì)、知識(shí)沉淀需求就值得考慮自托管方案。2.3 技術(shù)選型的常見考量這類項(xiàng)目在技術(shù)選型上通常有幾個(gè)方向。后端語(yǔ)言方面Go 和 Node.js 是比較常見的選擇前者勝在部署簡(jiǎn)單、性能穩(wěn)定后者勝在生態(tài)豐富、上手快。數(shù)據(jù)庫(kù)方面PostgreSQL 幾乎是標(biāo)配因?yàn)樵u(píng)審數(shù)據(jù)天然是關(guān)系型的需要復(fù)雜的關(guān)聯(lián)查詢。前端方面React 或 Vue 都能勝任關(guān)鍵是要把評(píng)審界面做得足夠輕量不能讓評(píng)審人覺得“用這個(gè)工具比直接看代碼還累”。我在實(shí)際搭建時(shí)踩過的一個(gè)坑是一開始追求功能大而全結(jié)果評(píng)審界面加載了太多信息評(píng)審人打開就懵了。后來做減法把界面精簡(jiǎn)到“代碼 diff 評(píng)論框 規(guī)則提示”三塊使用率立刻上來了。這個(gè)經(jīng)驗(yàn)說明評(píng)審工具的核心競(jìng)爭(zhēng)力不是功能多而是讓評(píng)審這件事變得足夠順滑。3. 核心機(jī)制拆解規(guī)則、記錄與統(tǒng)計(jì)怎么落地3.1 評(píng)審規(guī)則的結(jié)構(gòu)化定義評(píng)審規(guī)則是整套系統(tǒng)的靈魂。如果規(guī)則只是寫在文檔里的一段話那它永遠(yuǎn)不會(huì)被執(zhí)行。open-code-review 這類項(xiàng)目通常會(huì)把規(guī)則做成可配置的結(jié)構(gòu)化數(shù)據(jù)每條規(guī)則包含幾個(gè)要素規(guī)則名稱、觸發(fā)條件、檢查內(nèi)容、嚴(yán)重級(jí)別、建議操作。舉個(gè)具體的例子一條關(guān)于“函數(shù)長(zhǎng)度”的規(guī)則可以這樣定義觸發(fā)條件是“新增或修改的函數(shù)”檢查內(nèi)容是“函數(shù)體行數(shù)是否超過 50 行”嚴(yán)重級(jí)別是“警告”建議操作是“拆分為更小的函數(shù)”。這樣定義的好處是規(guī)則可以被程序讀取、可以被統(tǒng)計(jì)、可以被版本管理。當(dāng)團(tuán)隊(duì)想調(diào)整標(biāo)準(zhǔn)時(shí)改配置就行不需要重新培訓(xùn)所有人。我在配置規(guī)則時(shí)的一個(gè)心得是規(guī)則數(shù)量要克制。一開始我列了三十多條規(guī)則結(jié)果評(píng)審人根本記不住最后全被忽略。后來精簡(jiǎn)到八條核心規(guī)則每條都配了正反例執(zhí)行率反而高了。規(guī)則的價(jià)值不在于多而在于每一條都真的被當(dāng)回事。3.2 評(píng)審記錄的關(guān)聯(lián)與檢索評(píng)審記錄如果只是“某人在某時(shí)間評(píng)論了某段代碼”那它的價(jià)值有限。真正有用的記錄需要能回答幾個(gè)問題這個(gè)意見是針對(duì)哪個(gè)提交的這個(gè)提交屬于哪個(gè)需求這個(gè)需求最終有沒有被合入要回答這些問題記錄就必須和代碼版本、需求管理系統(tǒng)、合并記錄做關(guān)聯(lián)。open-code-review 通常會(huì)在數(shù)據(jù)模型里設(shè)計(jì)幾層關(guān)聯(lián)評(píng)審意見關(guān)聯(lián)到代碼行代碼行關(guān)聯(lián)到提交提交關(guān)聯(lián)到分支分支關(guān)聯(lián)到合并請(qǐng)求。這樣一層層串起來之后你就能做很多有意思的查詢。比如“找出所有被標(biāo)記為‘嚴(yán)重’但最終仍然合入的意見”這類查詢能幫團(tuán)隊(duì)發(fā)現(xiàn)流程漏洞。我在實(shí)際使用中發(fā)現(xiàn)檢索功能的使用頻率遠(yuǎn)超預(yù)期。開發(fā)者經(jīng)常需要回溯“當(dāng)初為什么這么改”如果能快速搜到當(dāng)時(shí)的評(píng)審意見能省下大量溝通成本。所以我的建議是評(píng)審記錄的檢索一定要做得好用支持按關(guān)鍵詞、按人、按時(shí)間、按嚴(yán)重級(jí)別多維度篩選。3.3 統(tǒng)計(jì)維度與分析價(jià)值統(tǒng)計(jì)是評(píng)審數(shù)據(jù)沉淀之后最有價(jià)值的產(chǎn)出。常見的統(tǒng)計(jì)維度包括評(píng)審響應(yīng)時(shí)長(zhǎng)從提交到首次評(píng)論的時(shí)間、評(píng)審?fù)ㄟ^率首次提交就通過的比例、問題分布哪類問題出現(xiàn)最多、評(píng)審人負(fù)載誰(shuí)評(píng)審得最多、誰(shuí)評(píng)審得最少。這些數(shù)據(jù)單獨(dú)看可能沒什么感覺但組合起來就能說明很多問題。比如如果某個(gè)模塊的評(píng)審?fù)ㄟ^率明顯低于其他模塊那可能說明這個(gè)模塊的代碼質(zhì)量本身有問題或者評(píng)審標(biāo)準(zhǔn)在這個(gè)模塊上執(zhí)行得特別嚴(yán)格。再比如如果某個(gè)評(píng)審人的平均響應(yīng)時(shí)長(zhǎng)特別長(zhǎng)那可能說明他的工作量已經(jīng)飽和需要調(diào)整分工。我個(gè)人的經(jīng)驗(yàn)是統(tǒng)計(jì)功能不要做得太復(fù)雜先做好三張表按人統(tǒng)計(jì)、按模塊統(tǒng)計(jì)、按時(shí)間統(tǒng)計(jì)。這三張表能覆蓋 80% 的分析需求。更復(fù)雜的分析可以等團(tuán)隊(duì)用起來之后再逐步加。4. 實(shí)操落地從零搭建一套可用的評(píng)審工作流4.1 環(huán)境準(zhǔn)備與基礎(chǔ)部署假設(shè)你現(xiàn)在要從零搭建一套 open-code-review 的工作流第一步是環(huán)境準(zhǔn)備。你需要一臺(tái)能跑服務(wù)的機(jī)器物理機(jī)、虛擬機(jī)、容器都行一個(gè) PostgreSQL 數(shù)據(jù)庫(kù)以及一個(gè)能訪問代碼倉(cāng)庫(kù)的網(wǎng)絡(luò)環(huán)境。如果團(tuán)隊(duì)用的是自建代碼托管平臺(tái)還需要配置相應(yīng)的訪問憑證。部署方式上我推薦用容器化部署因?yàn)橐蕾嚬芾碜钍⌒?。典型的部署清單包括?yīng)用服務(wù)容器、數(shù)據(jù)庫(kù)容器、反向代理容器。配置文件通常包含數(shù)據(jù)庫(kù)連接信息、代碼倉(cāng)庫(kù)地址、通知渠道配置比如郵件或內(nèi)部 IM 的 webhook。這些配置項(xiàng)看起來瑣碎但每一項(xiàng)都直接影響系統(tǒng)能不能跑通。我在部署時(shí)踩過的一個(gè)坑是數(shù)據(jù)庫(kù)連接池配置得太小導(dǎo)致并發(fā)評(píng)審時(shí)經(jīng)常超時(shí)。后來把連接池調(diào)到 20 以上問題就消失了。這個(gè)經(jīng)驗(yàn)說明評(píng)審系統(tǒng)雖然并發(fā)量不大但因?yàn)槭墙换ナ讲僮鲗?duì)響應(yīng)時(shí)間很敏感資源預(yù)留要充足一些。4.2 規(guī)則配置的實(shí)操步驟規(guī)則配置是落地階段最花時(shí)間的環(huán)節(jié)。我的建議是分三步走第一步先梳理團(tuán)隊(duì)當(dāng)前最在意的五到八條規(guī)則不要貪多第二步把每條規(guī)則翻譯成結(jié)構(gòu)化配置明確觸發(fā)條件、檢查內(nèi)容、嚴(yán)重級(jí)別第三步找兩三個(gè)真實(shí)的歷史 PR 做測(cè)試看看規(guī)則能不能正確觸發(fā)。配置文件的格式通常是 YAML結(jié)構(gòu)大致如下rules: - name: function-length trigger: modified_function check: lines 50 severity: warning suggestion: consider splitting into smaller functions - name: missing-test trigger: new_function check: no corresponding test severity: error suggestion: add unit test for new function這個(gè)配置的意思是修改的函數(shù)如果超過 50 行給出警告新增的函數(shù)如果沒有對(duì)應(yīng)測(cè)試給出錯(cuò)誤。嚴(yán)重級(jí)別的區(qū)分很重要錯(cuò)誤級(jí)別通常會(huì)阻止合并警告級(jí)別只是提示。我在配置規(guī)則時(shí)的一個(gè)心得是規(guī)則要配正反例。光寫“函數(shù)不能超過 50 行”太抽象配上“這個(gè)函數(shù) 30 行合格”和“這個(gè)函數(shù) 80 行不合格”兩個(gè)例子評(píng)審人一看就懂。這個(gè)細(xì)節(jié)看起來小但對(duì)規(guī)則執(zhí)行率的影響很大。4.3 評(píng)審流程的完整走查配置好規(guī)則之后完整的評(píng)審流程大致是這樣的開發(fā)者提交代碼系統(tǒng)自動(dòng)檢查規(guī)則并生成提示評(píng)審人收到通知后查看代碼 diff 和規(guī)則提示逐條給出意見開發(fā)者根據(jù)意見修改評(píng)審人確認(rèn)后通過系統(tǒng)記錄整個(gè)過程的元數(shù)據(jù)。這個(gè)流程里最容易被忽視的環(huán)節(jié)是“規(guī)則提示的呈現(xiàn)方式”。如果提示只是冷冰冰地列在那里評(píng)審人很可能直接跳過。好的做法是把提示和代碼 diff 并排展示讓評(píng)審人在看代碼的同時(shí)就能看到相關(guān)規(guī)則。我在實(shí)際使用中發(fā)現(xiàn)這種并排展示的方式能讓規(guī)則執(zhí)行率提升不少。另一個(gè)細(xì)節(jié)是通知機(jī)制。評(píng)審人收到通知的時(shí)機(jī)很關(guān)鍵太早代碼還沒寫完會(huì)打擾太晚已經(jīng)過了半天會(huì)拖延。我的經(jīng)驗(yàn)是在開發(fā)者明確標(biāo)記“可以評(píng)審”之后再發(fā)通知同時(shí)設(shè)置一個(gè)提醒間隔比如超過四小時(shí)未響應(yīng)就再提醒一次。4.4 與現(xiàn)有工具鏈的集成評(píng)審工具很少孤立存在它通常需要和代碼托管平臺(tái)、需求管理系統(tǒng)、內(nèi)部 IM 做集成。集成的深度決定了這套工具用起來順不順。最基本的集成是代碼托管平臺(tái)需要能讀取提交、分支、合并請(qǐng)求信息。進(jìn)階的集成是需求管理系統(tǒng)需要能把評(píng)審意見關(guān)聯(lián)到具體需求。再進(jìn)階的是內(nèi)部 IM需要能把評(píng)審?fù)ㄖ徒Y(jié)果推送到團(tuán)隊(duì)頻道。我在集成上踩過的坑是一開始只做了代碼托管平臺(tái)的集成結(jié)果評(píng)審意見和需求完全脫節(jié)回溯的時(shí)候根本不知道某個(gè)改動(dòng)是為了什么需求。后來補(bǔ)上了需求管理系統(tǒng)的集成把需求編號(hào)寫進(jìn)提交信息評(píng)審意見就能自動(dòng)關(guān)聯(lián)到需求回溯效率高了很多。集成這件事的原則是先做最必要的再逐步加。不要一上來就追求全鏈路打通那樣很容易在集成細(xì)節(jié)上耗光精力反而忽略了評(píng)審本身。5. 常見問題與排查技巧實(shí)錄5.1 規(guī)則誤報(bào)與漏報(bào)怎么處理規(guī)則誤報(bào)是最常見的問題。比如某條規(guī)則規(guī)定“函數(shù)不能超過 50 行”但有些場(chǎng)景下確實(shí)需要寫長(zhǎng)函數(shù)比如復(fù)雜的初始化邏輯這時(shí)候規(guī)則就會(huì)誤報(bào)。處理誤報(bào)的方式通常有兩種一是給規(guī)則加例外標(biāo)記開發(fā)者可以在代碼里加注釋說明為什么這里需要例外二是調(diào)整規(guī)則的觸發(fā)條件讓它更精準(zhǔn)。漏報(bào)則更隱蔽通常是規(guī)則覆蓋不全導(dǎo)致的。比如只檢查了新增函數(shù)沒檢查修改函數(shù)就會(huì)漏掉修改引入的問題。處理漏報(bào)需要定期回顧評(píng)審記錄看看有沒有“事后才發(fā)現(xiàn)”的問題如果有就說明規(guī)則需要補(bǔ)充。我的經(jīng)驗(yàn)是規(guī)則維護(hù)是一個(gè)持續(xù)過程不要指望一次配置就一勞永逸。建議每個(gè)季度回顧一次規(guī)則根據(jù)實(shí)際評(píng)審記錄做調(diào)整。5.2 評(píng)審人積極性不高的破解思路評(píng)審人積極性不高是很多團(tuán)隊(duì)的通病。原因通常有幾個(gè)評(píng)審太耗時(shí)、評(píng)審意見不被重視、評(píng)審結(jié)果沒有反饋。破解思路也要從這幾個(gè)原因入手。降低評(píng)審耗時(shí)的方法是優(yōu)化工具界面讓評(píng)審人能在最短時(shí)間內(nèi)看到最關(guān)鍵的信息。讓評(píng)審意見被重視的方法是建立閉環(huán)每條意見都要有明確的處理結(jié)果。給評(píng)審結(jié)果反饋的方法是做統(tǒng)計(jì)和公示讓評(píng)審人看到自己的貢獻(xiàn)。我在實(shí)際推動(dòng)時(shí)用過的一個(gè)技巧是把評(píng)審質(zhì)量和團(tuán)隊(duì)內(nèi)部的認(rèn)可掛鉤。比如每月統(tǒng)計(jì)一次“最有價(jià)值的評(píng)審意見”在團(tuán)隊(duì)會(huì)議上公開表?yè)P(yáng)。這個(gè)做法成本很低但效果很明顯因?yàn)樵u(píng)審人感受到了自己的付出被看見。5.3 數(shù)據(jù)一致性與性能問題排查數(shù)據(jù)一致性問題通常出現(xiàn)在集成環(huán)節(jié)。比如代碼托管平臺(tái)的提交信息和評(píng)審系統(tǒng)里的記錄對(duì)不上可能是同步延遲或者同步失敗導(dǎo)致的。排查這類問題的思路是先看日志確認(rèn)同步任務(wù)有沒有正常執(zhí)行再看數(shù)據(jù)確認(rèn)兩邊的主鍵能不能對(duì)上最后看網(wǎng)絡(luò)確認(rèn)集成接口有沒有超時(shí)。性能問題通常出現(xiàn)在數(shù)據(jù)量大了之后。評(píng)審記錄積累到幾萬(wàn)條時(shí)檢索可能會(huì)變慢。優(yōu)化思路包括給常用查詢字段加索引、對(duì)歷史數(shù)據(jù)做歸檔、把統(tǒng)計(jì)任務(wù)放到離線執(zhí)行。我在實(shí)際使用中發(fā)現(xiàn)大部分性能問題都能通過加索引解決真正需要架構(gòu)調(diào)整的情況很少。5.4 常見問題速查表問題現(xiàn)象可能原因排查方向解決建議規(guī)則不觸發(fā)觸發(fā)條件配置錯(cuò)誤檢查規(guī)則配置的 trigger 字段用測(cè)試數(shù)據(jù)驗(yàn)證規(guī)則評(píng)審?fù)ㄖ詹坏酵ㄖ琅渲缅e(cuò)誤檢查 webhook 地址和憑證手動(dòng)觸發(fā)一次通知測(cè)試檢索結(jié)果不全索引缺失或數(shù)據(jù)未同步檢查數(shù)據(jù)庫(kù)索引和同步日志補(bǔ)索引、重跑同步任務(wù)統(tǒng)計(jì)數(shù)字對(duì)不上統(tǒng)計(jì)口徑不一致核對(duì)統(tǒng)計(jì)邏輯和原始數(shù)據(jù)統(tǒng)一統(tǒng)計(jì)口徑并文檔化系統(tǒng)響應(yīng)慢資源不足或查詢低效檢查 CPU、內(nèi)存、慢查詢?nèi)罩緮U(kuò)容或優(yōu)化查詢這張表是我在實(shí)際運(yùn)維中總結(jié)出來的覆蓋了大部分常見問題。遇到問題時(shí)先對(duì)照這張表排查能省下不少時(shí)間。6. 我在這套工作流上的一些真實(shí)體會(huì)搭建和使用 open-code-review 這類工具的過程中我最大的體會(huì)是工具本身只能解決“能不能做”的問題解決不了“愿不愿意做”的問題。評(píng)審文化才是核心工具只是載體。我見過團(tuán)隊(duì)把工具配得很完善但評(píng)審依然流于形式也見過團(tuán)隊(duì)只用最基礎(chǔ)的功能但評(píng)審質(zhì)量很高。差別就在于團(tuán)隊(duì)是不是真的把評(píng)審當(dāng)回事。另一個(gè)體會(huì)是評(píng)審規(guī)則要少而精。一開始總想覆蓋所有情況結(jié)果規(guī)則越多執(zhí)行越差。后來精簡(jiǎn)到幾條核心規(guī)則每條都配正反例執(zhí)行率反而上去了。這個(gè)道理和寫代碼一樣少即是多。最后一個(gè)實(shí)用建議評(píng)審數(shù)據(jù)要定期回顧。不要只收集不分析那樣數(shù)據(jù)就是死的。每個(gè)月花半小時(shí)看看評(píng)審統(tǒng)計(jì)能發(fā)現(xiàn)很多流程上的問題。比如某個(gè)模塊的評(píng)審?fù)ㄟ^率突然下降可能說明這個(gè)模塊的代碼質(zhì)量在惡化需要提前介入。這套工作流后續(xù)還可以往幾個(gè)方向擴(kuò)展一是和 CI 流水線打通讓規(guī)則檢查自動(dòng)化二是和知識(shí)庫(kù)打通把評(píng)審意見沉淀成團(tuán)隊(duì)規(guī)范三是做評(píng)審人的能力畫像幫助團(tuán)隊(duì)做更合理的分工。這些擴(kuò)展都不難關(guān)鍵是先把基礎(chǔ)流程跑順。