從個人擴散到團隊
2024 年時，為了摸索如何進行 Code Review，我在〈成為更重視 Code Review 的工程師〉 整理了一些準則及概念，對我自己幫助很大。
但 Code Review 要發揮真正的價值，必須是整個開發團隊共同參與。我因此開始嘗試在團隊內推廣這樣的文化。一年過去，我很滿意團隊在 Code Review 上的變化，也在過程中體會到許多過去沒想過的「開發快樂」。
今天這篇文章算是續集，我想進一步談談在「團隊」中推動 Code Review 文化的經驗與心路歷程，希望能對正在摸索的團隊，或是想改善 Code Review 文化的 Evangelist 有所幫助。
Code Review 是合作系統，而不是規範
許多人把 Code Review 視為「規範」或「審查」，這樣往往會帶來壓力，讓人卻步。
我以前在 Review 程式碼時，常常想：
如果我按下 Approve，結果後面有人挑出問題，是不是代表我沒看仔細？
這種心態會讓 Code Review 變成一場競賽：誰能先挑出錯誤，誰就比較厲害。
後來我轉換了觀點：Code Review 更像是一個「合作系統」。
每個工程師因為經歷、特質、踩過的雷不同，因此對某些「面向」會特別敏感
Code Review 正是要善用這種個體差異。
以我們設計 CI/CD Pipeline 的團隊為例，一份同樣的程式碼，解決同樣的問題，但是：
- 有些人特別看重「架構」，希望未來不會疊床架屋。
- 有些人喜歡「效能」，希望 Pipeline 的執行時間越短越好。
- 有些人則關心「使用者體驗」，希望Log 呈現要精準、有效。
這些差異並不是弱點，而是團隊構建出的集體優勢：
每個人共同確保正確性，同時就自己感興趣或擅長的領域給予建議。
當我按下 Approve，其實是說：「從我的角度看起來沒有問題。」而其他人仍能補上我看不到的盲區。這樣的互補，正是 Code Review 的價值所在。
從討論中形塑團隊的品質標準
你如何定義一段好的程式碼呢？
在推動 Code Review 文化的過程中，我最喜歡的一點是：
我感覺到團隊正在凝聚對於「好」的共識。
我原本特別在意「使用者體驗」，但因為夥伴們在 Review 時經常關注「架構」，我也養成多留意這部分的習慣。同樣地，其他人也會因為我對於「使用者體驗」的堅持，逐漸把這一塊納入考量。
換句話說，Code Review 不只是降低失敗風險，更是一個持續的對話機制。不同觀點互相影響，最後凝聚成團隊對於「好」的共識。
一定要是主管才有資格推動 Code Review 文化嗎？
當初我也曾猶豫過：
我夠格嗎？我算哪根蔥來改變這樣的流程？
在一次分享中，Team Lead 給了我一個深刻的回答：
「不必靠 Team Lead 發起，但需要 Team Lead 的支持。」
這讓我意識到：推動文化其實也是一種 “Influence without authority” 的練習，即便沒有主管頭銜，你仍然可以用信念、行動和影響力，去改變一個流程。只不過，若要走得久，還是需要主管的認同與資源支持。
(註：“Influence without authority” 的概念是我從 vgod 的文章 - 〈軟體工程師的修煉與成長 (6) — 換團隊 x 2〉" 中獲得的啟發，非常推薦各位去閱讀系列文章。)
舉例來說，我們在例會中固定留一個時段，專門檢視這段時間的 Code Review 狀況：有沒有阻礙？能怎麼排除？要把這樣的資源切進工時，就必須獲得主管的支持。
對於 Evangelist 而言，推動文化靠的不是「職權」，而是信念和持續的行動。但仍需要和主管維持同一陣線。我認為 1 on 1 是和主管交流時非常重要的工具，可以藉此說明為什麼值得投入、這些成本如何帶來效益，就能換來更多理解與協助。
(如果你對進行 1 on 1 感到陌生，可以參考我的另一篇文章 - 〈每個月和主管 1 on 1，半年後帶給我什麼樣的啟發？〉)
落地的關鍵：減少阻力、保留彈性
說到如何讓 Code Review 真正落地，我覺得最重要的就是降低阻力。以下分享幾個我們在團隊內實際踩過的點。
清理雜訊：建立單一通知鏈
我們遇到的主要問題是「通知疲勞」：成員每天會收到大量 Azure DevOps 的通知信，多數其實是雜訊(其他團隊的 PR、狀態更新)，導致所有人都習慣性忽略。
當開發者因為 Reviewer 的通知疲勞，造成 Response Time 上升時，只好透過其他管道 (例如 Teams 聊天室) 發送重複的 Link，進一步加劇疲勞。
我們的做法是刻意限縮通知管道：
- 先讓全體成員一同檢視 Azure DevOps 的通知設定，排除不必要的雜訊，只保留真正需要的通知。
- 在通知機制確定有效後，進一步要求成員避免使用其他渠道發送通知。
原因很單純：一旦討論從 PR 跑到其他聊天室，脈絡和認知就會分散。
這樣做的好處是：即時有人錯過當下討論，也能在 PR 裡追蹤完整脈絡，發揮「非同步溝通」的效果。
學會放手：不要讓 PR 卡死
另一個常見的阻力，是大家覺得 Reviewer 的建議「都要改完」，才能讓 PR 過關。剛開始時，我也有這種心態，結果就是 PR 生命週期拉得很長，功能很難 Deliver，開發者的成就感也隨之下降。
後來我們在團隊內練習一個觀念：提出 Comment，不代表一定要馬上解決。
如果不是緊急或核心的問題，可以在 PR 裡說明後，另外開一張 Ticket 留待後續處理。(關鍵是必須持續追蹤，而不是敷衍了事。)
這樣既不會忽略建議，也能確保開發進度不中斷。
而這樣的概念不只是 Developer 要有，Reviewer 同樣也必須接受，如同我在 〈成為更重視 Code Review 的工程師〉 提到的：
“只要這段內容有確實提升整體 Codebase 品質，Reviewer 就應該傾向接受。”
保留彈性：給團隊適應的空間
再完善的制度，也需要時間讓人適應。
因此，我們沒有一開始就規定所有人必須在 N 天內完成 Review，而是讓每位成員自行 Commit 「合理的 Response Time」。
在我們團隊，有人設定 1 天、有人設定 3 天。這樣做的好處是彼此一開始就知道期待，不會陷入「怎麼都沒人回」的焦慮。
這樣一來，當 PR 超過這段時間沒回覆時，開發者就能合理判定「對方掉球了」，此時進行友善提醒也就名正言順，不會顯得強硬。
這種做法除了讓流程更順暢，也建立了彼此的信任：我尊重你對自己時間的安排，你也承諾會在這個時限內回覆。這比單純的規範，更能累積出團隊的默契。
Code Review 不只是挑毛病
我看過一些團隊嘗試推敏捷、導入看板，最後卻在真正享受到利益之前，被「規則」壓垮。
Code Review 也是。如果只把它當作「挑毛病」的戰場，很快就會消磨掉熱情。
延續前面提到的「合作系統」，一個好的 Code Review 也可以是：
- 請益：「為什麼會選這個語法？」
- 稱讚：「這個寫法很漂亮！我學到了！」
人都喜歡被肯定，在 Review 中適時給予稱讚，或是認同其他 Reviewer 的觀點，都能讓氛圍更正向，而我認為這是成功推動 Code Review 文化的秘訣之一。
這樣的風氣，會讓更多人願意主動參與。
讓團隊更好的系統
一個文化的建立，不會在短時間內一步到位。它需要不斷的對話、練習以及修正。
對我來說，推動 Code Review 並不是「多了一道流程」，而是讓團隊更願意彼此學習、彼此補位。當每個人都能在 Review 裡看見自己的價值，也看見他人的觀點，這種正向循環才是真正的文化。
如果你也正在推動 Code Review，或許不必急著做到完美，而是先讓大家感受到：這是一個能幫助彼此、讓團隊更好的系統。
當這樣的信念持續被實踐，團隊的文化就會慢慢成形。
加油！
也謝謝你的閱讀，如果對於 Code Review 有不同的看法，也歡迎留言交流！
我們下次見。
About Byte & Ink
我會定期在部落格分享不同主題的文章，目前包含：
- 職涯心得
- 個人成長
- 筆記軟體 - Obsidian 教學
- 技術相關 (
K8S,DevOps,軟體測試…)
如果你覺得內容有幫助，歡迎你點此訂閱我的文章，你的訂閱會帶給我更多動力，持續分享有意義的內容！