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