1. 先想清楚開放式代碼審查到底要解決什么問題提起 code review很多團(tuán)隊(duì)的實(shí)際情況其實(shí)挺擰巴的。嘴上都說(shuō)重要真做起來(lái)卻常常流于形式。要么是趕進(jìn)度直接合入要么是review了一圈全是“LGTM”這種無(wú)意義回復(fù)再要么是評(píng)審意見變成人身攻擊現(xiàn)場(chǎng)。我自己待過(guò)幾家不同規(guī)模的技術(shù)團(tuán)隊(duì)從兩三個(gè)人的小組到幾十人的研發(fā)部門都踩過(guò)類似的坑。做得久了以后慢慢提煉出一套相對(duì)成型的方法也就是標(biāo)題里這個(gè)“open-code-review”——其實(shí)不復(fù)雜核心就三件事讓評(píng)審標(biāo)準(zhǔn)透明、讓討論過(guò)程開放、讓合入動(dòng)作可追蹤。先說(shuō)清楚它解決的問題。常規(guī)的代碼評(píng)審最典型的痛點(diǎn)有三個(gè)第一個(gè)痛點(diǎn)是標(biāo)準(zhǔn)不統(tǒng)一。前端同學(xué)覺得變量命名短一點(diǎn)沒關(guān)系后端同學(xué)覺得必須全拼有人堅(jiān)持大函數(shù)拆小有人覺得一個(gè)函數(shù)兩百行也沒什么大不了。這些偏好在沒有明確規(guī)則的時(shí)候每次評(píng)審都變成個(gè)人審美之爭(zhēng)效率極低。第二個(gè)痛點(diǎn)是評(píng)審?fù)Ａ粼凇翱唇Y(jié)果不看過(guò)程”。大部分團(tuán)隊(duì)用PR/MR的方式做review審查者看到的是一坨diff卻不知道這坨diff是怎么一步步演變來(lái)的。有些明顯很奇怪的寫法其實(shí)是為了兼容某個(gè)歷史數(shù)據(jù)或者繞過(guò)線上故障才加的不明背景的評(píng)審者很容易給出“何不食肉糜”式的意見。第三個(gè)痛點(diǎn)是review意見沒有閉環(huán)。今天提出來(lái)的問題過(guò)兩周回頭看可能壓根沒人處理也沒人跟蹤。新來(lái)的同學(xué)照著有問題的代碼繼續(xù)往上疊功能問題就像滾雪球一樣越來(lái)越大。所以開放式代碼審查的核心思路說(shuō)白了就是三件事定義清楚“什么是好代碼”把標(biāo)準(zhǔn)文檔化而不是靠每個(gè)人腦補(bǔ)把評(píng)審從“挑錯(cuò)”變成“共同改進(jìn)”強(qiáng)調(diào)討論過(guò)程而不是單向?qū)弳栕屆織l意見有狀態(tài)、有歸屬、有結(jié)論該修的修該解釋的解釋全部都留痕我見過(guò)很多團(tuán)隊(duì)把code review做成了一道程序化流程——代碼提交、分配評(píng)審人、打分、合入每一步都有了協(xié)作質(zhì)量卻依然糟糕。原因就是他們把review當(dāng)成一道“門檻”而不是一個(gè)“機(jī)會(huì)”。門檻思維下的人會(huì)用最小成本通過(guò)審查機(jī)會(huì)思維下的人才會(huì)認(rèn)真琢磨別人的建議是不是言之有理。open-code-review想做的就是創(chuàng)造這樣一個(gè)環(huán)境讓每個(gè)人在review里都有話說(shuō)都敢說(shuō)真話并且知道自己的建議最終去了哪里。這套方法并不局限于軟件研發(fā)團(tuán)隊(duì)。只要是內(nèi)容產(chǎn)出型協(xié)作——文檔評(píng)審、設(shè)計(jì)評(píng)審、數(shù)據(jù)分析結(jié)論復(fù)核——都能抽出一套類似的流程來(lái)用。所以這篇文章后半部分的實(shí)操細(xì)節(jié)雖然大量舉例是代碼但思路是可以遷移的。2. 工具選型和流程設(shè)計(jì)為什么“開放式”不等于“放任式”2.1 工具決定協(xié)同形態(tài)選型前先想清楚你的團(tuán)隊(duì)規(guī)模組做open-code-review很多人第一反應(yīng)是挑一個(gè)趁手的工具比如GitHub上的pull request、GitLab上的merge request或者代碼托管平臺(tái)自帶的評(píng)審功能。工具本身確實(shí)重要但它不是最關(guān)鍵的變量。最重要的是團(tuán)隊(duì)規(guī)模和工作習(xí)慣工具是要匹配這兩件事的。小團(tuán)隊(duì)三五個(gè)人以內(nèi)其實(shí)不需要太重型的review工具。用GitHub的PR功能就夠了再配上一些簡(jiǎn)單的CI檢查比如最基礎(chǔ)的語(yǔ)法檢查、單元測(cè)試、lint規(guī)則。審查標(biāo)準(zhǔn)用一份Markdown文件放在倉(cāng)庫(kù)里每個(gè)人都能看到這就足夠了。這個(gè)階段最大的問題是容易偷懶跳過(guò)review所以核心理念是用儀式感倒逼習(xí)慣養(yǎng)成——比如固定一個(gè)時(shí)間把所有待review的PR集中過(guò)一遍。中大型團(tuán)隊(duì)十幾個(gè)到幾十人就會(huì)遇到新的問題并行開發(fā)的PR很多評(píng)審人容易漏同一個(gè)文件被多個(gè)人改合入沖突頻繁評(píng)審意見散落在不同的線程里事后翻起來(lái)很費(fèi)勁。這個(gè)階段建議引入帶自定義狀態(tài)流的評(píng)審工具或者用代碼托管平臺(tái)里的review規(guī)則配合機(jī)器人bot來(lái)自動(dòng)分配評(píng)審人、檢查評(píng)審狀態(tài)、攔截未滿足條件的合入。超過(guò)五十人甚至上百人的組織光靠工具已經(jīng)不夠了需要的是分層評(píng)審機(jī)制常規(guī)改動(dòng)由組內(nèi)評(píng)審跨模塊改動(dòng)必須通知受影響方的owner參與評(píng)審核心基礎(chǔ)設(shè)施的改動(dòng)還要走獨(dú)立的專家組評(píng)審。這套機(jī)制不能在工具上生堆出來(lái)而是要在流程設(shè)計(jì)層面規(guī)劃好。工具選型我自己的原則是優(yōu)先用團(tuán)隊(duì)已經(jīng)在用的平臺(tái)不要為了review單獨(dú)引入一套新的協(xié)同工具。原因很簡(jiǎn)單學(xué)習(xí)成本和切換成本都是隱性消耗如果每次提交代碼要跑到一個(gè)陌生的頁(yè)面去操作大家很快會(huì)找出各種理由繞過(guò)這個(gè)流程。與其這樣不如把現(xiàn)有平臺(tái)的潛力挖掘到極致。2.2 “開放式”設(shè)計(jì)的邊界避免三個(gè)常見誤區(qū)“開放式”這個(gè)詞聽起來(lái)很理想似乎人人都能參與、什么意見都可以提就是好的。但實(shí)操中如果邊界沒設(shè)好很容易演變成另一種混亂。我總結(jié)了一下有三個(gè)誤區(qū)最值得警惕。誤區(qū)一把“開放”理解為“誰(shuí)都可以毫無(wú)約束地評(píng)論”。如果任何人隨時(shí)隨地都能對(duì)任何一段代碼發(fā)表意見評(píng)審區(qū)會(huì)變成論壇大量跟代碼質(zhì)量無(wú)關(guān)的噪聲會(huì)淹沒真正有價(jià)值的意見。正確的做法是默認(rèn)情況下代碼作者、相關(guān)模塊的owner和明確指派的評(píng)審人可以評(píng)論其他團(tuán)隊(duì)成員可以閱讀但評(píng)論需要先標(biāo)注一個(gè)理由比如“發(fā)現(xiàn)一個(gè)疑似bug”或者“這里可能需要同步修改文檔”。這個(gè)限制不是封閉而是保護(hù)討論的質(zhì)量。誤區(qū)二把“開放”理解為“所有意見都必須處理”。恰恰相反開放式評(píng)審的精神是——每個(gè)人有權(quán)利發(fā)表意見但不是每條意見都會(huì)被執(zhí)行。代碼作者有責(zé)任逐條回應(yīng)意見但是回應(yīng)可以是“采納”“部分采納”或者“不采納原因如下”三種結(jié)論。重要的是把“不采納的理由”寫清楚而不是每條都照做。否則review就變成了誰(shuí)聲音大誰(shuí)說(shuō)了算技術(shù)判斷反而退居二線。誤區(qū)三把“開放”錯(cuò)位成了“無(wú)流程約束”。開放式評(píng)審在討論階段確實(shí)自由但在合入階段必須有硬性門檻。CI不通過(guò)不能合、必要評(píng)審人數(shù)不夠不能合、關(guān)鍵問題的討論沒有結(jié)論不能合。這些是底線不能開放。所謂開放是打開討論的邊界不是打開質(zhì)量的紅線。我經(jīng)歷過(guò)一次比較典型的“過(guò)度開放”事故。當(dāng)時(shí)團(tuán)隊(duì)剛推行開放評(píng)審大家熱情很高一個(gè)簡(jiǎn)單的前端組件PR下面掛了幾十條評(píng)論從命名風(fēng)格到縮進(jìn)方式再到CSS屬性的書寫順序五花八門。作者被搞得焦頭爛額最后干脆棄用了那個(gè)PR重新開了一個(gè)之后悄悄合入完全沒有討論。這次教訓(xùn)讓我意識(shí)到開放式評(píng)審必須配套“討論分類”的機(jī)制。我后來(lái)在每個(gè)REVIEW_GUIDE.md里明確寫了風(fēng)格類問題不在評(píng)審中爭(zhēng)論統(tǒng)一走lint工具自動(dòng)檢查設(shè)計(jì)類問題必須給出兩種以上可行方案再討論bug類問題優(yōu)先現(xiàn)場(chǎng)溝通再在平臺(tái)上沉淀結(jié)論。這樣做之后討論密度下降了不少但意見的有效性和采納率反而大幅提升。2.3 評(píng)審粒度和頻率到底多久評(píng)審一次才健康評(píng)審頻率是一個(gè)經(jīng)常被忽視的問題。有些團(tuán)隊(duì)喜歡攢一批大PR再集中評(píng)審美其名曰減少切換開銷實(shí)際上這會(huì)讓評(píng)審者面對(duì)幾百上千行的diff產(chǎn)生嚴(yán)重的認(rèn)知負(fù)擔(dān)。研究數(shù)據(jù)很多人都看過(guò)評(píng)審效率和diff規(guī)模成反比——改動(dòng)行數(shù)超過(guò)400行之后評(píng)審者能發(fā)現(xiàn)的缺陷比例顯著下降。所以設(shè)計(jì)上我會(huì)傾向于把大改動(dòng)拆成多個(gè)小步提交每個(gè)小步都能獨(dú)立構(gòu)建、獨(dú)立測(cè)試再逐個(gè)評(píng)審合入。具體的建議是單次PR改動(dòng)的凈增行數(shù)控制在200到400行以內(nèi)評(píng)審時(shí)間控制在20到30分鐘以內(nèi)。如果一次評(píng)審超過(guò)40分鐘人已經(jīng)處于疲勞狀態(tài)后續(xù)的評(píng)論質(zhì)量會(huì)明顯滑坡。可能有人會(huì)說(shuō)有些feature就是很大怎么拆都拆不開。這時(shí)候我常用的辦法是先合入一個(gè)“空殼結(jié)構(gòu)”——包括接口定義、數(shù)據(jù)模型、基本目錄結(jié)構(gòu)和測(cè)試框架——然后在這個(gè)基礎(chǔ)上每個(gè)功能分支按照依賴順序逐步填充實(shí)現(xiàn)。這樣做既保持了每次diff的可評(píng)審性又避免了一個(gè)巨型分支長(zhǎng)期存在導(dǎo)致的合并沖突。評(píng)審頻率上理想狀態(tài)是每天安排固定的時(shí)間段做review而不是集中在周五下午突擊。團(tuán)隊(duì)成員分布在多個(gè)時(shí)區(qū)的時(shí)候可以設(shè)置兩個(gè)重疊窗口保證每個(gè)PR在24小時(shí)內(nèi)至少有一位評(píng)審人看過(guò)。實(shí)測(cè)下來(lái)這種“小步快跑”的評(píng)審節(jié)奏比隔周一次的大評(píng)審更能發(fā)現(xiàn)缺陷因?yàn)樽髡咴诖a里的上下文還沒有完全忘掉改起來(lái)成本也最低。3. 實(shí)操過(guò)程從提交到合入完整復(fù)盤一次open-code-review3.1 提交前的自檢沒人愿意替你擦屁股開放式評(píng)審不是從別人看你的代碼開始的而是從你自己提交代碼時(shí)就已經(jīng)開始了。很多初級(jí)的開發(fā)者不理解這一點(diǎn)以為review是別人幫自己找錯(cuò)提交代碼跟丟垃圾一樣隨意。真實(shí)情況恰恰相反評(píng)審者第一眼看的是你的自檢痕跡——是不是仔細(xì)思考過(guò)邊界條件是不是自己先跑過(guò)測(cè)試是不是把無(wú)關(guān)的調(diào)試代碼清干凈了。我自己要求團(tuán)隊(duì)在提交PR之前做一個(gè)快速自檢清單這個(gè)改動(dòng)能不能用一句話說(shuō)清楚如果說(shuō)不清楚說(shuō)明改動(dòng)范圍可能太雜需要拆相關(guān)測(cè)試是不是補(bǔ)齊了不僅是新增功能的正常路徑還有邊界條件、異常輸入、兼容性場(chǎng)景有沒有跑過(guò)lint和格式化沒有的話評(píng)審者第一屏看到的就是風(fēng)格問題真正的邏輯問題反而被淹沒提交信息是不是寫明白了好的提交信息應(yīng)該說(shuō)明“為什么改”而不是只寫“改了什么”有沒有留下TODO或者調(diào)試日志有的話清理掉再提這個(gè)自檢清單我自己就踩過(guò)很多次坑。有一次改一個(gè)支付相關(guān)的服務(wù)改動(dòng)本身不大就是調(diào)整一下超時(shí)時(shí)間配置。我提交的時(shí)候沒有寫清楚為什么從3秒改成5秒評(píng)審人問了一句“這個(gè)調(diào)整的依據(jù)是什么”。當(dāng)時(shí)我覺得有點(diǎn)煩后來(lái)線上出現(xiàn)了支付回調(diào)堆積排查下來(lái)就是這個(gè)超時(shí)改動(dòng)引起的。如果我當(dāng)時(shí)在提交說(shuō)明里寫清楚“統(tǒng)計(jì)數(shù)據(jù)表明上游某渠道的響應(yīng)P95已經(jīng)達(dá)到2.8秒需要擴(kuò)大超時(shí)窗口”評(píng)審人一眼就能看出來(lái)這是數(shù)據(jù)驅(qū)動(dòng)的調(diào)整風(fēng)險(xiǎn)評(píng)估的思路也就完全不一樣了。從那以后我對(duì)自檢清單里“提交信息”的權(quán)重放得非常高。3.2 評(píng)審人視角怎么讀diff才能抓住真正的問題站在評(píng)審人的位置上最忌諱的事情是逐行通讀代碼。逐行讀既費(fèi)時(shí)間又會(huì)讓你迷失在細(xì)節(jié)里而忽略了整體設(shè)計(jì)上的缺陷。我一般會(huì)按照下面這個(gè)順序過(guò)一遍PR第一步看標(biāo)題和提交信息。這一步如果你發(fā)現(xiàn)寫得很模糊甚至只有一個(gè)“fix bug”那這本身就是一個(gè)評(píng)審意見——請(qǐng)作者補(bǔ)充背景。因?yàn)楹罄m(xù)任何人翻git歷史的時(shí)候這段潦草的信息都會(huì)讓人摸不著頭腦。第二步看測(cè)試。我有個(gè)習(xí)慣先看測(cè)試再看實(shí)現(xiàn)。因?yàn)闇y(cè)試直接反映了作者對(duì)需求的理解測(cè)試覆蓋了哪些場(chǎng)景遺漏了哪些場(chǎng)景一眼就能看出來(lái)。如果一個(gè)PR聲稱修復(fù)了一個(gè)并發(fā)問題但測(cè)試完全沒有涉及多線程場(chǎng)景那不管實(shí)現(xiàn)代碼長(zhǎng)什么樣這個(gè)修復(fù)都是不可信的。第三步看接口簽名和數(shù)據(jù)流。整個(gè)diff中最先關(guān)注的是對(duì)外暴露的接口有沒有變化數(shù)據(jù)結(jié)構(gòu)是不是合理模塊之間的依賴方向?qū)Σ粚?duì)。如果接口設(shè)計(jì)有問題內(nèi)部的實(shí)現(xiàn)細(xì)看下去基本是一只壞蘋果壞一整筐。第四步看具體實(shí)現(xiàn)。這時(shí)候才逐段讀代碼。讀的過(guò)程中腦子里始終有三個(gè)問題這段代碼在什么情況下會(huì)出錯(cuò)有沒有更簡(jiǎn)單的寫法下一輪迭代如果要加功能在這個(gè)結(jié)構(gòu)上改會(huì)不會(huì)很痛苦第五步寫評(píng)審意見。我給自己定了一個(gè)規(guī)則每條意見必須標(biāo)注類型和優(yōu)先級(jí)。類型分為“設(shè)計(jì)問題”“邏輯問題”“風(fēng)格建議”“疑問”優(yōu)先級(jí)分為“必須修改”“建議修改”“可選優(yōu)化”。不是所有問題都適合用強(qiáng)語(yǔ)氣表述“可選優(yōu)化”類問題如果能加一句“你現(xiàn)在的寫法也沒錯(cuò)但可以考慮xxx因?yàn)閤xx”作者感受到的是切磋而不是批評(píng)。走完這一步你作為評(píng)審人已經(jīng)為這個(gè)PR提供了真正有價(jià)值的輸入。整個(gè)評(píng)審過(guò)程通常在20分鐘左右如果超過(guò)30分鐘依然沒有形成一個(gè)清晰的結(jié)論說(shuō)明這個(gè)PR本身可能太大了需要退回去拆分再來(lái)。3.3 合入后的復(fù)盤評(píng)審意見不能說(shuō)完就完很多團(tuán)隊(duì)做完review就散了意見沉淀在平臺(tái)里再也沒人看。這是對(duì)評(píng)審資產(chǎn)的最大浪費(fèi)。我推薦在每次迭代版本發(fā)布之后花一點(diǎn)時(shí)間對(duì)評(píng)審記錄做一次復(fù)盤從中提煉出三類信息第一類共性缺陷。如果連續(xù)幾個(gè)PR里都出現(xiàn)了對(duì)異常處理不夠重視的問題那就不是某一個(gè)人的問題而是團(tuán)隊(duì)的測(cè)試意識(shí)和代碼習(xí)慣需要提升。把這些共性問題歸類之后可以組織一次短時(shí)間的技術(shù)分享再補(bǔ)幾條lint規(guī)則和測(cè)試模板就能系統(tǒng)性解決。第二類有爭(zhēng)議的討論。Review中出現(xiàn)的無(wú)法達(dá)成一致意見的技術(shù)選型問題非常值得留下來(lái)。因?yàn)檫@說(shuō)明團(tuán)隊(duì)里存在兩種不同的認(rèn)知而這個(gè)問題沒有在當(dāng)下被充分討論清楚。把這些議題收集起來(lái)在架構(gòu)評(píng)審會(huì)上專門安排時(shí)間做決策遠(yuǎn)比在PR下扯皮有效。第三類過(guò)程的效率瓶頸。比如某個(gè)環(huán)節(jié)總是要等到特定同學(xué)有時(shí)間才能繼續(xù)或者某種類型的改動(dòng)總出現(xiàn)高頻率的修改意見。這些瓶頸聽到了就要在流程上做調(diào)整比如補(bǔ)充文檔模板、增加自動(dòng)化檢查。我自己實(shí)踐的復(fù)盤頻率是每?jī)芍芤淮魏偷芷谕健?fù)盤時(shí)間不需要很長(zhǎng)30分鐘左右但這個(gè)動(dòng)作堅(jiān)持下去團(tuán)隊(duì)的代碼質(zhì)量曲線會(huì)在一個(gè)比較高的位置保持平穩(wěn)而不是每隔幾個(gè)月就出現(xiàn)一次質(zhì)量滑坡。4. 常見問題與排查技巧實(shí)錄這些坑我替你踩過(guò)了4.1 問題速查表當(dāng)你的review陷入僵局或者失控我在推行open-code-review的過(guò)程中碰到過(guò)各種奇奇怪怪的情況整理成一個(gè)速查表希望對(duì)同樣在實(shí)踐這個(gè)流程的團(tuán)隊(duì)有參考價(jià)值。癥狀可能原因排查方向與建議PR長(zhǎng)時(shí)間無(wú)人評(píng)審評(píng)審人不夠明確或者大家忙于自己的需求檢查是否配置了自動(dòng)分配規(guī)則是否設(shè)置了48小時(shí)未評(píng)審的提醒必要時(shí)可以約定每天固定時(shí)間統(tǒng)一過(guò)PR評(píng)審意見全是LGTM團(tuán)隊(duì)成員怕得罪人或者評(píng)審流于形式先自查是不是某些意見的處理方式傷害了作者的積極性再定一個(gè)規(guī)則評(píng)審意見必須至少包含一個(gè)實(shí)質(zhì)性問題或明確提問純“LGTM”不算有效評(píng)審評(píng)審意見堆積不更新作者長(zhǎng)期不回應(yīng)評(píng)審人也不跟進(jìn)設(shè)置deadline如果作者確實(shí)沒時(shí)間明確指定一個(gè)協(xié)作者代處理讓PR的狀態(tài)從“待作者”變成“待處理”即可保持流動(dòng)評(píng)審為了一個(gè)風(fēng)格問題爭(zhēng)論不休團(tuán)隊(duì)沒有風(fēng)格規(guī)范或者規(guī)范沒有自動(dòng)化風(fēng)格問題全部交給格式化工具檢查如果工具沒有覆蓋到就補(bǔ)充工具而不是靠評(píng)審人約束評(píng)審意見條數(shù)過(guò)多導(dǎo)致作者崩潰PR范圍太大或者評(píng)審人沒有分類標(biāo)注先把大PR拆分同時(shí)要求評(píng)審人按類型和優(yōu)先級(jí)標(biāo)注意見作者優(yōu)先處理“必須修改”類其余集中到下一輪再議兩個(gè)人對(duì)設(shè)計(jì)方向完全無(wú)法達(dá)成一致缺少?zèng)Q策機(jī)制誰(shuí)都不愿意讓步把爭(zhēng)議搬出PR到會(huì)議上來(lái)討論如果還是無(wú)法達(dá)成一致由架構(gòu)負(fù)責(zé)人拍板并把決策理由記錄下來(lái)新人覺得評(píng)審意見很挫敗評(píng)審語(yǔ)氣過(guò)于生硬缺乏解釋在REVIEW_GUIDE里明確要求“意見必須說(shuō)明理由最好給出例子”團(tuán)隊(duì)內(nèi)約定先用即時(shí)溝通確認(rèn)語(yǔ)氣再在PR里沉淀結(jié)論這個(gè)表不是讓你出了問題再來(lái)看而是建議在推行流程之前就通讀一遍提前意識(shí)到這些局面是常態(tài)不是意外。心態(tài)上能接納這些坑的存在處理起來(lái)反而會(huì)從容很多。4.2 怎么避免評(píng)審變成“形式主義表演”“形式主義表演”是code review最大的敵人沒有之一。具體表現(xiàn)是作者就是把代碼扔上去根本沒仔細(xì)檢查過(guò)評(píng)審人打開頁(yè)面看到什么都習(xí)慣性回一句“l(fā)ooks good”合入之后大家心知肚明根本沒人認(rèn)真看過(guò)。一旦團(tuán)隊(duì)進(jìn)入這種狀態(tài)再好的工具和流程都是廢鐵。我自己的經(jīng)驗(yàn)是想辦法讓評(píng)審“有回音”。最有效的一招是在PR模板里加一個(gè)問題“你在測(cè)試這個(gè)改動(dòng)的時(shí)候手動(dòng)驗(yàn)證過(guò)哪些場(chǎng)景請(qǐng)簡(jiǎn)要列出?！眲e小看這個(gè)字段它會(huì)讓作者在提交之前強(qiáng)制回顧自己的驗(yàn)證過(guò)程。如果作者寫不出任何手動(dòng)驗(yàn)證過(guò)的場(chǎng)景那這個(gè)PR本身就有問題評(píng)審人完全可以順著這個(gè)點(diǎn)深入提問而不是泛泛地看代碼。另一個(gè)有效的做法是隨機(jī)抽查式的復(fù)盤。每個(gè)月找一兩個(gè)已經(jīng)合入的PR不提前通知在周會(huì)上過(guò)一遍當(dāng)時(shí)評(píng)審的完整記錄看看當(dāng)時(shí)提出的“必須修改”類問題是不是真的都改到位了有沒有合入之后反而不符合當(dāng)時(shí)討論意圖的情況。這個(gè)動(dòng)作會(huì)傳遞一個(gè)明確的信號(hào)評(píng)審記錄是會(huì)追溯的不是說(shuō)完就算了。我試過(guò)之后最明顯的變化是評(píng)審意見的嚴(yán)謹(jǐn)度提高了因?yàn)闆]人想在一個(gè)月后被點(diǎn)名復(fù)盤的時(shí)候說(shuō)不出所以然。還有一點(diǎn)要特別提醒不要把自動(dòng)化檢查變成評(píng)審者的偷懶理由。有團(tuán)隊(duì)上了CI和靜態(tài)檢查之后評(píng)審人覺得機(jī)器已經(jīng)查過(guò)了自己就不必細(xì)看。這是個(gè)很危險(xiǎn)的誤區(qū)。自動(dòng)化工具能抓到的只是一小部分模式化問題真正的業(yè)務(wù)邏輯缺陷、設(shè)計(jì)問題、邊界條件遺漏依然要依靠人腦。所以CI應(yīng)該是評(píng)審的前置過(guò)濾器而不是替代者。4.3 打造團(tuán)隊(duì)共識(shí)讓每個(gè)人都愿意被open地評(píng)價(jià)最后說(shuō)一個(gè)偏“軟技能”但特別核心的問題怎么讓團(tuán)隊(duì)成員從心理上接納開放式評(píng)審。代碼是程序員的作品被公開指出問題哪怕是完全善意的方式也會(huì)觸發(fā)天然的防御心理。我在年輕的時(shí)候也經(jīng)歷過(guò)這個(gè)階段當(dāng)時(shí)覺得別人給我提意見就是在否定我的能力現(xiàn)在回頭看這種心理是每個(gè)人都要邁過(guò)的坎。作為制度的推動(dòng)者我可以分享幾個(gè)被驗(yàn)證有效的方法。第一評(píng)審人自己先示范被批評(píng)的正確姿態(tài)。我通常會(huì)在團(tuán)隊(duì)里第一個(gè)提交PR并且故意在一些無(wú)關(guān)緊要的地方留下可優(yōu)化空間然后公開感謝認(rèn)真看代碼的評(píng)審人。這樣做是想傳遞一個(gè)信號(hào)被提出問題是正常且健康的不是丟臉的事。第二把“評(píng)審加分”納入考核導(dǎo)向。雖然不一定和績(jī)效直接掛鉤但至少要讓認(rèn)真做評(píng)審這件事被看見。季度總結(jié)的時(shí)候我會(huì)把每個(gè)人作為評(píng)審人提出的有效意見列出來(lái)無(wú)論職位高低誰(shuí)提了關(guān)鍵的設(shè)計(jì)問題、誰(shuí)阻止了一次線上事故的代碼合入都是值得公開表?yè)P(yáng)的。第三用“我們的代碼”代替“你的代碼”作為默認(rèn)表達(dá)。評(píng)審意見里可以把“你這里寫錯(cuò)了”改成“這部分邏輯我們是不是再確認(rèn)一下”語(yǔ)言習(xí)慣的微調(diào)很多時(shí)候能極大降低對(duì)方的防御心。第四鼓勵(lì)作者在評(píng)審意見下面寫收獲。評(píng)論結(jié)束之后作者可以回一句“這個(gè)建議有效之前我確實(shí)沒有考慮到xxx場(chǎng)景”這種正向反饋循環(huán)會(huì)讓評(píng)審人覺得自己的投入是值得的從而在下一次評(píng)審時(shí)更認(rèn)真。根據(jù)我自己的經(jīng)驗(yàn)從“抗拒評(píng)審”到“主動(dòng)尋求評(píng)審”的團(tuán)隊(duì)氛圍轉(zhuǎn)變至少需要兩到三個(gè)月的時(shí)間。前期的阻力很正常關(guān)鍵在于持續(xù)做對(duì)的事情同時(shí)及時(shí)調(diào)整那些讓參與者感到不公平或者無(wú)意義的細(xì)節(jié)。沒有人愿意在一個(gè)說(shuō)了也白說(shuō)的流程上浪費(fèi)時(shí)間所以要讓每條意見都有去處每個(gè)好的建議都被表?yè)P(yáng)很快大家就會(huì)發(fā)現(xiàn)這其實(shí)是讓自己成長(zhǎng)最快的方式。