1. 從“open-code-review”這個(gè)標(biāo)題說起它到底想解決什么問題第一次看到“open-code-review”這個(gè)標(biāo)題我腦子里蹦出來的不是某個(gè)具體工具而是一整套協(xié)作流程。代碼評(píng)審這件事做過團(tuán)隊(duì)開發(fā)的人都懂——它既是質(zhì)量守門員也是最容易變成走過場(chǎng)的環(huán)節(jié)。標(biāo)題里那個(gè)“open”很關(guān)鍵它至少有三層含義一是評(píng)審過程對(duì)團(tuán)隊(duì)公開透明二是評(píng)審工具本身是開源的、可自建的三是評(píng)審文化是開放的誰都能提意見而不是只有組長能拍板。我這些年待過幾個(gè)不同規(guī)模的研發(fā)團(tuán)隊(duì)從五六個(gè)人的小作坊到上百人的協(xié)作體代碼評(píng)審的形態(tài)差別巨大。小團(tuán)隊(duì)往往靠一句“你幫我瞅一眼”就上線了大團(tuán)隊(duì)則可能有一套完整的評(píng)審系統(tǒng)卡點(diǎn)、門禁、自動(dòng)化檢查一應(yīng)俱全。但不管規(guī)模如何核心痛點(diǎn)高度一致評(píng)審效率低、意見難追蹤、責(zé)任說不清、新人不敢提、老人懶得看。open-code-review 這個(gè)方向本質(zhì)上就是想把評(píng)審從“人治”變成“流程工具文化”的三位一體。這篇文章適合誰看如果你是團(tuán)隊(duì)里負(fù)責(zé)搭建研發(fā)流程的人或者你正被“評(píng)審流于形式”折磨又或者你只是想給自己開源項(xiàng)目找一套靠譜的評(píng)審機(jī)制那接下來的內(nèi)容應(yīng)該能幫到你。我會(huì)從整體設(shè)計(jì)思路講到具體落地步驟再到踩過的坑和排查技巧盡量把每個(gè)決策背后的“為什么”說清楚。畢竟評(píng)審這件事光知道工具怎么裝沒用得明白它為什么這么設(shè)計(jì)才能在自己的場(chǎng)景里靈活調(diào)整。2. 整體設(shè)計(jì)與思路拆解為什么是“開放評(píng)審”而不是“關(guān)門評(píng)審”2.1 核心需求解析評(píng)審到底在評(píng)什么很多人把代碼評(píng)審等同于“找bug”這其實(shí)窄化了它的價(jià)值。我梳理下來一次有效的評(píng)審至少覆蓋四個(gè)層面正確性邏輯對(duì)不對(duì)、邊界有沒有處理、可維護(hù)性命名、結(jié)構(gòu)、注釋是否清晰、一致性是否符合團(tuán)隊(duì)規(guī)范和既有風(fēng)格、知識(shí)傳遞評(píng)審者和被評(píng)審者是否都學(xué)到了東西。open-code-review 的設(shè)計(jì)思路就是把這四個(gè)層面拆解成可操作的檢查項(xiàng)而不是靠評(píng)審者臨場(chǎng)發(fā)揮。為什么強(qiáng)調(diào)“開放”因?yàn)殛P(guān)門評(píng)審有個(gè)致命問題評(píng)審者容易陷入“挑刺模式”被評(píng)審者容易進(jìn)入“防御模式”。一旦變成對(duì)抗評(píng)審就失去了知識(shí)傳遞的意義。開放評(píng)審的核心是把評(píng)審變成一次公開的技術(shù)討論意見對(duì)事不對(duì)人而且所有討論記錄都留痕后來的人能查到“當(dāng)初為什么這么寫”。這一點(diǎn)在人員流動(dòng)頻繁的團(tuán)隊(duì)里尤其重要代碼背后的決策上下文往往比代碼本身更值錢。2.2 方案選型背后的考量自建還是用現(xiàn)成說到落地第一個(gè)岔路口就是用現(xiàn)成的托管平臺(tái)自帶評(píng)審功能還是自建一套 open-code-review 流程我的經(jīng)驗(yàn)是兩者不沖突但側(cè)重點(diǎn)不同。托管平臺(tái)的優(yōu)勢(shì)是開箱即用、和代碼倉庫深度集成缺點(diǎn)是定制化能力有限尤其是當(dāng)你想把評(píng)審和內(nèi)部的質(zhì)量門禁、知識(shí)庫、通知系統(tǒng)打通時(shí)往往會(huì)遇到瓶頸。自建 open-code-review 的價(jià)值在于可控。你可以定義自己的評(píng)審檢查清單、自己的分級(jí)標(biāo)準(zhǔn)、自己的自動(dòng)化觸發(fā)規(guī)則。比如我們之前就規(guī)定涉及核心鏈路的改動(dòng)必須至少兩人評(píng)審純文檔改動(dòng)一人即可緊急修復(fù)可以走快速通道但事后必須補(bǔ)評(píng)審。這種細(xì)粒度的規(guī)則現(xiàn)成平臺(tái)很難完全滿足。當(dāng)然自建的成本也不低需要有人維護(hù)工具鏈、有人推動(dòng)文化落地。所以我的建議是小團(tuán)隊(duì)先用現(xiàn)成平臺(tái)跑起來等流程穩(wěn)定了、痛點(diǎn)明確了再考慮自建或混合方案。2.3 開放評(píng)審的三大支柱流程、工具、文化我把 open-code-review 拆成三個(gè)支柱來理解。流程解決“什么時(shí)候評(píng)、誰來評(píng)、評(píng)完怎么算通過”工具解決“在哪里評(píng)、怎么記錄、怎么自動(dòng)化”文化解決“愿不愿意評(píng)、敢不敢提意見、意見被采納后有沒有正反饋”。三者缺一不可而且順序不能亂——先有流程共識(shí)再上工具最后靠文化固化。我見過太多團(tuán)隊(duì)一上來就折騰工具結(jié)果流程沒理清工具反而成了負(fù)擔(dān)。比如有人裝了一堆自動(dòng)化檢查每次提交都報(bào)幾十條警告大家看都不看直接忽略最后工具形同虛設(shè)。正確的做法是先和團(tuán)隊(duì)對(duì)齊“我們?cè)u(píng)審到底要看什么”把檢查項(xiàng)精簡到真正重要的幾條再讓工具去輔助執(zhí)行。文化層面則要靠持續(xù)的正向激勵(lì)比如公開表揚(yáng)提出高質(zhì)量評(píng)審意見的人或者把評(píng)審質(zhì)量納入技術(shù)影響力的考量而不是只數(shù)評(píng)審次數(shù)。3. 核心細(xì)節(jié)解析與實(shí)操要點(diǎn)把評(píng)審拆成可執(zhí)行的步驟3.1 評(píng)審檢查清單的設(shè)計(jì)少即是多檢查清單是 open-code-review 的靈魂但也是最容易設(shè)計(jì)過度的部分。我試過給團(tuán)隊(duì)列了三十多條檢查項(xiàng)結(jié)果沒人記得住評(píng)審時(shí)還是憑感覺。后來砍到八條反而執(zhí)行得更好。這八條大致是改動(dòng)目的是否清晰、是否有對(duì)應(yīng)的測(cè)試或驗(yàn)證方式、邊界條件是否處理、錯(cuò)誤處理是否合理、命名和注釋是否達(dá)意、是否有安全或性能隱患、是否影響既有功能、文檔是否同步更新。設(shè)計(jì)清單的關(guān)鍵是可判斷。像“代碼是否優(yōu)雅”這種就太主觀沒法執(zhí)行而“新增函數(shù)是否有對(duì)應(yīng)的單元測(cè)試”就很明確有就是有沒有就是沒有。另外清單要分級(jí)別核心模塊的改動(dòng)走完整清單邊緣模塊可以只走前四條。這樣既保證質(zhì)量又不至于讓評(píng)審變成負(fù)擔(dān)。我個(gè)人的經(jīng)驗(yàn)是清單最好由團(tuán)隊(duì)一起討論定稿而不是組長拍腦袋這樣大家才有認(rèn)同感。3.2 評(píng)審粒度與節(jié)奏控制別讓評(píng)審變成馬拉松評(píng)審粒度是個(gè)容易被忽視但影響巨大的點(diǎn)。一個(gè)改動(dòng)如果超過五百行評(píng)審質(zhì)量會(huì)斷崖式下降——評(píng)審者看到后面忘了前面最后只能草草點(diǎn)個(gè)通過。所以 open-code-review 的一個(gè)實(shí)操要點(diǎn)是控制單次評(píng)審的規(guī)模。我們當(dāng)時(shí)的做法是超過三百行的改動(dòng)必須拆成多個(gè)小提交每個(gè)提交聚焦一個(gè)邏輯單元評(píng)審者可以逐個(gè)提交看而不是一次性面對(duì)一大坨。節(jié)奏控制也很重要。我見過兩種極端一種是攢了一周才評(píng)審結(jié)果上下文全忘了另一種是每改一行就發(fā)起評(píng)審評(píng)審者被頻繁打斷。比較舒服的節(jié)奏是小改動(dòng)當(dāng)天評(píng)大改動(dòng)拆成小步走。另外評(píng)審請(qǐng)求發(fā)出后最好給評(píng)審者一個(gè)明確的預(yù)期比如“這個(gè)改動(dòng)我明天下午前需要反饋”而不是無限期掛著。工具層面可以設(shè)置提醒但別搞成騷擾一天一次提醒足夠了。3.3 意見分級(jí)與處理機(jī)制不是所有意見都要改評(píng)審意見最怕兩種一種是“我覺得這樣不好”但說不出所以然另一種是“必須按我說的改”但其實(shí)是個(gè)人偏好。open-code-review 的解法是給意見分級(jí)。我們當(dāng)時(shí)分了三級(jí)阻塞級(jí)必須改不改不能合并比如邏輯錯(cuò)誤、安全隱患、建議級(jí)可以改也可以不改但需要回應(yīng)比如命名優(yōu)化、討論級(jí)只是提出一個(gè)思路供參考不強(qiáng)制回應(yīng)。分級(jí)的好處是讓被評(píng)審者知道哪些必須處理、哪些可以商量。同時(shí)評(píng)審者也要克制別把個(gè)人偏好包裝成阻塞級(jí)。我踩過的坑是早期大家不好意思標(biāo)阻塞級(jí)結(jié)果所有意見都變成“建議”最后誰也沒改。后來我們明確涉及正確性和安全性的必須標(biāo)阻塞級(jí)這是對(duì)代碼負(fù)責(zé)不是對(duì)人苛刻。處理機(jī)制上建議級(jí)意見如果被評(píng)審者決定不改需要簡單說明理由這樣評(píng)審者也能學(xué)到東西而不是覺得自己的意見被無視了。3.4 自動(dòng)化與人工評(píng)審的邊界機(jī)器管格式人管邏輯open-code-review 不是要取代人工評(píng)審而是要把人工從重復(fù)勞動(dòng)里解放出來。我的原則是機(jī)器能判斷的絕不讓人來判斷。比如代碼格式、靜態(tài)檢查、單元測(cè)試是否通過、是否有明顯的安全漏洞這些全部交給自動(dòng)化工具在評(píng)審發(fā)起前就跑完不通過直接打回根本進(jìn)不了人工評(píng)審環(huán)節(jié)。人工評(píng)審聚焦在機(jī)器搞不定的地方設(shè)計(jì)是否合理、邏輯是否自洽、邊界是否考慮周全、可讀性如何、是否有更好的實(shí)現(xiàn)思路。這樣評(píng)審者不用浪費(fèi)時(shí)間在格式問題上可以把精力放在真正需要人類判斷的地方。我實(shí)測(cè)下來這種分工能讓評(píng)審效率提升至少三成而且評(píng)審者的體驗(yàn)也好很多——沒人喜歡當(dāng)人肉格式化工具。4. 實(shí)操過程與核心環(huán)節(jié)實(shí)現(xiàn)從零搭一套可用的評(píng)審流程4.1 環(huán)境與工具鏈準(zhǔn)備先跑通最小閉環(huán)假設(shè)你現(xiàn)在要從零開始搭一套 open-code-review 流程我建議先跑通最小閉環(huán)別一上來就追求大而全。最小閉環(huán)包括代碼倉庫托管代碼和評(píng)審記錄、評(píng)審觸發(fā)機(jī)制比如提交合并請(qǐng)求時(shí)自動(dòng)創(chuàng)建評(píng)審任務(wù)、通知渠道讓評(píng)審者知道有活干了、意見記錄與追蹤確保每條意見都有回應(yīng)。工具選型上如果團(tuán)隊(duì)已經(jīng)在用某個(gè)托管平臺(tái)優(yōu)先用平臺(tái)自帶的評(píng)審功能減少學(xué)習(xí)成本。如果平臺(tái)功能不夠可以考慮引入獨(dú)立的評(píng)審工具但要注意和現(xiàn)有倉庫的集成成本。我個(gè)人的經(jīng)驗(yàn)是工具鏈越簡單越好每多一個(gè)工具就多一個(gè)維護(hù)點(diǎn)。通知渠道用團(tuán)隊(duì)日常溝通的工具就行別單獨(dú)搞一個(gè)否則大家不會(huì)看。評(píng)審記錄一定要和代碼倉庫關(guān)聯(lián)這樣后來的人查代碼時(shí)能直接看到當(dāng)初的評(píng)審討論。4.2 評(píng)審請(qǐng)求的發(fā)起與描述規(guī)范讓評(píng)審者少問幾句評(píng)審請(qǐng)求的描述質(zhì)量直接決定評(píng)審效率。我見過太多評(píng)審請(qǐng)求就寫一句“改了點(diǎn)東西幫忙看看”評(píng)審者點(diǎn)進(jìn)去一臉懵還得反過來問“你改這個(gè)是為了啥”。open-code-review 的一個(gè)實(shí)操要點(diǎn)是評(píng)審請(qǐng)求必須包含改動(dòng)目的、改動(dòng)范圍、驗(yàn)證方式、需要重點(diǎn)關(guān)注的地方。這四樣寫清楚評(píng)審者能省一半時(shí)間。我們當(dāng)時(shí)定了一個(gè)模板發(fā)起評(píng)審時(shí)自動(dòng)帶出來填完才能提交。模板大致是這個(gè)改動(dòng)解決了什么問題、改了哪些文件、怎么驗(yàn)證的跑了什么測(cè)試或手動(dòng)驗(yàn)證步驟、有沒有已知的遺留問題、希望評(píng)審者重點(diǎn)看哪里。剛開始大家嫌麻煩但跑了兩周后所有人都嘗到了甜頭——評(píng)審者不再問“這是干嘛的”評(píng)審意見也更聚焦了。這個(gè)投入產(chǎn)出比非常高強(qiáng)烈建議一開始就上模板。4.3 評(píng)審執(zhí)行與意見記錄把討論留在代碼旁邊評(píng)審執(zhí)行階段最關(guān)鍵的是把討論留在代碼旁邊而不是跑到聊天工具里。聊天工具里的討論過兩天就沉底了后來的人根本查不到。open-code-review 的做法是所有意見都掛在具體的代碼行上形成行級(jí)評(píng)論。這樣后來的人看代碼時(shí)能直接看到“這行為什么這么寫”“當(dāng)初誰提了什么意見”。評(píng)審者提意見時(shí)我建議遵循“先問后斷”的原則。比如看到一段代碼覺得有問題先問“這里是不是沒考慮空值的情況”而不是直接說“你這寫錯(cuò)了”。前者是討論后者是審判。被評(píng)審者回應(yīng)時(shí)也要對(duì)每條意見給出明確反饋改了、不改但說明理由、或者需要進(jìn)一步討論。我踩過的坑是早期大家只回復(fù)“好的”但到底改沒改、改在哪沒人知道。后來我們要求如果改了要指出改在哪個(gè)提交如果不改要說明理由。這樣評(píng)審記錄才是完整的。4.4 評(píng)審?fù)ㄟ^后的合并與復(fù)盤別評(píng)完就完了評(píng)審?fù)ㄟ^不等于結(jié)束。open-code-review 的完整閉環(huán)還包括合并后的復(fù)盤。我們當(dāng)時(shí)每周會(huì)抽半小時(shí)快速過一遍上周的評(píng)審記錄看看有沒有反復(fù)出現(xiàn)的問題、有沒有評(píng)審時(shí)漏掉的隱患、有沒有特別高質(zhì)量的評(píng)審意見值得分享。這個(gè)復(fù)盤不需要很正式但堅(jiān)持下來效果驚人——很多共性問題在復(fù)盤時(shí)被發(fā)現(xiàn)然后通過文檔或自動(dòng)化檢查固化下來下次就不用再靠人提醒了。另外合并后的代碼如果出了問題也可以回溯評(píng)審記錄看看當(dāng)初為什么沒發(fā)現(xiàn)。這不是為了追責(zé)而是為了改進(jìn)評(píng)審清單。比如我們發(fā)現(xiàn)某類邊界問題反復(fù)出現(xiàn)就在檢查清單里加了一條“是否處理了空值和越界”并在自動(dòng)化測(cè)試?yán)镅a(bǔ)了對(duì)應(yīng)的用例。這樣評(píng)審流程就形成了一個(gè)持續(xù)改進(jìn)的循環(huán)而不是一成不變的死規(guī)矩。5. 常見問題與排查技巧實(shí)錄那些評(píng)審中繞不開的坑5.1 評(píng)審沒人愿意做怎么辦這是最常被問到的問題。我的觀察是沒人愿意做評(píng)審?fù)ǔ２皇且驗(yàn)閼卸且驗(yàn)樽鲈u(píng)審沒有正反饋。評(píng)審做得好沒人看見評(píng)審出問題反而要背鍋那誰愿意做解法有幾個(gè)一是把評(píng)審納入工作量統(tǒng)計(jì)別讓評(píng)審變成“額外勞動(dòng)”二是公開表揚(yáng)高質(zhì)量評(píng)審比如每月選幾條“最有價(jià)值的評(píng)審意見”在團(tuán)隊(duì)里分享三是控制評(píng)審負(fù)擔(dān)別讓一個(gè)人同時(shí)掛太多評(píng)審請(qǐng)求。還有一個(gè)技巧是輪值評(píng)審。我們當(dāng)時(shí)設(shè)了一個(gè)“本周評(píng)審負(fù)責(zé)人”負(fù)責(zé)協(xié)調(diào)評(píng)審任務(wù)分配確保沒有人的請(qǐng)求被晾著。這個(gè)角色每周輪換大家都能體會(huì)到評(píng)審者的不易也能更認(rèn)真地對(duì)待別人的評(píng)審請(qǐng)求。實(shí)測(cè)下來輪值制比“誰有空誰評(píng)”有效得多因?yàn)樨?zé)任明確了就不會(huì)出現(xiàn)“我以為他會(huì)評(píng)”的情況。5.2 評(píng)審意見引發(fā)爭論怎么收?qǐng)鰻幷摬灰欢ㄊ菈氖抡f明大家在認(rèn)真思考。但如果爭論變成僵持就需要收?qǐng)鰴C(jī)制。open-code-review 的做法是設(shè)定一個(gè)決策人。當(dāng)評(píng)審者和被評(píng)審者無法達(dá)成一致時(shí)由決策人通常是模塊負(fù)責(zé)人或技術(shù)負(fù)責(zé)人拍板。拍板不是和稀泥而是基于技術(shù)判斷給出明確結(jié)論并說明理由。這樣既保證了效率又讓雙方都有臺(tái)階下。我個(gè)人的經(jīng)驗(yàn)是大部分爭論其實(shí)源于信息不對(duì)稱。評(píng)審者可能不知道某個(gè)歷史背景被評(píng)審者可能沒解釋清楚某個(gè)約束條件。所以收?qǐng)龅牡谝徊绞茄a(bǔ)充上下文把雙方掌握的信息對(duì)齊。如果對(duì)齊后還有分歧那就上升到?jīng)Q策人。另外爭論過程中要避免人身攻擊對(duì)事不對(duì)人這一點(diǎn)評(píng)審文化里要反復(fù)強(qiáng)調(diào)。5.3 評(píng)審流于形式怎么破流于形式的典型表現(xiàn)是評(píng)審者只看一眼就點(diǎn)通過或者只挑格式問題不碰邏輯。破解的關(guān)鍵是讓評(píng)審有后果。如果評(píng)審沒發(fā)現(xiàn)問題但合并后出了故障復(fù)盤時(shí)要看評(píng)審記錄看看是評(píng)審清單沒覆蓋還是評(píng)審者沒認(rèn)真看。如果是后者就要考慮調(diào)整評(píng)審分配或加強(qiáng)評(píng)審培訓(xùn)。當(dāng)然這不是為了懲罰而是為了讓評(píng)審者意識(shí)到自己的責(zé)任。另一個(gè)技巧是抽樣復(fù)查。我們當(dāng)時(shí)會(huì)隨機(jī)抽一些已通過的評(píng)審由另一位資深人員復(fù)查看看有沒有漏掉的問題。這個(gè)動(dòng)作不是為了抓人而是為了校準(zhǔn)評(píng)審標(biāo)準(zhǔn)。如果發(fā)現(xiàn)某類問題反復(fù)被漏掉就在清單里加一條或者組織一次針對(duì)性的分享。堅(jiān)持幾個(gè)月后評(píng)審質(zhì)量會(huì)有明顯提升因?yàn)榇蠹叶贾涝u(píng)審不是走過場(chǎng)。5.4 常見問題速查表問題現(xiàn)象可能原因排查思路解決建議評(píng)審請(qǐng)求長時(shí)間無人響應(yīng)評(píng)審任務(wù)分配不清、評(píng)審者負(fù)擔(dān)過重查看評(píng)審請(qǐng)求的分配記錄和評(píng)審者當(dāng)前任務(wù)量引入輪值評(píng)審負(fù)責(zé)人控制單人評(píng)審任務(wù)上限評(píng)審意見只有格式問題自動(dòng)化檢查缺失、評(píng)審者精力不足檢查自動(dòng)化工具是否覆蓋格式和靜態(tài)檢查把格式問題交給自動(dòng)化人工聚焦邏輯和設(shè)計(jì)評(píng)審意見引發(fā)長時(shí)間爭論信息不對(duì)稱、缺少?zèng)Q策機(jī)制回溯爭論點(diǎn)看是否缺少上下文或決策人補(bǔ)充上下文設(shè)定決策人拍板并說明理由評(píng)審?fù)ㄟ^后仍出故障評(píng)審清單覆蓋不足、評(píng)審者疏忽復(fù)盤故障原因?qū)φ赵u(píng)審記錄補(bǔ)充檢查清單抽樣復(fù)查評(píng)審質(zhì)量新人不敢提評(píng)審意見評(píng)審文化不包容、缺少正反饋觀察新人參與評(píng)審的頻率和意見被采納情況公開表揚(yáng)新人意見強(qiáng)調(diào)對(duì)事不對(duì)人5.5 獨(dú)家避坑技巧評(píng)審不是越多越好最后分享一個(gè)我踩過的坑早期我們追求“評(píng)審覆蓋率”要求所有改動(dòng)都必須評(píng)審結(jié)果評(píng)審量爆炸評(píng)審者疲于奔命質(zhì)量反而下降。后來我們調(diào)整策略按風(fēng)險(xiǎn)分級(jí)高風(fēng)險(xiǎn)改動(dòng)核心邏輯、安全相關(guān)、對(duì)外接口必須兩人評(píng)審中風(fēng)險(xiǎn)改動(dòng)一人評(píng)審低風(fēng)險(xiǎn)改動(dòng)文檔、注釋、格式可以走快速通道甚至免評(píng)審。這樣評(píng)審資源集中在真正重要的地方整體質(zhì)量反而提升了。另一個(gè)技巧是評(píng)審意見的“保鮮期”。如果一個(gè)評(píng)審請(qǐng)求掛了一周還沒結(jié)論要么是改動(dòng)太大需要拆分要么是評(píng)審者太忙需要重新分配。我們當(dāng)時(shí)設(shè)了一個(gè)規(guī)則評(píng)審請(qǐng)求超過三天沒進(jìn)展自動(dòng)提醒評(píng)審負(fù)責(zé)人介入。這個(gè)規(guī)則避免了評(píng)審請(qǐng)求無限期掛著也避免了被評(píng)審者反復(fù)催問的尷尬。6. 評(píng)審文化的長期建設(shè)從流程到習(xí)慣6.1 讓評(píng)審成為學(xué)習(xí)機(jī)會(huì)而不是審判open-code-review 最終要落到的是一種文化評(píng)審不是挑錯(cuò)而是共同學(xué)習(xí)。我見過最好的評(píng)審氛圍是評(píng)審者會(huì)說“這個(gè)地方我有個(gè)不同的思路你看看有沒有道理”被評(píng)審者會(huì)說“你這個(gè)角度我沒想過我改一下”。這種氛圍不是天生的而是靠一次次正向互動(dòng)積累起來的。作為團(tuán)隊(duì)負(fù)責(zé)人你可以從自己做起主動(dòng)請(qǐng)別人評(píng)審自己的代碼并且認(rèn)真回應(yīng)每一條意見這樣大家才會(huì)跟著做。另外評(píng)審記錄本身就是很好的學(xué)習(xí)材料。新人入職時(shí)可以讓他翻看幾個(gè)典型的評(píng)審記錄看看團(tuán)隊(duì)關(guān)注什么、怎么討論問題。這比看文檔直觀得多也更能傳遞團(tuán)隊(duì)的工程文化。我們當(dāng)時(shí)甚至整理了一個(gè)“評(píng)審案例集”把一些有代表性的評(píng)審討論摘出來作為內(nèi)部培訓(xùn)材料效果很好。6.2 評(píng)審指標(biāo)的合理使用很多團(tuán)隊(duì)會(huì)統(tǒng)計(jì)評(píng)審指標(biāo)比如評(píng)審次數(shù)、意見數(shù)量、響應(yīng)時(shí)間。這些指標(biāo)有用但要小心被濫用。如果只看評(píng)審次數(shù)大家就會(huì)拆小提交來刷數(shù)如果只看意見數(shù)量大家就會(huì)提一堆無關(guān)痛癢的意見。我的建議是指標(biāo)只用于觀察趨勢(shì)不用于考核個(gè)人。比如發(fā)現(xiàn)評(píng)審響應(yīng)時(shí)間變長了就去看看是不是評(píng)審者負(fù)擔(dān)過重而不是去批評(píng)某個(gè)評(píng)審者響應(yīng)慢。比較健康的指標(biāo)組合是評(píng)審覆蓋率有多少改動(dòng)經(jīng)過了評(píng)審、評(píng)審參與度有多少人參與了評(píng)審、意見處理率有多少意見得到了回應(yīng)、評(píng)審后故障率評(píng)審?fù)ㄟ^的改動(dòng)有多少出了故障。這四個(gè)指標(biāo)結(jié)合起來看能比較全面地反映評(píng)審流程的健康度。但記住指標(biāo)是工具不是目的別為了指標(biāo)好看而犧牲實(shí)際質(zhì)量。6.3 持續(xù)改進(jìn)的機(jī)制評(píng)審流程不是定下來就一勞永逸的。團(tuán)隊(duì)在變、代碼在變、工具在變?cè)u(píng)審流程也要跟著調(diào)整。我們當(dāng)時(shí)的做法是每季度做一次評(píng)審流程回顧看看哪些規(guī)則還適用、哪些需要調(diào)整?；仡櫟妮斎氚ㄔu(píng)審記錄、故障復(fù)盤、團(tuán)隊(duì)反饋、工具使用數(shù)據(jù)。輸出可能是一條新規(guī)則、一個(gè)工具改進(jìn)、或者一次培訓(xùn)分享。這個(gè)回顧不需要很正式一小時(shí)的討論就夠了。關(guān)鍵是讓團(tuán)隊(duì)知道流程是可以改的而不是上面定死的。當(dāng)大家覺得自己的反饋能影響流程時(shí)參與評(píng)審的積極性也會(huì)更高。我個(gè)人的體會(huì)是評(píng)審流程的迭代和代碼迭代一樣重要都是團(tuán)隊(duì)工程能力的一部分。別指望一次設(shè)計(jì)出完美流程而是在實(shí)踐中不斷打磨讓它越來越貼合團(tuán)隊(duì)的實(shí)際需求。7. 我個(gè)人的實(shí)操體會(huì)說了這么多最后分享幾點(diǎn)我自己的體會(huì)。第一評(píng)審流程的復(fù)雜度要和團(tuán)隊(duì)規(guī)模匹配。五個(gè)人團(tuán)隊(duì)搞一套復(fù)雜的評(píng)審系統(tǒng)純屬自找麻煩五十人團(tuán)隊(duì)靠口頭約定評(píng)審必然混亂。找到適合自己團(tuán)隊(duì)的平衡點(diǎn)比照搬大廠經(jīng)驗(yàn)重要得多。第二工具是輔助文化是根本。再好的工具如果團(tuán)隊(duì)沒有認(rèn)真評(píng)審的文化也是白搭反過來文化到位了哪怕工具簡陋一點(diǎn)評(píng)審也能做得不錯(cuò)。第三評(píng)審的最終目的是讓代碼更好、讓團(tuán)隊(duì)更強(qiáng)而不是證明誰對(duì)誰錯(cuò)。記住這一點(diǎn)很多糾結(jié)就迎刃而解了。如果你正在搭建或優(yōu)化團(tuán)隊(duì)的評(píng)審流程我的建議是先從一個(gè)小范圍試點(diǎn)跑通最小閉環(huán)收集反饋再逐步推廣。別一上來就全團(tuán)隊(duì)鋪開那樣一旦出問題調(diào)整成本很高。另外多和團(tuán)隊(duì)成員聊聊聽聽他們對(duì)評(píng)審的真實(shí)想法往往能發(fā)現(xiàn)你沒想到的痛點(diǎn)。評(píng)審這件事說到底是為團(tuán)隊(duì)服務(wù)的適合的才是最好的。