好的我們這就開(kāi)始寫這篇實(shí)戰(zhàn)導(dǎo)向的博文。1. 為什么公開(kāi)做代碼評(píng)審比審查代碼更難也更值得做open-code-review這個(gè)話題乍一看像是把日常的代碼評(píng)審Code Review流程開(kāi)源或者公開(kāi)化但我在實(shí)際推動(dòng)過(guò)幾次之后發(fā)現(xiàn)它真正的內(nèi)核不在于代碼而在于open這個(gè)詞帶來(lái)的心態(tài)、流程和協(xié)作方式的轉(zhuǎn)變。傳統(tǒng)意義上代碼評(píng)審?fù)划?dāng)成上線前的關(guān)卡——寫完了丟給同事或?qū)熆匆谎鄞_認(rèn)沒(méi)有低級(jí)錯(cuò)誤然后合并、發(fā)布。這種模式的問(wèn)題在于評(píng)審變成了挑刺提交代碼的人處于防御姿態(tài)評(píng)審的人則在扮演質(zhì)檢員。結(jié)果是什么評(píng)審流于形式comments集中在代碼風(fēng)格、命名規(guī)范這些表面問(wèn)題上真正涉及架構(gòu)設(shè)計(jì)、邏輯邊界、潛在性能風(fēng)險(xiǎn)的討論少之又少。而且評(píng)審記錄散落在不同的Pull RequestPR里難以沉淀成團(tuán)隊(duì)的知識(shí)資產(chǎn)。我自己參與過(guò)多個(gè)團(tuán)隊(duì)從兩三個(gè)人的小組到幾十人的大項(xiàng)目一個(gè)很深的體會(huì)是代碼評(píng)審的價(jià)值完全取決于透明和開(kāi)放的程度。所謂open-code-review就是要把評(píng)審從一個(gè)私密的、帶著權(quán)威色彩的檢查過(guò)程變成一個(gè)公開(kāi)的、平等的、以學(xué)習(xí)為目的的研討過(guò)程。所有參與者都能看到完整的上下文評(píng)審意見(jiàn)可以被公開(kāi)討論和反駁甚至允許吃瓜群眾沒(méi)有直接參與該功能開(kāi)發(fā)的同事來(lái)提問(wèn)。這種模式一旦跑通團(tuán)隊(duì)的整體工程能力會(huì)以肉眼可見(jiàn)的速度提升。這篇文章我打算結(jié)合我嘗試過(guò)的方案和踩過(guò)的坑從評(píng)審該看什么、流程怎么定、工具怎么搭、以及怎么應(yīng)對(duì)團(tuán)隊(duì)里的抵觸情緒這幾個(gè)維度聊聊怎么把一個(gè)普通的代碼評(píng)審真正變成開(kāi)放、高效、大家都有收獲的團(tuán)隊(duì)儀式。如果你正在為評(píng)審總是走過(guò)場(chǎng)代碼越寫越亂沒(méi)人敢動(dòng)這類問(wèn)題頭疼或者你想在團(tuán)隊(duì)里建立一種更健康的工程文化這篇文章應(yīng)該能給你不少可直接落地的參考。2. 一次有效的評(píng)審到底該盯住哪些維度的代碼很多剛做評(píng)審的同學(xué)最喜歡問(wèn)我看完他的代碼了也提了comment但都是關(guān)于變量命名的總感覺(jué)沒(méi)說(shuō)到點(diǎn)子上怎么辦這很正常因?yàn)槿绻麤](méi)有人告訴你該看什么你當(dāng)然只能看到最表面的東西。開(kāi)放的評(píng)審第一步不是開(kāi)PR而是所有人包括作者自己對(duì)評(píng)審清單達(dá)成共識(shí)。2.1 從能跑到能扛關(guān)注邏輯正確性與邊界條件我最看重的是代碼能不能處理意外。很多代碼在正常路徑下跑得飛快但一到邊界就露怯。評(píng)審時(shí)我會(huì)下意識(shí)地去拆解這個(gè)函數(shù)或模塊的對(duì)外契約它宣稱自己接受什么類型的輸入那么空值、越界、超長(zhǎng)字符串、并發(fā)沖突、超時(shí)這些不合格的輸入進(jìn)來(lái)代碼是優(yōu)雅降級(jí)還是直接拋出一個(gè)讓用戶摸不著頭腦的500錯(cuò)誤有一次我們做一個(gè)訂單狀態(tài)流轉(zhuǎn)的模塊新同學(xué)實(shí)現(xiàn)的邏輯在正常的狀態(tài)跳轉(zhuǎn)A→B→C時(shí)毫無(wú)問(wèn)題review時(shí)我特意問(wèn)了一句如果用戶在D狀態(tài)已取消下客戶端因?yàn)槟承┭舆t操作發(fā)起一個(gè)B→C的請(qǐng)求你這里會(huì)怎樣他回去一查發(fā)現(xiàn)代碼根本沒(méi)有處理這種非法狀態(tài)遷移結(jié)果就是數(shù)據(jù)被覆蓋訂單金額差點(diǎn)錯(cuò)亂。這就是邊界條件的作用。評(píng)審的時(shí)候多問(wèn)幾個(gè)如果...會(huì)怎樣比多記幾個(gè)抽象類名有用一萬(wàn)倍。2.2 從能讀到能改可維護(hù)性的隱性指標(biāo)可維護(hù)性聽(tīng)起來(lái)虛實(shí)際上有非常具體的衡量標(biāo)準(zhǔn)一個(gè)新加入的同學(xué)在不問(wèn)任何人的情況下能不能通過(guò)讀代碼和測(cè)試快速定位某個(gè)業(yè)務(wù)規(guī)則是在哪里實(shí)現(xiàn)的、改動(dòng)它會(huì)影響哪些下游所以我評(píng)審時(shí)會(huì)刻意關(guān)注命名和結(jié)構(gòu)。變量名是否傳達(dá)意圖而不是糾結(jié)于名字長(zhǎng)短函數(shù)是否只做一件事內(nèi)聚性強(qiáng)不強(qiáng)模塊之間的依賴方向是否清晰有沒(méi)有出現(xiàn)底層依賴高層這種反模式。如果一段代碼要跳三層文件才能看懂一個(gè)字段的來(lái)源或者一個(gè)Controller里塞了七八種互不相干的邏輯那我一定會(huì)打回去重寫。這看起來(lái)是在難為提交者實(shí)際上是在為未來(lái)的維護(hù)者包括未來(lái)的自己省時(shí)間。我常跟團(tuán)隊(duì)說(shuō)一句話代碼被閱讀的次數(shù)一定比被編寫的次數(shù)多一個(gè)數(shù)量級(jí)值得花心思優(yōu)化。評(píng)審時(shí)多問(wèn)幾句這段代碼以后誰(shuí)維護(hù)很多表面爭(zhēng)論瞬間就清晰了。2.3 安全、性能與可觀測(cè)性容易被忽略的隱形負(fù)債安全不是安全工程師一個(gè)人的事性能也不是性能測(cè)試專員的事。開(kāi)放評(píng)審中最有價(jià)值的部分就是不同背景的人從各自角度出發(fā)有意無(wú)意地暴露那些隱藏的問(wèn)題。我在評(píng)審清單里加了三個(gè)必查項(xiàng)第一這個(gè)改動(dòng)會(huì)不會(huì)引入不可信的外部輸入HTTP參數(shù)、用戶上傳、第三方回調(diào)并且有沒(méi)有經(jīng)過(guò)合理的校驗(yàn)SQL語(yǔ)句是參數(shù)化的還是字符串拼接的第二這個(gè)改動(dòng)的時(shí)間復(fù)雜度是否合理會(huì)不會(huì)在數(shù)據(jù)量增長(zhǎng)10倍后級(jí)聯(lián)拖垮其他模塊有沒(méi)有不必要的前端輪詢或重復(fù)的數(shù)據(jù)庫(kù)查詢第三關(guān)鍵的路徑有沒(méi)有日志出了錯(cuò)能不能追根溯源監(jiān)控告警能不能覆蓋到這次改動(dòng)引入的新場(chǎng)景有一次我們上線了一個(gè)看似無(wú)害的導(dǎo)出報(bào)表功能review時(shí)大家都關(guān)注了格式是否正確。我隨口問(wèn)了一句關(guān)聯(lián)查詢有沒(méi)有加索引覆蓋結(jié)果一查全表掃描數(shù)據(jù)量一上來(lái)三分鐘超時(shí)。后來(lái)補(bǔ)了索引、加了異步任務(wù)才避免了一次線上事故。這些細(xì)節(jié)看不看結(jié)果天差地別。3. 什么樣的代碼值得被開(kāi)放評(píng)審一份實(shí)用的拒絕清單開(kāi)放不意味著所有的代碼都要拉個(gè)評(píng)審會(huì)或者每個(gè)PR都必須有4個(gè)人以上點(diǎn)贊。這既不現(xiàn)實(shí)也會(huì)把評(píng)審變成繁文縟節(jié)。我實(shí)際操作下來(lái)一個(gè)健康的規(guī)則是關(guān)鍵代碼、接口變更、公共模塊、影響面大的改動(dòng)必須走開(kāi)放評(píng)審而文檔調(diào)整、簡(jiǎn)單的字典映射、純配置修改可以走輕量流程甚至直接合并。那么在開(kāi)放評(píng)審里最容易被忽視、又最值得拿出來(lái)公開(kāi)討論的是哪些類型呢我整理一份開(kāi)放評(píng)審核心對(duì)象清單供你參考代碼類型開(kāi)放評(píng)審價(jià)值點(diǎn)誰(shuí)必須參與接口設(shè)計(jì)與跨服務(wù)契約有沒(méi)有前后端不一致、字段命名混亂、兼容性考慮缺失后端、前端、測(cè)試架構(gòu)/模塊邊界調(diào)整依賴方向是否合理、是否破壞現(xiàn)有分層、是否引入循環(huán)依賴架構(gòu)牽頭人、受影響模塊owner并發(fā)/事務(wù)處理代碼鎖的范圍是否過(guò)大、事務(wù)邊界是否正確、會(huì)不會(huì)出現(xiàn)死鎖或臟讀資深后端、DBA如有安全敏感操作權(quán)限校驗(yàn)是否在服務(wù)端完成、敏感信息有無(wú)泄露風(fēng)險(xiǎn)安全接口人數(shù)據(jù)處理與遷移腳本大數(shù)據(jù)量下的執(zhí)行效率、冪等性、回滾方案是否完善數(shù)據(jù)/平臺(tái)團(tuán)隊(duì)測(cè)試代碼本身測(cè)試是否有價(jià)值、是否保護(hù)了核心行為、還是只為了覆蓋率數(shù)字全體開(kāi)發(fā)可以說(shuō)在開(kāi)放評(píng)審的語(yǔ)境下真正值得興師動(dòng)眾的代碼往往不是那些新功能的核心業(yè)務(wù)邏輯而是那些牽一發(fā)而動(dòng)全身的橫切邏輯。比如統(tǒng)一的認(rèn)證鑒權(quán)框架、日志埋點(diǎn)組件、公共的列表分頁(yè)組件、數(shù)據(jù)字典的加載方式這些代碼一旦寫歪了影響的是成百上千個(gè)調(diào)用方。把這些代碼拿出來(lái)公開(kāi)評(píng)審讓所有依賴方都來(lái)看一眼其實(shí)就是一種非常高性價(jià)比的風(fēng)險(xiǎn)對(duì)沖。實(shí)際操作中我見(jiàn)過(guò)一個(gè)讓我印象深刻的案例某平臺(tái)團(tuán)隊(duì)想統(tǒng)一所有模塊的緩存訪問(wèn)方式規(guī)劃了一個(gè)底層API。他們起初只拿給各自小組看了后來(lái)我用了一次開(kāi)放評(píng)審把相關(guān)業(yè)務(wù)后端的同學(xué)都拉進(jìn)了同一個(gè)評(píng)審群。結(jié)果前端同學(xué)站出來(lái)說(shuō)他們需要在接口層面直接控制緩存清理后端的API根本沒(méi)暴露這個(gè)能力。這一討論把潛在的后端接口二次返工徹底避免了。這就是開(kāi)放評(píng)審的價(jià)值——它讓看不見(jiàn)的依賴浮出水面而這在傳統(tǒng)的一對(duì)一私密評(píng)審里幾乎不可能被發(fā)現(xiàn)。4. 搭一套有人情味的開(kāi)放評(píng)審工具鏈聊完看什么和評(píng)什么接下來(lái)是很多技術(shù)負(fù)責(zé)人最關(guān)心的工具怎么選、流程怎么搭。工具選得好開(kāi)放評(píng)審就成功了一大半。工具選得不好大家就會(huì)在工具里互相扯皮、迷失在通知郵件的海洋里。4.1 評(píng)審?fù)泄芷脚_(tái)PR/MR是開(kāi)放評(píng)審的主戰(zhàn)場(chǎng)我們需要一個(gè)所有改動(dòng)都能被方便地看到、評(píng)論和被引用的平臺(tái)。我記得最早大家用郵件列表或者共享文件夾那體驗(yàn)簡(jiǎn)直是災(zāi)難。后來(lái)我們遷移到基于Git的專業(yè)代碼托管工具以Pull RequestPR或Merge RequestMR作為核心載體。我對(duì)平臺(tái)的核心要求有三個(gè)。第一上下文完整性評(píng)審人必須能方便地看到這個(gè)PR關(guān)聯(lián)了哪個(gè)Issue/任務(wù)解決的是什么問(wèn)題并且能從代碼上找到對(duì)應(yīng)的改動(dòng)位置。第二討論的線性和持久性每一條comment都必須能追蹤到具體的代碼行且能基于它展開(kāi)子討論而不是在群里發(fā)一段話就石沉大海。第三通知的可控性和低噪音默認(rèn)情況下涉及的人可以訂閱其他人可以選擇性關(guān)注但不能讓所有數(shù)百名工程師被無(wú)關(guān)的通知打擾?；谶@三條市面上的主流托管平臺(tái)包括GitLab/GitHub/自建類Gitea基本都能勝任關(guān)鍵是團(tuán)隊(duì)必須約定好統(tǒng)一的用法不然還是各寫各的。領(lǐng)一個(gè)任務(wù)列表如下把主干分支設(shè)為保護(hù)分支任何直接push都被拒絕強(qiáng)制走PR流程。要求PR標(biāo)題遵循清晰格式例如“[module] 簡(jiǎn)述功能”并且必須填寫描述模板說(shuō)明背景、實(shí)現(xiàn)方案、測(cè)試情況、影響范圍。設(shè)置合理的自動(dòng)合并條件至少1-2個(gè)Approved以及所有CI檢查通過(guò)但也留手動(dòng)合并的口子。4.2 CI流水線讓機(jī)器先把那些不值一提的問(wèn)題過(guò)濾掉開(kāi)放評(píng)審的另一個(gè)大前提是不能讓有經(jīng)驗(yàn)的工程師的寶貴時(shí)間浪費(fèi)在挑格式錯(cuò)誤、缺分號(hào)、變量名拼寫這些機(jī)器就能發(fā)現(xiàn)的問(wèn)題上。所以在人肉評(píng)審之前一定要讓CI流水線先跑完所有的自動(dòng)化檢查代碼格式化、靜態(tài)檢查、單元測(cè)試、測(cè)試覆蓋率門檻、構(gòu)建產(chǎn)物。如果這一層沒(méi)卡好評(píng)審的意見(jiàn)質(zhì)量會(huì)直線下降因?yàn)榇蟛糠志Χ急浑u毛蒜皮消耗掉了。我在不同團(tuán)隊(duì)落地時(shí)都會(huì)強(qiáng)烈推薦在CI里加一個(gè)安全與依賴檢查步驟。掃描依賴庫(kù)的已知漏洞、檢查L(zhǎng)icense合規(guī)性。這在以前是完全依賴Reviewer的人肉經(jīng)驗(yàn)來(lái)完成的效果很不穩(wěn)定。把這些自動(dòng)化之后Reviewer才能專注于真正的業(yè)務(wù)邏輯和架構(gòu)合理性。而且在開(kāi)放評(píng)審的文化里CI有一種微妙的作用它是個(gè)沉默的裁判而且是絕對(duì)客觀的。如果CI掛了那么不管別人對(duì)你的代碼風(fēng)格有多少喜好之爭(zhēng)都可以暫時(shí)擱置你先把構(gòu)建修綠再說(shuō)。這能大幅減少評(píng)審中的情緒摩擦。4.3 評(píng)審會(huì)還是異步評(píng)審不同場(chǎng)景的不同策略open并不等于開(kāi)會(huì)。我個(gè)人的經(jīng)驗(yàn)是小型改動(dòng)或緊急修復(fù)用異步評(píng)論式評(píng)審在PR下方評(píng)論區(qū)點(diǎn)對(duì)點(diǎn)討論不需要所有人同時(shí)在線而大型架構(gòu)改造、接口定義、或跨團(tuán)隊(duì)影響面大的核心設(shè)計(jì)則必須安排一次短暫的、有主持人的同步評(píng)審會(huì)議。同步評(píng)審會(huì)是很多團(tuán)隊(duì)的痛點(diǎn)要不就是從頭安靜到尾就作者一個(gè)人自說(shuō)自話要不就是大家在一個(gè)細(xì)節(jié)上糾纏不休拖到一小時(shí)開(kāi)外。我實(shí)踐下來(lái)的有效做法是主持人提前一天把PR鏈接和相關(guān)背景文檔發(fā)出來(lái)并且要求每位核心參會(huì)人至少留下一條評(píng)論哪怕是一個(gè)問(wèn)題沒(méi)有意見(jiàn)的人必須明確說(shuō)LGTM看起來(lái)不錯(cuò)。會(huì)上只討論那些需要來(lái)回對(duì)話才能澄清的問(wèn)題。會(huì)議記錄也要沉淀回PR的評(píng)論區(qū)保證結(jié)論可追溯。這個(gè)習(xí)慣一旦養(yǎng)成評(píng)審會(huì)能從低效的朗讀代碼變成高效的拍板決策。提示不管用哪種方式開(kāi)放的核心是讓每一次討論都能被后來(lái)者看到。千萬(wàn)不要在IM群里聊完就算完了一定要把關(guān)鍵討論和結(jié)論回寫到PR/MR下。這是團(tuán)隊(duì)知識(shí)庫(kù)最廉價(jià)卻最有效的建設(shè)方式。5. 開(kāi)放的姿態(tài)比流程和工具更重要流程和工具是骨架真正讓評(píng)審活起來(lái)的是參與者的心態(tài)和文化。這一點(diǎn)最難但也是整個(gè)模式的價(jià)值所在。如果你只是把PR改成公開(kāi)可見(jiàn)、拉了更多人進(jìn)來(lái)但大家的交流方式還是那誰(shuí)你是不是傻這個(gè)明顯寫錯(cuò)了那么這個(gè)開(kāi)放評(píng)審是走不遠(yuǎn)的。5.1 對(duì)提交者Author的三條要求第一把自己當(dāng)成一個(gè)懇請(qǐng)同行指教的人而不是負(fù)責(zé)證明自己代碼正確的人。在PR描述里把你不確定的點(diǎn)直接明說(shuō)這塊的并發(fā)處理我拿不準(zhǔn)希望有人幫忙看一下這比藏著掖著等別人發(fā)現(xiàn)要好得多。第二及時(shí)響應(yīng)評(píng)論哪怕只是回復(fù)一個(gè)這個(gè)建議我收到了我再考慮一下。沉默是開(kāi)放評(píng)審的毒藥會(huì)讓評(píng)論者覺(jué)得自己在對(duì)著墻說(shuō)話。第三別把Reviewer的評(píng)論當(dāng)成對(duì)你個(gè)人的否定。別人只是就代碼發(fā)表看法你在代碼里傾注了心血但代碼永遠(yuǎn)可以被討論和優(yōu)化。5.2 對(duì)評(píng)審者Reviewer的三條要求第一先夸后慫是沒(méi)用的但只提問(wèn)題也是不友善的。好的評(píng)審意見(jiàn)應(yīng)該是具體的、可執(zhí)行的最好能給出可選的方案而不是居高臨下的命令。例如如果緩存擊穿了這里會(huì)返回什么就比這段寫得很爛強(qiáng)一萬(wàn)倍。第二關(guān)注大問(wèn)題捕抓小問(wèn)題可以順手但不要漫無(wú)目的地挑剔。意見(jiàn)要分優(yōu)先級(jí)必須修Blocking、建議修Nice to have、只是探討Question。不要搞平均主義讓作者抓不住重點(diǎn)。第三不要獨(dú)占評(píng)審權(quán)?？吹絼e人已經(jīng)給出了不錯(cuò)的意見(jiàn)除非你有補(bǔ)充不然就點(diǎn)贊認(rèn)可即可把新的角度留給他人。開(kāi)放的評(píng)審就是多元視角的碰撞。5.3 如何應(yīng)對(duì)老板突然進(jìn)來(lái)給了一堆注釋的尷尬局面這是很多團(tuán)隊(duì)開(kāi)放評(píng)審后遇到的新問(wèn)題本來(lái)是小范圍的討論結(jié)果大領(lǐng)導(dǎo)或者高級(jí)Title的人突然進(jìn)來(lái)噼里啪啦留了一堆評(píng)論而且多半是語(yǔ)氣比較強(qiáng)硬的建議。然后所有人都不敢說(shuō)話了評(píng)審變成了領(lǐng)導(dǎo)的獨(dú)角戲。我的處理經(jīng)驗(yàn)是建議團(tuán)隊(duì)在前提中達(dá)成一條不成文的規(guī)矩——職位再高在評(píng)審里也是平等的參與者任何人的意見(jiàn)都要講道理、有依據(jù)而不是靠職權(quán)壓人。但注意這話得負(fù)責(zé)人公開(kāi)講并且以身作則。如果領(lǐng)導(dǎo)在上面寫了一條建議但團(tuán)隊(duì)成員覺(jué)得不合理也應(yīng)該有人敢站出來(lái)說(shuō)我不同意原因是...。如果這個(gè)氛圍還沒(méi)有建立起來(lái)那么對(duì)于比較容易緊張的團(tuán)隊(duì)可以先從小范圍的開(kāi)放做起比如前端組、后端組內(nèi)部做開(kāi)放而不是一上來(lái)就拉上全技術(shù)部。文化是慢慢擴(kuò)散的不是靠一紙公告就能強(qiáng)推的。5.4 處理好雞蛋里挑骨頭和意見(jiàn)被忽視的挫敗感投入很多時(shí)間寫了仔細(xì)的評(píng)審意見(jiàn)結(jié)果作者就回了一個(gè)Done完全沒(méi)說(shuō)明改了沒(méi)有、為什么這么改這是非常打擊積極性的。我在團(tuán)隊(duì)里明確要求作者對(duì)于所有評(píng)論必須給一個(gè)明確的回復(fù)——要么已修改并說(shuō)明改了哪里要么不修改并給出充足的理由。只回復(fù)Done或已閱是不合格的。這條紀(jì)律能從根本上保護(hù)評(píng)審者的熱情。反過(guò)來(lái)評(píng)審者也要克制自己這代碼不是按我風(fēng)格寫的就必須改的強(qiáng)迫癥。團(tuán)隊(duì)的核心目標(biāo)是交付正確、可維護(hù)的系統(tǒng)而不是統(tǒng)一成某一個(gè)人的審美。討論是必要的但要盡快達(dá)成共識(shí)不要當(dāng)杠精。6. 實(shí)戰(zhàn)手記一次典型的open-code-review是怎么推進(jìn)的光說(shuō)不練假把式。這里我以一個(gè)模擬項(xiàng)目為例帶大家完整走一遍開(kāi)放評(píng)審的實(shí)操流程。這個(gè)項(xiàng)目我稱之為某跨平臺(tái)訂單同步系統(tǒng)它的目標(biāo)是把多個(gè)外部渠道的訂單數(shù)據(jù)統(tǒng)一拉取到本地?cái)?shù)據(jù)中心做二次轉(zhuǎn)換和分發(fā)。這個(gè)系統(tǒng)的核心模塊之一是渠道商Http接口客戶端。我們就聚焦這個(gè)模塊的開(kāi)放評(píng)審。6.1 會(huì)前準(zhǔn)備階段這個(gè)環(huán)節(jié)直接決定會(huì)議效率負(fù)責(zé)該模塊的開(kāi)發(fā)同學(xué)A在分支feature/http-client-refactor上完成了初版改造目標(biāo)是把原來(lái)一個(gè)500行的上帝類拆成多個(gè)單一職責(zé)的小類并支持未來(lái)接入新渠道的擴(kuò)展。工作進(jìn)展到一半他創(chuàng)建了一個(gè)MRMerge Request標(biāo)題是[order-sync] Http客戶端重構(gòu)支持渠道配置化接入。我在評(píng)審平臺(tái)上看到他提交的MR后做了幾件事在MR里發(fā)起了一個(gè)評(píng)審請(qǐng)求并了相關(guān)的后端開(kāi)發(fā)同事B負(fù)責(zé)數(shù)據(jù)轉(zhuǎn)換、測(cè)試同學(xué)C、以及平臺(tái)基礎(chǔ)組的一位資深工程師D對(duì)HTTP框架比較有發(fā)言權(quán)。給這個(gè)MR打上了架構(gòu)影響評(píng)估設(shè)計(jì)評(píng)審兩個(gè)標(biāo)簽。在MR描述里A同學(xué)按團(tuán)隊(duì)模板寫清了重構(gòu)動(dòng)機(jī)、舊的實(shí)現(xiàn)有什么痛點(diǎn)、新的模塊結(jié)構(gòu)草圖、以及他希望評(píng)審者重點(diǎn)幫忙看的問(wèn)題比如連接池參數(shù)設(shè)置得是否合理。說(shuō)實(shí)話這一步是最容易被省略的。很多人建個(gè)PR就讓人看但連動(dòng)機(jī)和期望都沒(méi)說(shuō)清楚這會(huì)導(dǎo)致評(píng)審者不知道從何入手討論也很難深入。6.2 異步評(píng)論拉鋸高價(jià)值討論的黃金期在會(huì)議開(kāi)始之前的一天里D工程師在MR的代碼行評(píng)論里指出了一個(gè)問(wèn)題新抽象的AbstractChannelClient里把線程池的核心線程數(shù)硬編碼在了字節(jié)碼里這不利于不同渠道的差異化調(diào)優(yōu)建議改為從配置中心動(dòng)態(tài)讀取。測(cè)試同學(xué)C則提出重構(gòu)后不同渠道的A/B Test能力被移除了但文檔里沒(méi)說(shuō)這個(gè)變更會(huì)影響流量回放功能這個(gè)需要考慮是否需要保留擔(dān)保邏輯。A同學(xué)看到評(píng)論后沒(méi)有馬上反駁也沒(méi)有沉默。他在每條評(píng)論下面做了簡(jiǎn)短的回復(fù)。對(duì)D他回復(fù)這個(gè)我同意已經(jīng)抽成一個(gè)可注入的Bean對(duì)象晚點(diǎn)更新代碼。對(duì)C他先點(diǎn)了已讀然后單獨(dú)回復(fù)你說(shuō)得對(duì)我確實(shí)漏了流量回放場(chǎng)景可否請(qǐng)你給出這個(gè)功能的測(cè)試用例或相關(guān)文檔鏈接我補(bǔ)上回歸測(cè)試。這幾條評(píng)論在平臺(tái)和郵件里都已經(jīng)討論過(guò)了而且留下了文字記錄。這是異步評(píng)審最香的地方不需要所有人同時(shí)在線卻能最大程度地覆蓋思考盲區(qū)。6.3 同步評(píng)審會(huì)議用來(lái)拍板而不是讀書雖然異步討論已經(jīng)把大部分問(wèn)題攤開(kāi)了但還有兩個(gè)問(wèn)題存在分歧一個(gè)是線程池參數(shù)到底怎么配才算彈性另一個(gè)是那個(gè)被移除的A/B Test能力是重構(gòu)掉還是保留。這兩件事不是一行代碼能說(shuō)清的牽涉到團(tuán)隊(duì)的整體設(shè)計(jì)方向。于是我們召開(kāi)了一次30分鐘的同步評(píng)審會(huì)。會(huì)議流程極其簡(jiǎn)單由A同學(xué)用5分鐘快速過(guò)了一下MR的主要改動(dòng)和異步評(píng)論結(jié)論不是讀代碼是串邏輯。主持人對(duì)這個(gè)會(huì)議必須有個(gè)主持人我通常擔(dān)任引導(dǎo)大家聚焦剩下的分歧點(diǎn)。D工程師先解釋了為什么數(shù)字化配置是更優(yōu)解然后A同學(xué)補(bǔ)充了自己看到的具體渠道性能瓶頸數(shù)據(jù)。最終大家達(dá)成一致配置中心化但初始默認(rèn)值先沿用A的硬編碼值由A負(fù)責(zé)后續(xù)在配置中心接入。C同學(xué)補(bǔ)充了測(cè)試方案保留一段兼容測(cè)試代碼驗(yàn)證舊客戶端發(fā)起的請(qǐng)求和新客戶端可以互通保證流量回放能力不下線。會(huì)議上有一個(gè)人負(fù)責(zé)記錄通常我本人或?qū)嵙?xí)生把結(jié)論當(dāng)場(chǎng)貼回MR的評(píng)論區(qū)。整個(gè)過(guò)程我們沒(méi)有無(wú)限發(fā)散全部聚焦在那兩個(gè)阻塞級(jí)問(wèn)題上30分鐘開(kāi)完收工。這不是巧合是因?yàn)橛挟惒接懻撛谇懊娲虻装涯芙鉀Q的都解決了。6.4 收尾與回溯讓這一次的認(rèn)知變成團(tuán)隊(duì)下一次的起點(diǎn)合并前A同學(xué)完成了所有修改CI重新跑到了綠色兩位核心評(píng)審者D和C點(diǎn)了通過(guò)審批。最后合并進(jìn)了主干。但這里還有一步被我視為開(kāi)放評(píng)審與普通評(píng)審的本質(zhì)區(qū)別A同學(xué)在MR的總結(jié)區(qū)域更新了一段話記錄了本次評(píng)審中發(fā)現(xiàn)的主要問(wèn)題、決策時(shí)的理由以及后續(xù)待辦比如配置中心接入待提新工單。這段話就是團(tuán)隊(duì)未來(lái)的新同學(xué)研究渠道接入模塊時(shí)最好的第一份參考資料。它比任何架構(gòu)文檔都真實(shí)因?yàn)樗菑恼鎸?shí)的討論里長(zhǎng)出來(lái)的。這就是整個(gè)開(kāi)放評(píng)審的閉環(huán)。工具只提供了舞臺(tái)讓代碼的作者和讀者在一個(gè)透明、記錄完整的環(huán)境下頻繁對(duì)話而流程和文化決定了對(duì)談質(zhì)量。7. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄那些你做開(kāi)放評(píng)審后才會(huì)遇到的坎很多團(tuán)隊(duì)試水開(kāi)放評(píng)審后都會(huì)遇到一些共性問(wèn)題我遇到過(guò)不下十次。這里列幾個(gè)最典型的以及我個(gè)人的解法。7.1 每次評(píng)審都變成了大型吵架現(xiàn)場(chǎng)這種沖突大多不是針對(duì)代碼而是**背景假設(shè)不一致**。兩個(gè)人對(duì)某個(gè)函數(shù)要不要保留參數(shù)、某個(gè)模塊要不要拆分各執(zhí)一詞吵到不可開(kāi)交其實(shí)是因?yàn)楦髯阅X子里設(shè)想的未來(lái)擴(kuò)展場(chǎng)景根本不一樣。解法是先別爭(zhēng)論結(jié)論先逼雙方把我為什么要這么想的背景和假設(shè)說(shuō)清楚。當(dāng)雙方都攤開(kāi)假設(shè)框架之后往往會(huì)發(fā)現(xiàn)爭(zhēng)論的只是同一件事在不同條件下的權(quán)衡然后到具體場(chǎng)景里去分析往往很快能達(dá)成一致。真到僵局的時(shí)候主持人要拍板今天先按方案A做如果出現(xiàn)X場(chǎng)景我們?cè)倏紤]方案B保證推進(jìn)優(yōu)先于完美。7.2 所有人都LGTM但合并后還是出了事故這是一個(gè)非常經(jīng)典的假陽(yáng)性問(wèn)題。LGTM多不代表代碼質(zhì)量高有時(shí)只說(shuō)明大家都沒(méi)仔細(xì)看。特別是當(dāng)一個(gè)PR改動(dòng)太大或者牽涉到太多文件時(shí)Reviewer會(huì)產(chǎn)生畏難情緒隨便點(diǎn)個(gè)贊就算完事。我的對(duì)策有三個(gè)第一鼓勵(lì)小步提交在需求和任務(wù)拆解階段就把一個(gè)大功能切成多個(gè)可獨(dú)立review的小塊每次PR控制在400行以內(nèi)的改動(dòng)有研究認(rèn)為超過(guò)這個(gè)數(shù)量評(píng)審效果顯著下降第二在MR模板中刻意增加請(qǐng)說(shuō)明此改動(dòng)的風(fēng)險(xiǎn)點(diǎn)以及你希望評(píng)審者重點(diǎn)關(guān)注的地方用模板倒逼作者思考也給評(píng)審者一個(gè)明確的切入點(diǎn)第三定期抽查已合并MR的Review質(zhì)量如果發(fā)現(xiàn)某個(gè)Review非常流于形式私下里和這位同學(xué)聊一下看是任務(wù)太多沒(méi)時(shí)間細(xì)看還是不熟悉這塊代碼不敢提意見(jiàn)。找到根源再對(duì)癥單純地喊大家認(rèn)真一點(diǎn)是無(wú)濟(jì)于事的。7.3 新人不敢在公開(kāi)評(píng)審里說(shuō)話怕說(shuō)錯(cuò)這個(gè)問(wèn)題一定要正視。新人沒(méi)有歷史上下文不懂技術(shù)債務(wù)或者某個(gè)怪異編程風(fēng)格的來(lái)龍去脈讓他們?cè)趲资说念l道里公開(kāi)發(fā)問(wèn)真的需要些膽量。我解鎖這個(gè)僵局的辦法是設(shè)立評(píng)審導(dǎo)師或結(jié)對(duì)評(píng)審機(jī)制。讓新人先跟著一位有經(jīng)驗(yàn)的中級(jí)工程師一起過(guò)PR他可以先把問(wèn)題私下里和導(dǎo)師對(duì)齊有一些可以說(shuō)這可能是新人問(wèn)題但值得我們確認(rèn)一下的觀點(diǎn)由導(dǎo)師或者鼓勵(lì)新人自己發(fā)出來(lái)。久而久之新人對(duì)業(yè)務(wù)和代碼庫(kù)越來(lái)越熟悉慢慢也就敢在更大范圍內(nèi)發(fā)聲了。7.4 開(kāi)放評(píng)審?fù)下私桓端俣仍趺崔k很多團(tuán)隊(duì)的代碼評(píng)審會(huì)拖慢速度不是因?yàn)樵u(píng)審本身而是因?yàn)殚_(kāi)始得太晚——代碼寫完、聯(lián)調(diào)快結(jié)束了才發(fā)起評(píng)審這時(shí)候任何改動(dòng)的成本都非常高自然就顯得慢。真正的解法是做**設(shè)計(jì)先行評(píng)審和中途評(píng)審**在寫代碼前把一兩頁(yè)紙的技術(shù)方案、接口定義甚至核心類的草圖拿出來(lái)公開(kāi)討論代碼寫了一半或者核心模塊已經(jīng)成型時(shí)再把WIPWork In Progress狀態(tài)的MR開(kāi)放出來(lái)標(biāo)題前加WIP標(biāo)記讓大家早看早反饋而不是等完成了才亮相。提前反饋的代價(jià)極小而等到完成再返工的代價(jià)是幾何級(jí)的。這條路走順之后開(kāi)放評(píng)審不單不會(huì)拖慢交付還能消滅大量返工時(shí)間反而成為提速的杠桿。7.5 工具上的一些細(xì)節(jié)坑分支名/PR標(biāo)題不規(guī)范建議把PR標(biāo)題和分支名都跟任務(wù)ID或需求單號(hào)做映射不然追蹤起來(lái)極其痛苦。機(jī)器評(píng)審意見(jiàn)和人工評(píng)審意見(jiàn)混為一談務(wù)必讓每個(gè)意見(jiàn)的來(lái)源清晰可辨養(yǎng)成自動(dòng)化結(jié)果直接掛在CI里的習(xí)慣別讓機(jī)器刷屏淹沒(méi)人工的真知灼見(jiàn)。評(píng)審插件/機(jī)器人告警太吵如果團(tuán)隊(duì)的代碼托管平臺(tái)的機(jī)器人一有“可疑代碼”就瘋狂發(fā)通知會(huì)讓人產(chǎn)生“狼來(lái)了”效應(yīng)。務(wù)必把機(jī)器人告警閾值調(diào)到合理范圍或者只在特定標(biāo)簽/分支上開(kāi)啟。8. 寫到最后說(shuō)點(diǎn)心里話這幾年推進(jìn)開(kāi)放評(píng)審我最強(qiáng)烈的感受是它表面上解決的是代碼質(zhì)量問(wèn)題實(shí)際上解決的是團(tuán)隊(duì)信任問(wèn)題。當(dāng)一個(gè)團(tuán)隊(duì)敢于把自己的代碼在最廣泛的范圍內(nèi)展示、討論、甚至被批評(píng)這說(shuō)明大家對(duì)事不對(duì)人的氛圍已經(jīng)立住了。而當(dāng)評(píng)審記錄變成團(tuán)隊(duì)共同的歷史和知識(shí)時(shí)你會(huì)發(fā)現(xiàn)新人成長(zhǎng)變快了跨模塊的信息不對(duì)稱變少了連帶著那些隱藏的架構(gòu)矛盾也會(huì)提前暴露、提前化解。以前我總認(rèn)為評(píng)審到最后拼的是技術(shù)深度是資歷。后來(lái)我發(fā)現(xiàn)拼的是心態(tài)的開(kāi)放程度和心胸的寬度。代碼世界里最難的從來(lái)不是寫代碼而是心平氣和地接受我的代碼可以被別人更好這個(gè)事實(shí)以及誠(chéng)懇地幫助別人把代碼變得比他原來(lái)想的更好。如果你也想試試這個(gè)模式我的建議很簡(jiǎn)單從下一次PR開(kāi)始不要只那個(gè)離你最近的同事試著把相關(guān)上下游的同事都拉進(jìn)來(lái)告訴他們?cè)谠u(píng)論里盡管放心提問(wèn)。然后設(shè)一個(gè)規(guī)矩所有討論結(jié)論都要回寫在PR下面。做完這兩件事再感受一下三個(gè)月后團(tuán)隊(duì)的微妙變化。最后送大家一句話開(kāi)放式評(píng)審不是一場(chǎng)表演而是一場(chǎng)關(guān)于代碼的長(zhǎng)期對(duì)話。對(duì)話一旦開(kāi)始工程質(zhì)量自然會(huì)跟著變好。