北京
我的團隊有一條死規矩：當一條合并請求的改動超過500行，得到的回復永遠是同一句話——“這個太大了，拆一下。”
說實話，我也不想當那個整天數代碼行數的“警察”。可我這些年反復體會到一個事實：持續地拒絕，并帶上真正的理由，才是“存在合并規范”和“合并規范真正起作用”之間的分水嶺。
幾乎所有團隊都在內部維基里存著一頁“合并規范”：小改動、指定評審人、關聯需求卡片。可大部分頁面不過是裝飾品。標準沒有錯，錯在沒人真的遵守。所以今天我不想再給你一份清單，而是把我的團隊里標準的“真實狀態”攤開來——哪些有硬機制，哪些靠團隊文化在撐，哪些我們到現在也沒做到。
先說我們嚴格執行的幾條。第一條：保持改動小。我給團隊定的目標是把單次合并請求控制在300行改動以內，實際上限是500行。這個落差是刻意留下的——目標是努力方向，中間留出判斷空間。但只要一個合并請求超過500行，且不屬于少數豁免情況，我一定會拒絕并要求拆分。不是“偶爾”，是每一次。只要你放過一次，標準立刻變成建議。
我對數據盯得很緊：每個工程師的平均請求大小、整個團隊的平均值，還有每一個新打開的合并請求到底有多大。為什么這么較真？因為評審者面對300行改動，還能真正“推理”這段代碼；遠超這個數，所謂的“評審”就變成了快速掃一眼，最后點一個綠色的通過標記。這種事我見過，你見過，我們都干過。
第二條：別讓合并請求干等著。從打開到合入控制在兩天以內。一個掛著不動的請求會迅速變質：作者的上下文記憶消退，沖突越積越多，等到終于有人來處理時，評審質量明顯更差。閑置時間，就是一段好改動悄悄腐爛的過程。
第三條：每個合并請求必須關聯一張工作卡片。唯一的例外是極少數高優先級的緊急修復，而且每次發生時所有人都知道這是特例。為什么要咬住不放？因為評審者只要先看了卡片里的需求和背景，再讀代碼差異，就能帶上上下文。半年后，當有人問“這段代碼為什么存在”，一定有一個清晰的答案。
第四條：把能吵起來的事交給自動化。代碼檢查和格式化工具在提交前鉤子里跑一遍，連續的集成流水線里再跑一遍。沒人能跟格式化工具討價還價。這就把評審者的注意力解放出來，去關注機器查不了的東西：模式、命名、方案的形態。你用自動化消解掉的每一次爭論，都是從評審精力中收回來的判斷時間。
以上四條，是真正有“拒絕”作為后盾的。但老實說，我們也有一些標準，更多是靠文化在推動，而不是硬機制。
比如關于評審人的分配：我們建議每個合并請求至少指定兩位評審者，一位更偏重業務邏輯，另一位更偏重技術實現。這種分配在緊張交付期經常被跳過。它沒有硬性阻斷，所以能不能做到，取決于當時的節奏和團隊的自覺。還有關于寫提交信息和請求描述，我們有明確模板，但工程師們有時還是會寫得很隨意——不是抗拒，只是時間一緊就順著慣性走了。這些地方，我們沒有用規則卡死，而是靠定期的代碼回顧和互相提醒來維持最低水準。
還沒有做到的，是讓整個團隊對“小改動”三個字形成本能。雖然數據在改善，平均合并請求大小在下降，但當業務壓力集中出現時，依舊會看到400多行的大請求被直接提交，而且帶著“這次真的太復雜了，拆不開”的附言。這個階段，標準仍然是我們在推動，而不是寫代碼的人的肌肉記憶。要走到那一步，還需要更多時間。
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
