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