1. 一次評(píng)審翻車(chē)后我重新思考了代碼評(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)求這類(lèi)問(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)放。你不需要成為專(zhuān)家才能用上它剛接觸評(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ù)、客戶(hù)投訴、緊急回滾。一次十到二十分鐘的評(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ù)最好控制在三百行以?xún)?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就能干凈地撤銷(xiāo)整件事不用擔(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ù)代碼、模塊之間的依賴(lài)是否合理、有沒(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è)試的名稱(chēng)和斷言會(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ì)稱(chēng)是評(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)審控制在十五分鐘以?xún)?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)用方的需求放在同一張白板上效率反而更高。這類(lèi)會(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ā)言。可以交給自動(dòng)化工具的有代碼格式、明顯的類(lèi)型問(wèn)題、未使用的變量、明顯的空指針風(fēng)險(xiǎn)、日志中是否打印了敏感信息、依賴(lài)license問(wèn)題、重復(fù)代碼比例。這些檢查建議全部接入提交前和合并前的流水線攔截了就把這類(lèi)型的評(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ù)存翻車(chē)到現(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)求拆分到三百行以?xún)?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)。