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