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