1. 從“open-code-review”這個(gè)標(biāo)題說起它到底想解決什么問題第一次看到“open-code-review”這個(gè)標(biāo)題我腦子里蹦出來的第一個(gè)念頭是這大概率不是一個(gè)單純的代碼審查工具而是一套把“審查”這件事從封閉走向開放的機(jī)制設(shè)計(jì)。為什么這么說因?yàn)椤皁pen”這個(gè)詞放在“code review”前面本身就帶著一種態(tài)度——它想打破傳統(tǒng)代碼審查里那種“只有少數(shù)人有權(quán)限看、只有上級(jí)能拍板”的封閉感讓審查過程、審查標(biāo)準(zhǔn)、審查結(jié)果都變得可被更多人看見、參與和復(fù)用。我在一線帶過不少項(xiàng)目也參與過各種規(guī)模的代碼評(píng)審。說實(shí)話絕大多數(shù)團(tuán)隊(duì)對(duì)“代碼審查”這件事是又愛又恨。愛的是它確實(shí)能攔住不少低級(jí)錯(cuò)誤恨的是它經(jīng)常變成走過場(chǎng)要么是提交者自己點(diǎn)個(gè)“通過”要么是評(píng)審人掃兩眼就放行真正有價(jià)值的討論少之又少。而“open-code-review”這個(gè)標(biāo)題背后我理解它想做的是把審查這件事變成一個(gè)開放、透明、可追溯、可協(xié)作的流程讓代碼質(zhì)量不再依賴某一個(gè)人的責(zé)任心而是靠機(jī)制來兜底。這個(gè)內(nèi)容適合誰來參考我覺得有三類人最值得看第一類是正在搭建團(tuán)隊(duì)代碼規(guī)范的技術(shù)負(fù)責(zé)人你需要一套能落地的審查機(jī)制而不是一堆寫在文檔里沒人看的規(guī)則第二類是剛進(jìn)入?yún)f(xié)作開發(fā)環(huán)境的開發(fā)者你想知道自己的代碼會(huì)被怎么審、該怎么準(zhǔn)備、怎么回應(yīng)評(píng)審意見第三類是對(duì)工程效率感興趣的產(chǎn)品或項(xiàng)目管理者你想理解為什么代碼審查值得投入時(shí)間以及怎么衡量它到底有沒有產(chǎn)生價(jià)值。接下來我會(huì)從整體設(shè)計(jì)思路、核心細(xì)節(jié)、實(shí)操流程、常見問題幾個(gè)維度把這個(gè)標(biāo)題背后的東西拆開講清楚。所有內(nèi)容都基于我在實(shí)際項(xiàng)目中反復(fù)驗(yàn)證過的做法能直接抄作業(yè)的地方我會(huì)給到具體參數(shù)和步驟踩過的坑我也會(huì)原樣告訴你。2. 整體設(shè)計(jì)與思路拆解為什么“開放”才是代碼審查的破局點(diǎn)2.1 傳統(tǒng)代碼審查的三個(gè)死結(jié)在聊“open-code-review”的設(shè)計(jì)思路之前得先把傳統(tǒng)代碼審查的問題說透不然你沒法理解為什么“開放”這個(gè)方向是對(duì)的。我總結(jié)下來傳統(tǒng)模式有三個(gè)繞不開的死結(jié)。第一個(gè)死結(jié)是信息不對(duì)稱。提交代碼的人知道自己的改動(dòng)意圖但評(píng)審人往往只看到 diff不知道上下文。結(jié)果就是評(píng)審人問的問題提交者覺得“這不是明擺著的嗎”提交者寫的代碼評(píng)審人覺得“這寫的什么鬼”。雙方都在猜效率極低。第二個(gè)死結(jié)是責(zé)任稀釋。一個(gè)倉(cāng)庫(kù)如果只有兩三個(gè)人有評(píng)審權(quán)限那這幾個(gè)人就成了瓶頸。他們忙的時(shí)候?qū)彶榫头e壓他們不忙的時(shí)候?qū)彶榫筒萋?。更麻煩的是一旦出了問題很難追溯到“當(dāng)時(shí)是誰放行的、依據(jù)是什么”。第三個(gè)死結(jié)是標(biāo)準(zhǔn)不統(tǒng)一。同一個(gè)團(tuán)隊(duì)里A評(píng)審人覺得變量命名要駝峰B評(píng)審人覺得下劃線也行C評(píng)審人根本不在乎命名。提交者每次都要猜這次會(huì)遇到哪個(gè)評(píng)審人體驗(yàn)非常割裂。“open-code-review”這個(gè)標(biāo)題給我的啟發(fā)是它想用“開放”來同時(shí)解決這三個(gè)問題。開放意味著信息透明、責(zé)任明確、標(biāo)準(zhǔn)統(tǒng)一。具體怎么落地往下看。2.2 開放審查機(jī)制的四個(gè)核心設(shè)計(jì)原則基于我對(duì)這個(gè)標(biāo)題的理解一套真正能跑起來的開放代碼審查機(jī)制應(yīng)該遵循四個(gè)原則。這四個(gè)原則不是拍腦袋想的是我在多個(gè)項(xiàng)目里試錯(cuò)之后沉淀下來的。原則一審查入口開放但審查標(biāo)準(zhǔn)前置。意思是任何人都可以發(fā)起審查、參與討論但“什么算通過”這件事必須在提交之前就寫清楚。我見過太多團(tuán)隊(duì)把標(biāo)準(zhǔn)藏在評(píng)審人腦子里結(jié)果就是每次審查都像開盲盒。正確的做法是把檢查項(xiàng)做成清單提交者自己先過一遍評(píng)審人再對(duì)照清單確認(rèn)。原則二審查過程留痕結(jié)論可追溯。每一條評(píng)審意見、每一次修改、每一個(gè)通過決定都要有記錄。這不是為了追責(zé)而是為了讓后來的人能看懂“為什么當(dāng)時(shí)這么改”。我試過用純聊天工具做審查三個(gè)月后回頭看完全想不起來當(dāng)時(shí)為什么否掉了一個(gè)方案。后來改成結(jié)構(gòu)化記錄效率提升非常明顯。原則三審查粒度可控避免大塊提交。一個(gè)提交如果改了三十個(gè)文件評(píng)審人根本沒法認(rèn)真看。開放審查的前提是提交本身要足夠小、足夠聚焦。我一般建議單個(gè)審查請(qǐng)求控制在400行以內(nèi)的有效改動(dòng)超過這個(gè)數(shù)就拆成多個(gè)。原則四審查結(jié)果可復(fù)用形成知識(shí)沉淀。每次審查中發(fā)現(xiàn)的典型問題、達(dá)成的共識(shí)都應(yīng)該沉淀成團(tuán)隊(duì)可查的規(guī)則或案例。這樣新人進(jìn)來不用從頭踩坑老問題也不會(huì)反復(fù)出現(xiàn)。2.3 為什么選擇“開放”而不是“收緊”有人可能會(huì)問代碼審查不是越嚴(yán)格越好嗎為什么要強(qiáng)調(diào)“開放”我的理解是嚴(yán)格和開放并不矛盾。嚴(yán)格指的是標(biāo)準(zhǔn)執(zhí)行要嚴(yán)開放指的是參與面和信息面要廣。一個(gè)只有三個(gè)人能看代碼的團(tuán)隊(duì)再嚴(yán)格也只是三個(gè)人的嚴(yán)格一個(gè)所有人都能看、都能提意見的團(tuán)隊(duì)嚴(yán)格才是真正的嚴(yán)格。而且從實(shí)際效果看開放審查還有一個(gè)隱性好處它能倒逼提交者更認(rèn)真。你知道你的代碼會(huì)被很多人看到你自然會(huì)更注意命名、注釋、邊界處理。這種“被看見”的壓力比任何規(guī)章制度都管用。3. 核心細(xì)節(jié)解析與實(shí)操要點(diǎn)把開放審查拆成可執(zhí)行的步驟3.1 審查請(qǐng)求的標(biāo)準(zhǔn)化模板要讓審查開放起來第一步是統(tǒng)一“提交審查”這個(gè)動(dòng)作的格式。我一般會(huì)要求每個(gè)審查請(qǐng)求包含五個(gè)部分缺一不可。改動(dòng)背景一句話說清楚為什么要改關(guān)聯(lián)的需求或問題是什么。改動(dòng)范圍列出涉及的文件和模塊讓評(píng)審人快速判斷影響面。核心邏輯用三到五句話說明關(guān)鍵實(shí)現(xiàn)思路特別是那些不看代碼就理解不了的設(shè)計(jì)決策。自測(cè)情況說明本地跑了哪些測(cè)試、覆蓋了哪些場(chǎng)景、有沒有已知的遺留問題。審查重點(diǎn)主動(dòng)指出自己不確定的地方請(qǐng)?jiān)u審人重點(diǎn)看。這個(gè)模板看起來簡(jiǎn)單但實(shí)際用起來效果非常明顯。我做過對(duì)比用了模板的審查請(qǐng)求平均評(píng)審時(shí)間縮短了將近四成因?yàn)樵u(píng)審人不用再花時(shí)間猜上下文了。注意審查重點(diǎn)這一項(xiàng)很多人會(huì)忽略覺得“我要是知道哪里有問題不就自己改了”。但實(shí)際情況是提交者往往對(duì)某些邊界情況心里沒底主動(dòng)標(biāo)出來反而能讓評(píng)審更聚焦。3.2 評(píng)審人的選擇與輪換機(jī)制開放審查不等于隨便拉人來看。評(píng)審人的選擇有幾個(gè)實(shí)操要點(diǎn)。首先是領(lǐng)域匹配。改動(dòng)涉及支付邏輯就至少要有一個(gè)熟悉支付模塊的人參與。但這不意味著只有他能看其他人也可以看只是他的意見權(quán)重更高。其次是人數(shù)控制。我試過拉五個(gè)人評(píng)審結(jié)果就是互相等誰都不好意思先表態(tài)。后來固定為兩到三人其中一人是主評(píng)審負(fù)責(zé)最終確認(rèn)其他人提供補(bǔ)充意見。這個(gè)配置在效率和覆蓋面之間平衡得最好。最后是輪換機(jī)制。如果每次都是同一批人評(píng)審很容易形成思維定式。我會(huì)定期輪換評(píng)審人讓不同背景的人參與進(jìn)來。新人評(píng)審雖然經(jīng)驗(yàn)少但往往能發(fā)現(xiàn)老手忽略的問題因?yàn)樗麄儧]有“一直都是這么寫的”這種慣性。3.3 審查意見的表達(dá)規(guī)范開放審查最大的挑戰(zhàn)之一是溝通。代碼審查里的很多沖突其實(shí)不是技術(shù)分歧而是表達(dá)方式的問題。我總結(jié)了幾條表達(dá)規(guī)范團(tuán)隊(duì)里推行之后審查氛圍明顯好了很多。對(duì)事不對(duì)人說“這個(gè)變量名在調(diào)用處容易歧義”而不是“你命名能不能走點(diǎn)心”。給出理由說“建議加空值判斷因?yàn)樯嫌谓涌谠诔瑫r(shí)情況下會(huì)返回空”而不是“這里要加判斷”。區(qū)分必須和建議必須改的用明確語氣建議性的用“可以考慮”“我個(gè)人傾向”。允許反駁評(píng)審意見不是圣旨提交者如果有充分理由可以討論甚至推翻。這幾條看起來是軟技能但在開放審查里是硬要求。因?yàn)閰⑴c的人多了溝通成本會(huì)指數(shù)級(jí)上升沒有規(guī)范根本跑不下去。3.4 審查通過的判定標(biāo)準(zhǔn)什么算“審查通過”這個(gè)問題如果不提前定義清楚開放審查就會(huì)變成無休止的討論。我的做法是設(shè)定三個(gè)硬性條件全部滿足才算通過。條件說明檢查方式無阻塞性問題沒有必須修改的邏輯錯(cuò)誤、安全問題、性能隱患主評(píng)審確認(rèn)關(guān)鍵意見已回應(yīng)所有標(biāo)記為“必須改”的意見都已處理或達(dá)成共識(shí)逐條核對(duì)自測(cè)證據(jù)完整提交者提供了可驗(yàn)證的測(cè)試結(jié)果查看自測(cè)記錄這三個(gè)條件里第一條是底線第二條是流程第三條是證據(jù)。三者缺一不可。我見過很多團(tuán)隊(duì)只滿足第一條就放行結(jié)果就是同樣的問題反復(fù)出現(xiàn)因?yàn)橐庖姏]有被真正閉環(huán)。4. 實(shí)操過程與核心環(huán)節(jié)實(shí)現(xiàn)一次完整的開放審查長(zhǎng)什么樣4.1 提交前的自檢清單在發(fā)起審查之前提交者需要先過一遍自檢清單。這個(gè)清單我建議做成固定模板每次提交時(shí)逐項(xiàng)確認(rèn)。以下是我在實(shí)際項(xiàng)目中用的版本你可以直接參考。[ ] 改動(dòng)是否聚焦單一目標(biāo)沒有夾帶無關(guān)修改 [ ] 有效改動(dòng)行數(shù)是否控制在400行以內(nèi) [ ] 新增或修改的邏輯是否有對(duì)應(yīng)的測(cè)試覆蓋 [ ] 變量命名是否清晰沒有縮寫歧義 [ ] 邊界條件是否處理包括空值、超時(shí)、并發(fā) [ ] 日志和錯(cuò)誤信息是否足夠定位問題 [ ] 是否有硬編碼的配置或密鑰 [ ] 文檔和注釋是否同步更新這個(gè)清單看起來有點(diǎn)長(zhǎng)但熟練之后五分鐘就能過完。關(guān)鍵是它能攔住大部分低級(jí)問題讓評(píng)審人把精力放在真正需要討論的地方。4.2 發(fā)起審查請(qǐng)求的具體操作自檢通過后就可以發(fā)起審查請(qǐng)求了。具體操作分四步。第一步創(chuàng)建審查記錄。不管用什么工具核心是有一個(gè)結(jié)構(gòu)化的記錄載體包含前面說的五個(gè)部分。我一般用項(xiàng)目管理系統(tǒng)里的任務(wù)卡片或者代碼平臺(tái)自帶的審查功能。第二步指定評(píng)審人。按照領(lǐng)域匹配和輪換機(jī)制選兩到三人明確誰是主評(píng)審。指定的時(shí)候要說明為什么選他們比如“這次改動(dòng)涉及緩存策略請(qǐng)熟悉這塊的同學(xué)重點(diǎn)看”。第三步設(shè)置響應(yīng)時(shí)限。開放審查不等于無限期等待。我一般設(shè)定主評(píng)審在24小時(shí)內(nèi)給出初步意見緊急改動(dòng)縮短到4小時(shí)。時(shí)限不是為了讓評(píng)審人草率而是為了讓大家有預(yù)期避免提交者干等。第四步同步相關(guān)方。如果改動(dòng)會(huì)影響其他模塊要主動(dòng)通知相關(guān)同學(xué)。這一步很多人會(huì)漏結(jié)果就是改完之后別人一臉懵。4.3 評(píng)審過程中的互動(dòng)與記錄評(píng)審開始后互動(dòng)方式直接決定審查質(zhì)量。我觀察下來高效的評(píng)審互動(dòng)有幾個(gè)共同特征。一是逐條回應(yīng)。評(píng)審人提了五條意見提交者就逐條回應(yīng)不要合并成一句“都改了”。逐條回應(yīng)能讓評(píng)審人確認(rèn)每條都被認(rèn)真對(duì)待了。二是區(qū)分討論和修改。有些意見需要討論清楚再改有些可以直接改。我一般建議先討論有分歧的達(dá)成共識(shí)后再統(tǒng)一修改避免改來改去。三是及時(shí)同步進(jìn)展。如果修改需要時(shí)間要在審查記錄里說明預(yù)計(jì)完成時(shí)間不要讓評(píng)審人干等。四是記錄關(guān)鍵決策。討論中達(dá)成的共識(shí)比如“這里暫時(shí)不加緩存后續(xù)單獨(dú)優(yōu)化”要明確記錄下來避免下次又被提出來。4.4 審查通過后的收尾動(dòng)作審查通過不是終點(diǎn)還有幾個(gè)收尾動(dòng)作要做。首先是合并代碼。合并前再確認(rèn)一次目標(biāo)分支是否正確避免合錯(cuò)地方。我踩過這個(gè)坑一次改動(dòng)合到了發(fā)布分支導(dǎo)致緊急回滾。其次是更新審查記錄狀態(tài)。把審查記錄標(biāo)記為已完成附上合并的提交標(biāo)識(shí)方便后續(xù)追溯。然后是沉淀知識(shí)。如果這次審查發(fā)現(xiàn)了新的典型問題或者達(dá)成了新的共識(shí)要更新到團(tuán)隊(duì)的審查規(guī)則或案例庫(kù)里。這一步是開放審查能持續(xù)進(jìn)化的關(guān)鍵。最后是感謝評(píng)審人。聽起來是小事但開放審查依賴的是大家的自愿投入一句真誠(chéng)的感謝能讓這個(gè)機(jī)制走得更遠(yuǎn)。5. 常見問題與排查技巧實(shí)錄開放審查踩過的坑5.1 審查意見遲遲沒有回應(yīng)怎么辦這是開放審查最常見的問題。我的排查思路分三層。第一層檢查是不是評(píng)審人太忙。如果是就調(diào)整評(píng)審人配置增加備選人或者把大改動(dòng)拆小降低單次評(píng)審負(fù)擔(dān)。第二層檢查是不是審查請(qǐng)求本身不清楚。如果提交者沒寫清楚背景和重點(diǎn)評(píng)審人不知道從哪看起自然就拖了。這時(shí)候要補(bǔ)充信息重新發(fā)起。第三層檢查是不是機(jī)制問題。如果每次都要催說明響應(yīng)時(shí)限沒有真正執(zhí)行。我一般會(huì)在團(tuán)隊(duì)里明確超過時(shí)限未響應(yīng)的提交者可以主動(dòng)升級(jí)找備選評(píng)審人或技術(shù)負(fù)責(zé)人介入。5.2 評(píng)審意見分歧太大怎么處理分歧不可怕可怕的是分歧沒有出口。我的處理原則是先對(duì)齊事實(shí)再對(duì)齊目標(biāo)最后才討論方案。對(duì)齊事實(shí)是指雙方先把“這段代碼實(shí)際會(huì)怎么執(zhí)行”搞清楚。很多分歧其實(shí)是因?yàn)閷?duì)代碼行為的理解不同把事實(shí)對(duì)齊了分歧自然消失。對(duì)齊目標(biāo)是指確認(rèn)這次改動(dòng)到底要解決什么問題。如果目標(biāo)不一致那討論方案就是雞同鴨講。最后討論方案時(shí)如果還是無法達(dá)成一致就由主評(píng)審做決定并記錄決策理由。開放審查不是無限民主最終還是要有人拍板。5.3 審查流于形式怎么破流于形式的典型表現(xiàn)是評(píng)審人只回“看起來沒問題”提交者只回“已修改”。要破這個(gè)局我有幾個(gè)實(shí)操技巧。一是隨機(jī)抽查。技術(shù)負(fù)責(zé)人定期抽查已通過的審查記錄看看評(píng)審意見的質(zhì)量。不是為了追責(zé)而是為了發(fā)現(xiàn)機(jī)制漏洞。二是設(shè)置最低互動(dòng)要求。比如要求每個(gè)評(píng)審人至少提出一條實(shí)質(zhì)性意見或者明確說明“無意見”的理由。這能逼著評(píng)審人認(rèn)真看。三是用數(shù)據(jù)說話。統(tǒng)計(jì)每個(gè)審查請(qǐng)求的平均意見數(shù)、修改輪次、問題發(fā)現(xiàn)率。如果某個(gè)模塊的審查總是零意見要么是代碼真的完美要么是審查沒到位大概率是后者。5.4 常見問題速查表問題現(xiàn)象可能原因排查動(dòng)作解決建議審查請(qǐng)求無人響應(yīng)評(píng)審人配置不當(dāng)或時(shí)限未執(zhí)行檢查評(píng)審人負(fù)載和響應(yīng)記錄增加備選評(píng)審人明確時(shí)限升級(jí)機(jī)制審查意見反復(fù)拉扯目標(biāo)未對(duì)齊或表達(dá)不規(guī)范回顧討論記錄確認(rèn)分歧點(diǎn)先對(duì)齊事實(shí)和目標(biāo)再討論方案審查通過后仍出問題自測(cè)不充分或?qū)彶闃?biāo)準(zhǔn)執(zhí)行不嚴(yán)檢查自測(cè)記錄和審查清單強(qiáng)化自測(cè)要求主評(píng)審嚴(yán)格把關(guān)審查記錄難以追溯記錄格式不統(tǒng)一或未結(jié)構(gòu)化檢查歷史記錄完整性統(tǒng)一模板強(qiáng)制結(jié)構(gòu)化記錄新人參與度低缺乏引導(dǎo)或意見不被重視觀察新人評(píng)審互動(dòng)情況安排導(dǎo)師帶教明確新人意見權(quán)重5.5 幾個(gè)獨(dú)家避坑技巧最后分享幾個(gè)我在實(shí)操中總結(jié)的避坑技巧都是常規(guī)文檔里不會(huì)寫的。技巧一審查請(qǐng)求不要在下班前發(fā)。我試過好幾次下班前發(fā)的審查請(qǐng)求第二天早上基本被淹沒在消息里。最佳發(fā)送時(shí)間是上午十點(diǎn)左右評(píng)審人有整塊時(shí)間看。技巧二大改動(dòng)拆成多個(gè)小審查但保持關(guān)聯(lián)。拆是為了好審關(guān)聯(lián)是為了不丟上下文。我一般會(huì)在每個(gè)小審查里注明“這是某某大改動(dòng)的第幾部分”并附上整體設(shè)計(jì)說明的鏈接。技巧三給評(píng)審人留“不看的權(quán)利”。如果某個(gè)評(píng)審人明確表示對(duì)某塊不熟悉不要強(qiáng)求他看。開放審查的核心是讓合適的人看合適的內(nèi)容而不是讓所有人看所有內(nèi)容。技巧四定期回顧審查數(shù)據(jù)。我每個(gè)月會(huì)花半小時(shí)看一下這個(gè)月的審查統(tǒng)計(jì)平均意見數(shù)、平均修改輪次、問題類型分布。這些數(shù)據(jù)能告訴你團(tuán)隊(duì)的代碼質(zhì)量趨勢(shì)比任何主觀感受都準(zhǔn)。技巧五把審查當(dāng)成教學(xué)機(jī)會(huì)。新人提交的代碼評(píng)審時(shí)多解釋“為什么這么改”而不是只說“這么改”。一次好的審查抵得上十次培訓(xùn)。這也是開放審查最有價(jià)值的副產(chǎn)品——它讓知識(shí)在團(tuán)隊(duì)里流動(dòng)起來。6. 開放審查的擴(kuò)展玩法從單次審查到持續(xù)質(zhì)量改進(jìn)6.1 建立團(tuán)隊(duì)審查規(guī)則庫(kù)單次審查結(jié)束后把發(fā)現(xiàn)的典型問題和達(dá)成的共識(shí)沉淀下來慢慢就形成了一個(gè)規(guī)則庫(kù)。這個(gè)規(guī)則庫(kù)不是死的文檔而是活的案例集。我一般按模塊分類每個(gè)條目包含問題描述、正確做法、實(shí)際案例鏈接。新人進(jìn)來先看規(guī)則庫(kù)能避開大部分常見坑。規(guī)則庫(kù)的維護(hù)也有講究。我建議每季度回顧一次把過時(shí)的規(guī)則刪掉把新出現(xiàn)的問題加進(jìn)去。規(guī)則庫(kù)如果只增不減很快就會(huì)變成沒人看的擺設(shè)。6.2 用審查數(shù)據(jù)驅(qū)動(dòng)流程優(yōu)化審查過程中產(chǎn)生的數(shù)據(jù)比如意見數(shù)、修改輪次、問題類型都是優(yōu)化流程的依據(jù)。我試過用這些數(shù)據(jù)做了一次分析發(fā)現(xiàn)某個(gè)模塊的審查意見集中在命名規(guī)范上說明這個(gè)模塊的命名確實(shí)混亂后來專門做了一次重構(gòu)后續(xù)審查意見明顯減少。數(shù)據(jù)分析不需要多復(fù)雜簡(jiǎn)單的統(tǒng)計(jì)和對(duì)比就能發(fā)現(xiàn)很多問題。關(guān)鍵是養(yǎng)成定期看的習(xí)慣而不是憑感覺判斷。6.3 把開放審查延伸到設(shè)計(jì)階段代碼審查是最后一道防線但很多問題其實(shí)在設(shè)計(jì)階段就埋下了。我后來嘗試把開放審查的思路往前延伸在設(shè)計(jì)方案階段就拉相關(guān)人一起看。這樣代碼審查時(shí)大家已經(jīng)對(duì)設(shè)計(jì)有共識(shí)討論效率高很多。具體做法是重大改動(dòng)先寫一頁(yè)設(shè)計(jì)說明包含背景、目標(biāo)、方案、影響面然后拉一個(gè)短會(huì)過一遍。這個(gè)會(huì)不需要正式評(píng)審就是讓大家提前知道要改什么有意見提前提。我實(shí)測(cè)下來這一步能讓后續(xù)代碼審查的意見數(shù)減少三成左右因?yàn)榇蠓较蛞呀?jīng)對(duì)齊了。6.4 開放審查與新人培養(yǎng)的結(jié)合開放審查還有一個(gè)我特別看重的價(jià)值它是新人成長(zhǎng)最快的通道之一。新人通過看別人的審查討論能快速理解團(tuán)隊(duì)的代碼標(biāo)準(zhǔn)和設(shè)計(jì)思路通過參與評(píng)審能鍛煉技術(shù)判斷力和溝通能力。我一般會(huì)讓新人在入職第一個(gè)月就參與評(píng)審但先從簡(jiǎn)單的改動(dòng)開始并且安排導(dǎo)師在旁邊指導(dǎo)。新人提的意見導(dǎo)師幫忙把關(guān)合適的就發(fā)出去不合適的就解釋為什么。這樣新人既有參與感又不會(huì)因?yàn)樘崃瞬怀墒斓囊庖姸艽?。這個(gè)機(jī)制跑順之后團(tuán)隊(duì)的代碼質(zhì)量會(huì)進(jìn)入一個(gè)正向循環(huán)審查越開放參與的人越多參與的人越多標(biāo)準(zhǔn)越統(tǒng)一標(biāo)準(zhǔn)越統(tǒng)一審查效率越高。最終受益的是整個(gè)團(tuán)隊(duì)而不是某一個(gè)人。我個(gè)人在實(shí)際操作中的體會(huì)是開放代碼審查最難的不是工具也不是流程而是讓每個(gè)人都真正相信“我的意見有價(jià)值”。這個(gè)信任建立起來需要時(shí)間但一旦建立起來它帶來的質(zhì)量提升和團(tuán)隊(duì)凝聚力遠(yuǎn)超任何技術(shù)手段。如果你正在考慮推行開放審查我的建議是從一個(gè)小模塊開始先跑通一個(gè)完整的閉環(huán)拿到實(shí)際效果之后再逐步擴(kuò)大。不要一上來就全團(tuán)隊(duì)鋪開那樣很容易因?yàn)槌跗诘牟豁槙扯舱邸?