軟體代碼審查（code review）是一種系統化的同儕驅動品質保證程序，當開發者提交 pull request 或 merge request 時，會對程式碼進行仔細檢視。

雖然大家常抱怨不良的代碼審查流程會造成延遲，也可能讓某些人因細微事項而製造瓶頸，但良好的代碼審查能及早發現 Bug、促進師徒關係，並被視為分享責任的民主方式。

事情本該如此，但實際上並非如此。

資深軟體工程師 Mark Dominus 告訴 The New Stack，雖然許多公司確實會執行代碼審查，但它們並未「清楚說明審查的成果應該是什麼」，這就是問題所在。

「假設你是一位初階工程師，第一次被要求進行代碼審查。你的交付物是什麼？在我工作過的許多地方，交付物從未被明確定義，」Dominus 說。

在 Mastodon 貼文中，Dominus 寫道：「任何依賴代碼審查來找 Bug 的人，都活在愚人的樂園裡」，主要原因是「通常不可能」只靠閱讀程式碼就找到 Bug。他強調，「代碼審查的主要目的」是找出未來維護上會變得困難的程式碼。

導致代碼審查結果不佳的必經之路

他指出，如果期望軟體工程師只是悠閒地瀏覽 變更集（change set），然後指出自己不喜歡的地方，這樣做會導致不良結果，也就是鼓勵人們強制推行自己對程式撰寫方式的偏好，進而引發爭執。

「只靠閱讀變更集來找 Bug 極其困難，而且需要一定的運氣。」– Mark Dominus。

「有時主管會給初階工程師多一點提示，例如：『看看能不能找到任何 Bug』，這反而讓初階工程師處於不利的處境，」Dominus 進一步說明。「也許他們真的找到 Bug，那很好！但如果找不到呢？只靠閱讀變更集來找 Bug，極其困難，而且需要一定的運氣。」

他建議採用另一種做法，由軟體團隊的專案負責人主導代碼審查流程，指示：「花兩個小時仔細閱讀這段程式碼，把你不懂的地方寫下來；如果沒看完，就記錄你看到哪裡。」

真正能為軟體工程帶來價值的做法

「如果審查者沒有時間看完所有內容，那你就獲得了寶貴的資訊：這次的變更太大或太複雜，無法在兩個小時內理解。也許應該把變更集拆成兩份或多份較小的提交，分別進行審查。不管審查者經驗多淺、資歷多淺，或是當天狀態多差，他們都能交付被要求的事情，而這些交付物將具有真正的工程價值，」Dominus 解釋。

這種真正的工程價值在此情境下是一種正向的負面回饋。團隊現在已經辨識出其他成員無法理解的程式碼，或是變更集太大而無法用現有流程有效審查……或者兩者皆是。

代碼審查只是一場戲碼，即將在你附近上演

高負載電商平台公司的 QA 工程師 Mikhail Golikov 大致同意上述觀點，他告訴 The New Stack，如果團隊把代碼審查當成抓 Bug 的工具，那「代碼審查只是一場戲碼」。

「當團隊把審查當成 Bug 過濾器時，他們帶著安心感出貨，卻沒有任何證據，之後才在正式環境中發現問題。」– Mikhail Golikov。

「人類 瀏覽 diff 無法看出 race condition，或是負載過大時折扣變成負數。審查是用來找出你未來會討厭維護的程式碼；測試則是用來找出現在已經壞掉的程式碼，」Golikov 強調。「審查者看到乾淨的 diff、合理的命名和整潔的函式，就點擊核准。但這些都無法告訴你，應用程式中某個關鍵部分已經故障，並向使用者提供錯誤的服務。」

同時也是 開源 Python 測試工具維護者 的 Golikov 解釋，造成這些錯誤的 Bug 並不存在於開發者能讀到的程式碼中，而是存在於程式碼在執行階段所進入的狀態裡。

不要帶著安心感出貨，卻沒有任何證據

「當團隊把審查當成 Bug 過濾器時，他們帶著安心感出貨，卻沒有任何證據，之後才在正式環境中發現問題，」Golikov 確認。「審查要回答的問題是『六個月後我會討厭維護這段程式碼嗎』，而『它是否真的正常運作』則要透過對真實輸入執行測試來驗證，而不是讓人類在下午五點匆匆瀏覽 pull request。」

開發者與廠商普遍認為，代碼審查流程需要改變，尤其在 AI 時代，agentic coding 工具日益普及。

Judah Taub 是 Hetz Ventures 的管理合夥人，他認同上述說法，並告訴 The New Stack，多年來工程團隊一直把代碼審查視為防堵 Bug 的最後一道防線，但這其實從來不是它的強項。

「工程師的角色持續從實際撰寫程式碼，轉向驗證架構、意圖與商業邏輯。未來，甚至連這項工作都可能被自動化。」– Judah Taub。

「代碼審查能捕捉到風格、架構、可讀性與可維護性，」Taub 說。「測試用來捕捉 Bug。正式環境則捕捉其他一切。最好的工程組織不會依賴另一位開發者在數百行程式碼中找出隱藏的邊界條件，而是建立能在 pull request 送到其他人面前之前，就自動驗證正確性的系統。代碼審查的目的是確保下一位工程師能順利接手這段程式碼。」

代碼審查的未來

隨著 AI 生成的程式碼 加入戰局，Taub 認為未來的平衡點將是：人類會減少直接審查程式碼，而是更多地審查 AI 對程式碼的審查結果。

「工程師的角色持續從實際撰寫程式碼，轉向驗證架構、意圖與商業邏輯。未來，甚至連這項工作都可能被自動化，」他預測。

從這些趨勢可以清楚看出，軟體工程團隊確實需要走出 90 年代（如果他們還停留在那個時代的話）。

雲原生、平台工程，以及從 vibe coding 走向 agentic coding 的革命（你也可以加入大數據、DevOps，以及企業開源標準化等趨勢），已經徹底改變了軟體開發者的工作方式，因此審查這些改變的方式，也應該有相對應的調整。

YOUTUBE.COM/THENEWSTACK

科技發展迅速，別錯過任何一集。訂閱我們的 YouTube 頻道，觀看所有 podcast、訪談、示範，以及更多內容。

Group Created with Sketch.