1. 一次評(píng)審翻車后我重新思考了代碼評(píng)審到底在看什么先說(shuō)一個(gè)讓我印象很深的場(chǎng)景。前陣子我在某個(gè)訂單系統(tǒng)的權(quán)限模塊上提了一個(gè)合并請(qǐng)求自認(rèn)為把所有邊界情況都想到了改動(dòng)也就一百多行干凈利落。結(jié)果評(píng)審會(huì)上同組的A同學(xué)只問(wèn)了一句如果下游服務(wù)三秒還沒(méi)返回你這邊的重試邏輯會(huì)把庫(kù)存扣兩次嗎我當(dāng)場(chǎng)愣住——我的確加了重試但重試時(shí)沒(méi)有做冪等校驗(yàn)。那次評(píng)審最終沒(méi)有通過(guò)卻讓我意識(shí)到一件事我們對(duì)代碼評(píng)審這四個(gè)字的理解很多時(shí)候是錯(cuò)的。大家習(xí)慣把代碼評(píng)審當(dāng)成一道質(zhì)量關(guān)卡覺(jué)得是找毛病、挑刺、攔住有問(wèn)題的代碼。但實(shí)際上代碼評(píng)審更核心的價(jià)值是信息同步。寫(xiě)代碼的人往往陷在自己的假設(shè)里評(píng)審者因?yàn)閹е滞馊艘暯欠炊钊菀装l(fā)現(xiàn)這里跟需求文檔對(duì)不上這里跟調(diào)用方的約定不一致這里沒(méi)考慮并發(fā)下的重復(fù)請(qǐng)求這類問(wèn)題。A同學(xué)能問(wèn)出那句話不是因?yàn)槲覍?xiě)得不認(rèn)真而是因?yàn)樗吹搅宋铱床坏降纳舷挛?。這也是我把這套實(shí)踐命名為open-code-review的原因。它不是某個(gè)現(xiàn)成的開(kāi)源工具而是一套我自己從多次評(píng)審中沉淀下來(lái)的開(kāi)放評(píng)審方法對(duì)代碼保持開(kāi)放對(duì)意見(jiàn)保持開(kāi)放對(duì)流程本身也保持開(kāi)放。你不需要成為專家才能用上它剛接觸評(píng)審的新手可以拿它當(dāng)入門(mén)指南帶團(tuán)隊(duì)的負(fù)責(zé)人可以拿它當(dāng)流程改版的參考。它要解決的核心問(wèn)題就一個(gè)讓評(píng)審真正攔住該攔的缺陷而不是變成走過(guò)場(chǎng)。順帶說(shuō)一句很多人覺(jué)得代碼評(píng)審浪費(fèi)時(shí)間。這個(gè)賬要算清楚缺陷發(fā)現(xiàn)得越晚修復(fù)成本越高。寫(xiě)代碼時(shí)發(fā)現(xiàn)的是低固定成本到了線上出故障可能牽扯數(shù)據(jù)修復(fù)、客戶投訴、緊急回滾。一次十到二十分鐘的評(píng)審如果能攔下一個(gè)潛在的線上事故這筆投入就非常劃算。問(wèn)題是大多數(shù)團(tuán)隊(duì)的評(píng)審并沒(méi)有在攔事故而是在比誰(shuí)的英語(yǔ)語(yǔ)法好、誰(shuí)的命名風(fēng)格更符合某個(gè)人的偏好。所以這篇內(nèi)容我把整個(gè) open-code-review 實(shí)踐拆成六個(gè)方面評(píng)審對(duì)象、評(píng)審節(jié)奏、工具輔助、意見(jiàn)表達(dá)、常見(jiàn)陷阱以及我最終落地的檢查清單。內(nèi)容會(huì)比較多但每一條都是踩過(guò)坑之后整理出來(lái)的希望你不用再走一遍彎路。2. 評(píng)審對(duì)象與流程設(shè)計(jì)從看代碼到看設(shè)計(jì)意圖2.1 評(píng)審的粒度小型異步評(píng)審才是常態(tài)很多人一提到代碼評(píng)審腦子里浮現(xiàn)的是一屋子人圍在投影儀前。那是過(guò)去重型評(píng)審的典型畫(huà)面適合非常核心的模塊但對(duì)日常開(kāi)發(fā)來(lái)說(shuō)太笨重了。我們團(tuán)隊(duì)現(xiàn)在的主流方式是小型異步評(píng)審開(kāi)發(fā)者提交合并請(qǐng)求評(píng)審者在自己的電腦上看diff寫(xiě)行內(nèi)評(píng)論最后給出結(jié)論。不占用會(huì)議室不用湊齊所有人隨時(shí)隨地可以開(kāi)始。不過(guò)這里有個(gè)前提合并請(qǐng)求的粒度必須足夠小。我見(jiàn)過(guò)最夸張的一次有人把一個(gè)迭代兩周的功能、七八個(gè)文件、三千多行改動(dòng)一次性塞進(jìn)一個(gè)合并請(qǐng)求里美其名曰完整交付。結(jié)果就是評(píng)審人根本看不過(guò)來(lái)草草 approve上線第二天就出了事故?，F(xiàn)在我對(duì)粒度的要求很簡(jiǎn)單一個(gè)合并請(qǐng)求只干一件事。重構(gòu)一個(gè)函數(shù)就只重構(gòu)這個(gè)函數(shù)修復(fù)一個(gè)bug就只修復(fù)這個(gè)bug新增一個(gè)接口就只新增這個(gè)接口。改動(dòng)行數(shù)最好控制在三百行以內(nèi)超過(guò)這個(gè)數(shù)就要反思是不是沒(méi)拆干凈。為什么是三百行我記得有一次項(xiàng)目統(tǒng)計(jì)改動(dòng)行數(shù)超過(guò)五百行的合并請(qǐng)求評(píng)審者平均只在三成區(qū)域留下了有效評(píng)論而小于兩百行的合并請(qǐng)求評(píng)審覆蓋率能到八成以上。人腦對(duì)連續(xù)信息的處理容量是有限的收益隨著代碼量增加迅速遞減。小粒度的合并請(qǐng)求還有一個(gè)隱藏好處回滾方便。萬(wàn)一上線出問(wèn)題一行g(shù)it revert就能干凈地撤銷整件事不用擔(dān)心帶上無(wú)關(guān)的改動(dòng)。這對(duì)線上穩(wěn)定性的價(jià)值很多時(shí)候比評(píng)審本身還要大。2.2 評(píng)審清單怎么設(shè)計(jì)分層攔截而不是逐行讀代碼很多人評(píng)審的時(shí)候是悶頭讀代碼從第一個(gè)文件開(kāi)始一個(gè)循環(huán)看一屏看到哪算哪。這種流式評(píng)審的效率非常低因?yàn)槟銢](méi)有帶著靶子去看。我現(xiàn)在的做法是先列清單再按清單去掃描。清單不是流水賬而是分層設(shè)計(jì)。第一層是正確性與安全性這個(gè)問(wèn)題最大直接決定上線后會(huì)不會(huì)炸。重點(diǎn)關(guān)注數(shù)據(jù)校驗(yàn)是否完善、越權(quán)訪問(wèn)有沒(méi)有攔截、并發(fā)場(chǎng)景下?tīng)顟B(tài)會(huì)不會(huì)亂、異常分支是否處理、敏感信息有沒(méi)有打日志。第二層是可維護(hù)性這個(gè)問(wèn)題不直接導(dǎo)致事故但決定了下個(gè)月的你或者同事會(huì)不會(huì)想罵人。函數(shù)是否過(guò)長(zhǎng)、命名是否名不副實(shí)、是否存在重復(fù)代碼、模塊之間的依賴是否合理、有沒(méi)有留下讓人困惑的魔法數(shù)字。第三層才是代碼風(fēng)格與性能。風(fēng)格問(wèn)題盡量交給自動(dòng)化工具不值得人工花時(shí)間性能問(wèn)題只在有明顯瓶頸的時(shí)候提不要在業(yè)務(wù)代碼里糾結(jié)一次遍歷是 O(n) 還是 O(2n)。這三層看起來(lái)簡(jiǎn)單實(shí)際操作時(shí)有一個(gè)關(guān)鍵技巧先看測(cè)試再看實(shí)現(xiàn)最后看上下文引入點(diǎn)。大多數(shù)評(píng)審者習(xí)慣拿過(guò)代碼就開(kāi)始讀實(shí)現(xiàn)讀到一半才去想這個(gè)函數(shù)應(yīng)該是干什么的。如果你先看測(cè)試用例測(cè)試的名稱和斷言會(huì)直接告訴你作者的真實(shí)意圖然后帶著這個(gè)意圖去看實(shí)現(xiàn)就能很快發(fā)現(xiàn)實(shí)現(xiàn)跟意圖之間的偏差最后再看這個(gè)改動(dòng)被誰(shuí)調(diào)用、影響哪些上游下游把全局上下文補(bǔ)上。這個(gè)順序我第一次用的時(shí)候只花了過(guò)去一半的時(shí)間就發(fā)現(xiàn)了兩個(gè)真正的邏輯漏洞。2.3 合并請(qǐng)求模板把該寫(xiě)的信息前置流程設(shè)計(jì)里最容易忽略的是合并請(qǐng)求描述本身。我見(jiàn)過(guò)太多人只寫(xiě)一句fix bug或者update評(píng)審人被迫從代碼里反推意圖。信息不對(duì)稱是評(píng)審低效的最大來(lái)源而模板是解決這個(gè)問(wèn)題的最便宜的方案。一個(gè)實(shí)用的合并請(qǐng)求模板應(yīng)該包含三塊這次改動(dòng)解決什么問(wèn)題最好帶上復(fù)現(xiàn)步驟或現(xiàn)象截圖、改動(dòng)涉及哪些模塊和文件讓評(píng)審人知道哪里是重點(diǎn)、測(cè)試情況如何單元測(cè)試、手動(dòng)驗(yàn)證、影響范圍。最后一塊特別重要很多人提交之前根本沒(méi)想自己測(cè)過(guò)什么寫(xiě)著寫(xiě)著就發(fā)現(xiàn)自己還有一堆沒(méi)驗(yàn)證的地方。有了模板評(píng)審人可以在一兩分鐘內(nèi)建立起對(duì)改動(dòng)的全局認(rèn)知然后把注意力集中在真正有風(fēng)險(xiǎn)的地方。這個(gè)前置信息的小改動(dòng)帶來(lái)的效率提升遠(yuǎn)超你想象。3. 評(píng)審節(jié)奏與時(shí)間管理把評(píng)審控制在十五分鐘以內(nèi)3.1 為什么評(píng)審會(huì)拖成無(wú)效加班不知道你有沒(méi)有過(guò)這種經(jīng)歷一個(gè)合并請(qǐng)求掛在列表里好幾天催了兩次都沒(méi)人看最后催急了才有人熬夜幫你點(diǎn)了通過(guò)。評(píng)審周期拖得越長(zhǎng)上下文丟失得越嚴(yán)重作者甚至都忘了自己當(dāng)時(shí)為什么這么寫(xiě)評(píng)審人還得花大量時(shí)間重新理解。更糟的是有些團(tuán)隊(duì)會(huì)抱怨代碼評(píng)審?fù)下说鋵?shí)拖慢迭代的不是評(píng)審本身而是沒(méi)有節(jié)奏的評(píng)審。我總結(jié)過(guò)幾個(gè)常見(jiàn)的節(jié)奏殺手評(píng)審請(qǐng)求發(fā)在群里沒(méi)人明確接單、評(píng)審人趕在下班前才開(kāi)始看所以草草了事、一個(gè)改動(dòng)同時(shí)等兩三個(gè)人評(píng)論導(dǎo)致結(jié)論打架、作者提交代碼后不主動(dòng)跟進(jìn)提醒。這些問(wèn)題跟技術(shù)關(guān)系不大但跟評(píng)審能不能跑起來(lái)關(guān)系很大。3.2 設(shè)定明確的時(shí)間盒十五分鐘決策機(jī)制我現(xiàn)在的經(jīng)驗(yàn)是每次評(píng)審最多給自己十五分鐘。聽(tīng)起來(lái)很激進(jìn)但配合小粒度的合并請(qǐng)求完全可行。前兩分鐘看描述和測(cè)試中間十分鐘過(guò) diff 和關(guān)鍵分支最后三分鐘寫(xiě)結(jié)論或者跟作者在線溝通。超過(guò)十五分鐘還沒(méi)看完說(shuō)明這個(gè)改動(dòng)已經(jīng)超出了它的安全評(píng)審范圍這時(shí)候就停下來(lái)讓作者拆下一次評(píng)審而不是硬撐著讀完。時(shí)間盒的好處是逼迫你區(qū)分必須看和可以跳過(guò)。很多人覺(jué)得每行都得看這是誤解。關(guān)鍵邏輯看三遍都不嫌多樣板代碼掃一眼就夠。有了時(shí)間壓力你的注意力反而更集中不會(huì)讀著讀著就跳到某個(gè)無(wú)關(guān)緊要的格式問(wèn)題上。實(shí)際操作中我會(huì)配合一個(gè)簡(jiǎn)單儀式評(píng)審?fù)瓿珊蟛还芙Y(jié)果是通過(guò)還是打回都在評(píng)審記錄里寫(xiě)一句已評(píng)審耗時(shí)X分鐘主要關(guān)注點(diǎn)是ABC。這句話幫作者快速定位風(fēng)險(xiǎn)區(qū)域也幫團(tuán)隊(duì)統(tǒng)計(jì)評(píng)審效率。后來(lái)我們的合并請(qǐng)求平均合并速度從三天縮短到半天靠的其實(shí)都是這種小節(jié)奏的改進(jìn)。3.3 評(píng)審會(huì)議出現(xiàn)在什么時(shí)候異步評(píng)審是主流但有一個(gè)場(chǎng)景我會(huì)特意安排同步討論跨模塊的接口變更。比如你的改動(dòng)涉及調(diào)用方或者改了某個(gè)公共方法的入?yún)⑦@時(shí)候異步評(píng)論來(lái)回一輪可能要半天同步開(kāi)個(gè)短會(huì)大家直接把路由打通把實(shí)現(xiàn)方的假設(shè)和調(diào)用方的需求放在同一張白板上效率反而更高。這類會(huì)議有個(gè)前提你必須帶著已經(jīng)完成的異步評(píng)審結(jié)論來(lái)而不是把會(huì)議當(dāng)成評(píng)審起點(diǎn)。我參加過(guò)很多一起看代碼的會(huì)實(shí)際效果基本是幾個(gè)人盯著投影儀發(fā)呆誰(shuí)都不好意思發(fā)言。正確姿勢(shì)是每個(gè)人先自己看一遍寫(xiě)好問(wèn)題清單會(huì)上只討論清單里的差異點(diǎn)十分鐘內(nèi)解決問(wèn)題十五分鐘聊完收工。4. 工具鏈怎么輔助 open-code-reviewdiff、行內(nèi)評(píng)論與自動(dòng)化檢查4.1 diff 閱讀順序與上下文切換代碼托管平臺(tái)的合并請(qǐng)求界面本質(zhì)上是把 diff 呈現(xiàn)給你看。但這個(gè)界面有個(gè)陷阱你看到的是變更后的代碼而評(píng)審真正需要對(duì)比的是變更前和變更后之間的語(yǔ)義差異。很多評(píng)審者看到一行刪除、幾行新增就急著評(píng)論其實(shí)根本不知道刪除的上下文在哪里。我建議按先新增、再刪除、后調(diào)整的順序讀 diff。新增代碼說(shuō)明這個(gè)改動(dòng)帶來(lái)了什么刪除代碼說(shuō)明它移除了什么調(diào)整代碼說(shuō)明它改了原來(lái)的什么假設(shè)。讀的時(shí)候注意平臺(tái)提供的展開(kāi)上下文功能尤其是那些看似沒(méi)變的周邊代碼有時(shí)候 bug 就藏在那幾行沒(méi)變的調(diào)用里。行內(nèi)評(píng)論是異步評(píng)審的核心工具。它的優(yōu)勢(shì)是可以精確定位到某一行作者一打開(kāi)就明白你在說(shuō)什么完全可以替代那種整體寫(xiě)得還不錯(cuò)但邏輯有問(wèn)題的模糊評(píng)語(yǔ)。我個(gè)人的習(xí)慣是每條評(píng)論盡量短只說(shuō)一件事不搞長(zhǎng)篇大論。如果確實(shí)需要解釋大背景我會(huì)先寫(xiě)一行核心結(jié)論再用一個(gè)背景子段落展開(kāi)方便作者快速?zèng)Q定要不要看細(xì)節(jié)。4.2 自動(dòng)化檢查該攔什么、不該攔什么自動(dòng)化工具是評(píng)審的好幫手但用不好也會(huì)制造噪音。我的原則其實(shí)很簡(jiǎn)單能讓機(jī)器確定的事情就不要浪費(fèi)人的時(shí)間機(jī)器不確定的事情也不要讓機(jī)器亂發(fā)言?？梢越唤o自動(dòng)化工具的有代碼格式、明顯的類型問(wèn)題、未使用的變量、明顯的空指針風(fēng)險(xiǎn)、日志中是否打印了敏感信息、依賴license問(wèn)題、重復(fù)代碼比例。這些檢查建議全部接入提交前和合并前的流水線攔截了就把這類型的評(píng)論從人工評(píng)審里剔出去。不該交給自動(dòng)化工具的有業(yè)務(wù)邏輯是否正確、接口語(yǔ)義是否符合需求、并發(fā)處理是否合理、數(shù)據(jù)一致性是否保證。這些判斷需要完整的業(yè)務(wù)上下文機(jī)器現(xiàn)在遠(yuǎn)做不到。很多團(tuán)隊(duì)在流水線里塞了一堆建議級(jí)別的檢查規(guī)則結(jié)果開(kāi)發(fā)者天天被逼著改無(wú)意義的告警反而沖淡了真正有價(jià)值的人工評(píng)審。自動(dòng)化檢查應(yīng)該是守門(mén)員而不是評(píng)論員該守的門(mén)守住剩下的交給人去對(duì)話。4.3 評(píng)審結(jié)論的三種表達(dá)通過(guò)、評(píng)論、請(qǐng)求修改工具上通常有三個(gè)按鈕同意合并、評(píng)論、請(qǐng)求修改。這三個(gè)按鈕的語(yǔ)義一定要在團(tuán)隊(duì)里對(duì)齊否則很快會(huì)出現(xiàn)一群人點(diǎn)了評(píng)論作者不知道到底能不能合并的混亂狀態(tài)。我把它們的邊界定義得很清楚。通過(guò)意味著我認(rèn)為這個(gè)改動(dòng)可以上線如果后續(xù)有問(wèn)題我負(fù)責(zé)得起這是一個(gè)強(qiáng)承諾不是敷衍的點(diǎn)贊。評(píng)論意味著當(dāng)前代碼沒(méi)問(wèn)題但我有改進(jìn)意見(jiàn)你可以擇機(jī)處理不阻塞合并。請(qǐng)求修改意味著當(dāng)前代碼存在我無(wú)法接受的缺陷合并前必須解決。使用評(píng)論這一檔要尤其克制。我看到很多人明明發(fā)現(xiàn)了會(huì)影響線上正確性的 bug卻只寫(xiě)了一句你可以考慮一下這里是否應(yīng)該加個(gè)判斷然后點(diǎn)了通過(guò)。這是典型的躲避沖突。正確的做法是如果有顧慮就明確說(shuō)請(qǐng)求修改如果只是品味偏好就放在評(píng)論里別阻塞別人。這個(gè)邊界不清晰是評(píng)審失去效力的最大隱患之一。5. 評(píng)審意見(jiàn)的表達(dá)如何讓這段邏輯必須重寫(xiě)不變成一場(chǎng)爭(zhēng)執(zhí)5.1 意見(jiàn)分三檔必須修、建議修、風(fēng)格偏好評(píng)審者給出意見(jiàn)之前先自己心里分個(gè)檔。必須修是正確性問(wèn)題比如數(shù)據(jù)會(huì)被覆蓋、權(quán)限會(huì)被繞過(guò)、異常會(huì)觸發(fā)嚴(yán)重 bug。建議修是可維護(hù)性問(wèn)題比如命名不清、邏輯重復(fù)、缺少測(cè)試不修也不至于上線出事但留著會(huì)持續(xù)消耗后來(lái)的維護(hù)成本。風(fēng)格偏好是純個(gè)人傾向比如變量名用哪個(gè)詞、花括號(hào)怎么換行、注釋中英文比例。這三個(gè)檔位在評(píng)論里要用明確的詞標(biāo)出來(lái)比如[必須修] 這里缺少對(duì)空值的判斷[建議修] 這個(gè)函數(shù)可以拆成兩個(gè)小函數(shù)[風(fēng)格] 我更喜歡用 start 而不是 begin。這樣作者接到意見(jiàn)時(shí)不需要自己去猜嚴(yán)重程度也避免了你居然為了一個(gè)變量名就打回我的代碼這種事。其實(shí)很多評(píng)審摩擦本質(zhì)就是檔位沒(méi)對(duì)齊。作者以為你在說(shuō)風(fēng)格結(jié)果你暗中是把他往必須修的檔位上算評(píng)審者以為自己在提建議結(jié)果用詞又像是在下命令。把檔位亮在明面上沖突能少掉一大半。5.2 用問(wèn)題代替斷言評(píng)審者的蘇格拉底式提問(wèn)我在評(píng)審中學(xué)到的最重要的一課是結(jié)論自己會(huì)讓人防御問(wèn)題會(huì)讓人思考。你這塊代碼有并發(fā)風(fēng)險(xiǎn)和如果兩個(gè)請(qǐng)求同時(shí)在跑這段邏輯會(huì)不會(huì)出現(xiàn)重復(fù)扣款后者的接受度要高得多。原因很簡(jiǎn)單代碼是作者花費(fèi)時(shí)間和心思寫(xiě)出來(lái)的直接下結(jié)論相當(dāng)于否定了他的一部分勞動(dòng)。但只要換成提問(wèn)你們就從對(duì)立關(guān)系變成了一起探索問(wèn)題的隊(duì)友。我自己做評(píng)審時(shí)有個(gè)硬性規(guī)定凡是必須修級(jí)的問(wèn)題全部寫(xiě)成問(wèn)題形式措辭也盡量具體比如這個(gè) null 是從哪里傳進(jìn)來(lái)的調(diào)用方有沒(méi)有可能不傳而不是這里空指針了修一下。提問(wèn)式評(píng)審的額外產(chǎn)出是它逼著你自己先想明白問(wèn)題到底出在哪。比起脫口而出的斷言提問(wèn)要經(jīng)過(guò)更嚴(yán)謹(jǐn)?shù)乃伎歼@對(duì)評(píng)審質(zhì)量本身也是一個(gè)正向加成。5.3 作者側(cè)的反向操作主動(dòng)標(biāo)記這里我看過(guò)沒(méi)把握評(píng)審意見(jiàn)的溝通壓力不只是評(píng)審者的問(wèn)題作者也能做很多事。我的習(xí)慣是在提交信息或者合并請(qǐng)求描述里明確標(biāo)出我自己懷疑過(guò)但拿不準(zhǔn)的區(qū)域。這樣評(píng)審者就能把精力放在你最心虛的地方而不是均勻撒在全篇上。反過(guò)來(lái)作者越坦誠(chéng)地暴露自己的不確定評(píng)審者越愿意給出真正有幫助的建議這是一條正向反饋。作者收到意見(jiàn)之后也要有個(gè)處理清單必須修的問(wèn)題逐一確認(rèn)修改建議修的問(wèn)題能改就改不能改要給出理由風(fēng)格偏好看情況跟自己的想法一致就采納不一致可以保留。最差的做法是看到評(píng)論就情緒上頭逐條反駁把評(píng)審變成辯論賽。代碼評(píng)審的目標(biāo)是共同把代碼變得更好不是證明誰(shuí)更聰明。6. 那些年踩過(guò)的評(píng)審坑形式化評(píng)審、無(wú)休止討論與漏網(wǎng)之魚(yú)6.1 全員通過(guò)卻照樣出事故評(píng)審為什么失效了最令人沮喪的情況莫過(guò)于評(píng)審流程走完了每個(gè)人都點(diǎn)了通過(guò)結(jié)果上線還是出了事故。這不是評(píng)審系統(tǒng)失效而是評(píng)審變成了形式化蓋章。我可以列出幾種常見(jiàn)病根。一種是因?yàn)闄?quán)力關(guān)系不對(duì)等資深的人說(shuō)沒(méi)問(wèn)題其他人就不好意思再說(shuō)話。一種是因?yàn)樵u(píng)審者對(duì)業(yè)務(wù)背景完全不了解看了代碼只覺(jué)得語(yǔ)法沒(méi)毛病就通過(guò)。還有一種是最普遍的改動(dòng)太大、太雜評(píng)審者看了一部分就開(kāi)始犯困最后大家都想著反正 CI 過(guò)了先合并再說(shuō)。針對(duì)這些病根我做了兩手調(diào)整。其一評(píng)審意見(jiàn)和決定嚴(yán)格基于內(nèi)容和數(shù)據(jù)不基于等級(jí)資歷其二合并請(qǐng)求描述必須包含測(cè)試情況如果作者寫(xiě)不出自己驗(yàn)證過(guò)什么就不進(jìn)入評(píng)審環(huán)節(jié)。這兩條規(guī)定一起執(zhí)行之后全員通過(guò)但事故照出的情況才真正開(kāi)始變少。6.2 評(píng)審?fù)咸脤?dǎo)致的上下文丟失評(píng)審周期過(guò)長(zhǎng)不只是流程效率問(wèn)題更會(huì)影響評(píng)審質(zhì)量本身。幾個(gè)真實(shí)體會(huì)改動(dòng)提交第一天作者腦子里還有完整的上下文可以立刻響應(yīng)評(píng)論到第三天他自己都要重新看代碼才能想起當(dāng)時(shí)的決策評(píng)論的回復(fù)質(zhì)量明顯下降到一周幾乎所有人都對(duì)這個(gè)改動(dòng)失去新鮮感看到的只是一堆代碼而不是一個(gè)問(wèn)題。所以我對(duì)評(píng)審超時(shí)的處理很干脆超過(guò)兩個(gè)工作日的評(píng)審自動(dòng)提醒作者和評(píng)審者不解決就升級(jí)到同步會(huì)議。升級(jí)不是懲罰而是承認(rèn)異步溝通在這個(gè)場(chǎng)景下已經(jīng)失效強(qiáng)制換一種模式。這時(shí)候開(kāi)一個(gè)十五分鐘短會(huì)通常比繼續(xù)掛一天效率高得多。我還有一個(gè)親測(cè)有效的細(xì)節(jié)作者提交合并請(qǐng)求之后不要默默等待主動(dòng)在團(tuán)隊(duì)溝通頻道里發(fā)一條簡(jiǎn)短說(shuō)明包含描述鏈接和需要誰(shuí)來(lái)評(píng)審。很多合并請(qǐng)求掛在列表里被遺忘不是大家不負(fù)責(zé)而是真的沒(méi)注意到。主動(dòng)跟進(jìn)這一下能把整個(gè)評(píng)審周期縮短一大截。6.3 低層次問(wèn)題搶走了高層次注意力最后一個(gè)坑是評(píng)審者把精力花在了機(jī)器能解決的問(wèn)題上。我看到過(guò)太多評(píng)審討論在吵命名這個(gè)變量叫 result 還是 outcome這個(gè)函數(shù)放 utils 還是 helper。吵到天荒地老卻沒(méi)有一個(gè)人關(guān)心核心業(yè)務(wù)邏輯有沒(méi)有缺陷。這不是說(shuō)命名不重要而是說(shuō)解決這個(gè)問(wèn)題有更便宜的方式。代碼格式化工具、文檔規(guī)范、高質(zhì)量模板都能處理絕大多數(shù)低層次問(wèn)題。人工評(píng)審是團(tuán)隊(duì)成本最高、心智資源最稀缺的環(huán)節(jié)應(yīng)該把它留給只有人才能發(fā)現(xiàn)的問(wèn)題。每當(dāng)有人開(kāi)始對(duì)著格式爭(zhēng)議我都會(huì)提醒一句先看邏輯格式上如果有潔癖請(qǐng)先去改自動(dòng)化規(guī)則不要在這里消耗人。這個(gè)觀念的轉(zhuǎn)變也是 open-code-review 從找錯(cuò)的流程進(jìn)化成質(zhì)量共建系統(tǒng)的關(guān)鍵節(jié)點(diǎn)。評(píng)審不再是防御性的關(guān)卡而是大家一起討論設(shè)計(jì)意圖、發(fā)現(xiàn)盲區(qū)、對(duì)齊認(rèn)知的協(xié)作場(chǎng)合。如果能做到這一點(diǎn)代碼庫(kù)的質(zhì)量會(huì)以肉眼可見(jiàn)的速度提升。7. 我現(xiàn)在的評(píng)審習(xí)慣與最終落地清單從那次訂單系統(tǒng)重試扣庫(kù)存翻車到現(xiàn)在我一直在迭代自己的評(píng)審方式最終形成了三個(gè)固定的習(xí)慣。第一個(gè)習(xí)慣是先問(wèn)三個(gè)問(wèn)題再看代碼這個(gè)改動(dòng)要解決什么問(wèn)題它影響哪些模塊和調(diào)用方作者驗(yàn)證過(guò)什么三個(gè)問(wèn)題在合并請(qǐng)求描述里找不到答案的話我會(huì)直接請(qǐng)作者補(bǔ)充而不是自己猜著往下讀。這讓我避開(kāi)了大多數(shù)讀了一大半才發(fā)現(xiàn)方向不對(duì)的情況。第二個(gè)習(xí)慣是必須在一個(gè)小本子里留一句評(píng)審備注。評(píng)審?fù)曛箜樖钟浺痪溥@個(gè)改動(dòng)哪個(gè)區(qū)域風(fēng)險(xiǎn)最高、哪條意見(jiàn)最值得后續(xù)跟進(jìn)。本來(lái)只是給自己留痕跡沒(méi)想到后來(lái)做線上回查時(shí)幫了大忙能快速定位當(dāng)初評(píng)審時(shí)擔(dān)心的地方。第三個(gè)習(xí)慣是評(píng)審別人之前先把自己的合并請(qǐng)求隨手處理掉。一個(gè)團(tuán)隊(duì)里如果資深的人總把自己的評(píng)審壓到最后一刻新人很快就會(huì)覺(jué)得評(píng)審只是走個(gè)形式。先把別人交給我的代碼處理好再去推進(jìn)自己的開(kāi)發(fā)任務(wù)這個(gè)次序本身就在傳遞一種信號(hào)評(píng)審是值得被認(rèn)真對(duì)待的事它不是可有可無(wú)的尾巴工程。如果你所在的團(tuán)隊(duì)還在被無(wú)效評(píng)審困擾我的建議是不要指望一步到位。先從一件小事開(kāi)始把合并請(qǐng)求拆分到三百行以內(nèi)給評(píng)審設(shè)定十五分鐘的時(shí)間盒把意見(jiàn)分檔標(biāo)清楚。這三個(gè)動(dòng)作不需要引入任何復(fù)雜平臺(tái)或工具只需要大家達(dá)成共識(shí)。我見(jiàn)過(guò)很多團(tuán)隊(duì)做到這一步之后評(píng)審會(huì)議的爭(zhēng)吵少了上線故障也明顯少了因?yàn)榇蠹医K于把力氣花在了真正值得花的地方。open-code-review 說(shuō)到底不是某種固定的形式。對(duì)別人寫(xiě)的代碼保持開(kāi)放對(duì)自己的盲區(qū)保持開(kāi)放對(duì)流程的改進(jìn)保持開(kāi)放——能做到這三點(diǎn)代碼評(píng)審就再也不是每月吐槽清單里的負(fù)擔(dān)而會(huì)成為整個(gè)團(tuán)隊(duì)質(zhì)量感覺(jué)最靈敏的一根神經(jīng)。