來一場兼顧程式碼品質及開發效率的 Code Review

在帶領產品團隊幾年後，深深覺得 Code Review 是很好用的工具，但同時又有很多坑要踩。所以，這篇就以自己多年來的經驗，整合一些研究的資料，分享給大家。

軟體開發中的常見問題

在軟體開發的過程中，大家或多或少會遇到這些情況：

• 團隊成員臨時請假或缺席：原本安排的開發或審查進度被延遲。

• 程式碼的可維護性降低：隨著功能的增加，程式碼的複雜度也不斷提升，開發時間被拖得更長。

• 產出品質不如期望：功能上線後總是自帶 bug。QA、PM、老闆、客戶、使用者們持續質疑：“為什麼我們的產品問題這麼多？”

• 開發者對自己的程式碼沒有信心：不知道是否已涵蓋所有的需求，或者擔心某些邊界情況會導致系統故障。不僅影響個人工作效率，還可能拖累整個團隊的進度。

加個審查的關卡：Code Review

針對上述的挑戰，許多團隊會選擇透過 Code Review 來改善問題。這裡是一般人對 Code Review 的期待：

我們期望 Code Review 可以...

• 促進團隊合作與知識分享：
  • 提高團隊的巴士指數，確保更多人對關鍵程式碼有了解。
  • 幫助新進開發者快速熟悉團隊的技術風格與最佳實踐。
• 提升程式碼品質與可維護性：
  • 檢查程式碼是否符合團隊的標準。
  • 減少技術債的積累，讓未來的維護變得更容易。
• 確認有照規格完成，減少 bug：
  • 確保功能實作與需求一致，避免漏掉關鍵細節。
  • 透過多雙眼睛的檢視，發現潛在的問題。
• 提高佈署信心：
  • 有了團隊的共同背書，讓每次的佈署變得更加安心。
  • 尤其在跨部門合作的情境下，Code Review 可以減少因為疏漏導致的反覆修改，提升團隊信任感。

Code Review 的現狀與挑戰

理想很豐滿，現實總是辛苦許多，這裡列出幾個常見的挑戰：

非常耗時

Code Review 是一項非常耗時的任務。對於一般團隊來說，平均需要花費每位開發者約 6 小時/每週，自己的最高紀錄是一週花上 30+ 小時在審查。這意味著，每個工作日都要花費幾個小時在審查別人的程式碼上，而自己的開發進度卻被大幅壓縮。

PR 從開啟到 Merge 通常會拖延多日

因為 Review 非常耗時，Pull Request（PR）的整個流程就需要耗費數天甚至更長時間。特別是那些 大型且複雜的 PR ，隨著 PR 從開啟到完成的時間拉長，開發迭代的節奏也會被拖慢。

無法如預期的找出問題

根據研究數據顯示，只有 14% 的審查回饋是關於實際問題的。這意味著，花上許多時間的 Code Review 對於直接的減少錯誤幫助有限。

在這裡我們先暫停一下，思考一個重要問題：

Code Review 的本質是什麼？

這是我的答案：

Code Review 的本質是透過知識與視角的交流，提升產出品質與團隊技術水準。

聽起來很美好，開發者希望審查能真正提升程式碼的品質；但是另一方面，這些耗費的資源對開發團隊又是極大的負擔。

兼顧程式碼品質以及開發效率的 Code Review

現在，回到這篇文章的主題，透過 Code Review 提升程式碼品質的同時，最大程度地降低對開發效率影響。這裡從三個層級來解析 Code Review，分別是：

1. 技術執行面：聚焦於 Code Review 本身的進行方式，包括選擇合適的形式、同步與非同步的搭配，以及審查的範疇甚至審查的關鍵點。

2. 知識交流面：這部分著眼於 Reviewer 與開發者之間的互動和知識傳遞。執行面之上，Code Review 更是一個促進團隊成員溝通的過程。我們需要考慮如何在交流中提高效率，讓知識順暢的流動。

3. 整體開發面：站在更高的層次，從整個開發流程的角度來看 Code Review，尋找可以優化的環節。什麼東西應該左移、採用更小的任務單位、或透過自動化工具等，讓 Code Review 進行的更加順暢。

這三個層級將 Code Review 拆解為點、線、面。技術執行面是點，知識交流面是連結的線，而整體開發面就是完整的面。接下來將一一解釋這三個層級的重點與實作方式。

技術執行面

Code Review 的執行方式直接影響其效率和效果。進一步拆解可以分成 審查的形式 以及 審查的層面 。

審查的形式

Code Review 的執行方式可以粗略分為 同步 和 非同步 兩大類，每種形式都有其特定的應用場景和特點。

同步形式

同步的 Code Review 是即時進行的，需要兩個以上的人同時參與：

• Pair Programming：兩人一組即時協作，一人負責編寫程式碼，另一人即時審查和提供建議。

• Live Review：開發者與 Reviewer 即時同步進行程式碼審查與討論的一種方式，透過即時互動快速解決問題並確認程式碼品質。

• Code Review Meeting：團隊成員集體參與的審查會議，針對關鍵程式碼變更進行深入討論，以獲得多方視角並提升產出品質。

• Code Walkthrough：偏向知識交流性質的互動，由開發者逐步解說程式碼的邏輯與功能，團隊成員主要是以觀察與提問的角色參與，目的是提高對程式碼的理解和學習。

同步形式的特點在於即時性和互動性，因此可以快速解決問題或進行深入討論，但需要多方同步時間，會增加時間成本。

非同步形式

非同步的 Code Review 則不需要參與者即時作業，所有的審查和回覆都透過數位載體進行，例如：

• PR Review：開發者提交 Pull Request，Reviewer 可依據自己的時間查看代碼變更、留下評論並進行交流。

非同步的優勢在於彈性高，適合分布式團隊和不同時區的協作，但缺乏即時互動，對於複雜變更的討論可能會受限。

同步與非同步的本質區別

同步形式強調即時的互動，適合複雜或緊急的變更；而非同步形式則重在時間彈性，讓參與者可以依自己的步調完成審查。兩者各有其適用場景，下面表格列出幾種形式的比較。

比較表：各種 Code Review 形式的特性與應用

該用哪種形式

在進行 Code Review 時，可以根據開發任務的「複雜度」與「緊急性」將其分布在四個象限內，來決定使用哪種審查方式更為合適。

越複雜的變更越需要人為的直接參與，確保有足夠深度的討論與檢驗。而越緊急的則是需要加快審查速度，比較簡單的任務如果有通過測試且有信心，那不審查直接上線有何不可？

審查時的不同層面與要點

Code Review 涉及多個層面，以下逐一介紹不同的層面，以及每個層面的審查重點

程式碼規範

程式碼規範目的是保持專案的一致性，讓所有開發者能快速理解和延續代碼。具體包括以下要點：

• 遵循專案的程式碼樣式規則、命名規則：確保程式碼的格式整潔並具有一致性。
• 具有可讀性：程式碼應清晰、簡單，方便他人快速理解。這包含了變數的命名應該明確的指出其作用或意圖。

樣式規則部分可以高度自動化，例如透過靜態程式碼分析工具檢查格式及簡單的命名規範，比如是否有遵照 CamelCase 來命名。比較難自動化的是可讀性的部分，這部份會需要人工審查來處理。好消息是部分可以交給 AI 來處理，Copilot / Cursor / Windsurf 都有類似的功能，如圖是我使用 cursor chat 『檢查檔案內的程式碼的可讀性』

測試

測試本身也是一種自我審查，需要注意的重點：

• 測試是否與需求規格一致，覆蓋所有範疇。
• 確保所有測試通過，特別是針對新功能的合理測試。
• 邊界狀況的測試，檢查極端或異常情境是否能正常處理。
• 非功能性需求（NFR）的測試，例如性能、穩定性及安全性。

測試通常會與 CI/CD 工具結合，自動化的進行。

文件

良好的文件是團隊知識傳遞與延續的關鍵：

• 新功能的紀錄是否充分：功能的背景、目的、設計邏輯及實作細節是否清楚。
• 相關文件的同步更新：如 README、API 文件、使用者引導等，確保文檔反映當前狀態。
• 文件的可讀性與可查找性：讓文件成為日後查詢或維護的重要資產。

程式碼是工程師的 Single Source of Truth，而文件可能散落在不同地方，因此文件要完整之外，『是否容易的被找到』、『是否是最新資訊』都是很重要的。找不到的文件等於沒有幫助，錯誤的資訊更有可能導致開發方向錯誤，這些都是需要注意的地方。文件的部分可以自動化的不多，但可以透過 AI 加上文件範本來產生草稿。

實作

實作層面自然是 Code Review 的重點，我們要看的是：

• 滿足功能需求：實現既定的需求，並無遺漏。
• 邏輯正確且簡潔，避免不必要的複雜度。
• 健全：能夠處理意外的輸入、邊界情況和故障，系統不會因此崩潰。
• 安全性：如避免 SQL 注入、XSS 等風險。
• 可觀測性：加入足夠的日誌、追蹤或指標，便於後續運維與狀態監控。

實作部分的複雜度及變化程度高，因此需要大量人工介入。好消息是 AI 審查工具（或簡單的 prompt ）可以幫忙處理複雜度較低的審查。

邊界

邊界指的是這次的變更範圍之外，有可能碰到這些變更的系統或外部資源、使用者。比如說這次改了一個資料庫屬性，那麼邊界就在該資料庫 table、使用該 table 的 data model、使用 data model 的人，以及其他有可能碰到這個資料庫屬性的。如果改了一個按鈕，那麼邊界就在使用該按鈕的頁面＆使用者。審查重點在於：

• 最小化影響範圍：在滿足需求的前提下，確保邊界簡化，盡量減少依賴。
• 遵循一致性與最小驚訝原則：讓接觸邊界的開發者能快速理解其行為。
• 隱藏內部實現細節：對外界僅暴露必要的功能或接口。
• 現有系統正常運作：任何受影響的部分都需能正常運作。

想像在一個大都會中蓋一條捷運線，這條捷運線的施工範圍、與現有建築的銜接、與既有道路的協調，甚至捷運站和交通流量的整合，都是「邊界」的問題，當功能越繁雜，變動範圍越大，邊界就會越複雜。好消息是許多複雜性是可以左移的，這會在『開發流程面』裡進一步探討。

這五個層面越上方的越容易自動化、理想狀況是盡量自動化上方的，把大部分精力放在最後兩個：實作與邊界的審查。

AI Code Review 工具

最近開始使用了一款叫 Code Rabbit AI 的工具，它是一個免費的開源工具，且整合起來相當簡單。透過這類工具，我們可以提升 Code Review 的效率，對於基礎問題的審查很有幫助。

以下是一些關於使用 AI 工具的要點與觀察：

• 完善但 Junior Level 的審查
  AI 能有效且即時幫助找到語法、語意或簡單邏輯錯誤、API 使用一致性等問題，光是這些就可以提升程式碼的基本水準。
• 清楚的規格書是關鍵
  跟人類一樣，輸入的規格越清楚，AI 工具越容易產出相關度高的結果。因此，清楚定義規格書或需求文檔，對於 AI 工具的應用有顯著的正面影響。
• 不要期望會有個 SENIOR AI 來救你
  但它通常無法理解過於複雜的功能、架構性設計或系統級別的問題，因此不要期望可以看到方向正確的建議。對於核心架構相關的內容，仍需人工參與。
• 適當控制檔案數量
  當變更檔案數量過多或範圍過大時，AI 的建議品質可能會下降。因此，合理規範變更範圍，能確保 AI 工具的有效性。

AI 可以省去許多挑小錯誤的時間，因為有時候 Reviewer 一直在挑小地方也會怕被對方覺得自己很煩。這也是 AI 的一個好處，讓他去背一些鳥毛的黑鍋。

提升執行面效率

稍微總結一下執行面可以做的：

• 選擇正確的 Code Review 形式
  適合的審查形式能大幅影響效率。例如，對於較緊急較複雜的需求，可以選擇同步進行的 Live Review 或 Pair Programming；而針對常規變更，非同步的 PR Review 更為彈性。
• 自動化工具的運用
  將靜態程式碼分析、單元測試、整合測試等自動化流程納入 CI/CD 管道中，可以確保基礎層面的程式碼品質在提交前就被驗證。
• 專注於實作與邊界審查
  Reviewer 的精力應該放在審查實作及邊界是否合適，尤其是比較複雜、難以被電腦審查的部分。
• AI 化的輔助審查
  AI 的作用更像是個萬能的小助手，減少工程師在簡單邏輯上耗費的時間，轉而專注在複雜有價值的功能討論上。

知識交流面

正確的理解後才能正確的給予回饋

Code Review 最大的挑戰是『理解內容以及理解變更的理由』

Code Review 的本質在於透過知識交流提升團隊的技術能力與產出品質。然而，知識交流本身就是很大的挑戰。根據研究，Reviewer 往往需要花費大量時間來消化 PR（Pull Request）的背景資訊，特別是當變更涉及複雜邏輯或多個模組時。缺乏足夠的上下文很容易導致錯誤的審查重點，或無法對問題提供建設性的回饋。特別是在大型團隊或長期專案中，每位 Reviewer 的背景知識不同，更需要清楚、具體的描述來協助理解。

以下是 Reviewer 可以採取的具體行動：

• 閱讀 PR 描述與提交記錄
  確保自己了解這次變更的目標和範疇，專注在審查有價值的項目，避免浪費時間在不相關的細節上。
• 參考測試與相關文件
  從測試案例和規格文件中了解變更的設計目標與預期行為。
• 主動提問與補充背景資訊
  當遇到模糊或難以理解的部分時，Reviewer 應主動提問並要求補充資訊，而不是直接假設或忽略細節。
• 使用高效的資訊獲取方式
  根據變更的複雜程度選擇適合的交流形式，例如對於小型變更可以使用非同步的方式，而對於複雜的變更則可以安排 Live Review 或 Code Walkthrough，透過即時的交流來釐清問題。
• 記錄討論過程中的關鍵資訊
  在審查過程中將重要的背景資訊或決策理由整理記錄，作為日後的參考依據，這不僅方便 Reviewer 自己，也能幫助團隊其他成員了解變更的考量。

這些措施能夠幫助 Reviewer 在有限的時間內獲取準確的上下文資訊，提高回饋的品質。

交流要點一：更有效率的傳遞資訊

• 圖解 > 口說 > 文字
  Code Review 不是只能用文字回饋，對於變更特別複雜的情況，可以邀請開發者進行 Code Walkthrough，逐行解釋邏輯，甚或把整個功能流程畫出來。
• 面對面 > 線上
  面對面的交流比線上更具效率，可以接收到更多的肢體語言以及物理細節，反饋與互動也都更為即時，能大大減少誤解。
• 同步 > 非同步
  同步的方式能夠更準確即時的傳遞資訊（例如 Live Review 或 Pair Programming）、即時的修正，避免因非同步溝通造成的延遲或資訊落差。
• 正面語氣 > 負面
  使用正面或建設性的語氣能有效提升 Review 的接受度與溝通效果。指出問題之外，嘗試建議替代方案或強調學習機會。研究顯示，採用正面或中立語氣的審查有 80% 的機率被認為是有效的；而帶有負面語氣的審查僅有 57% 的有效率。
• 在程式碼上連結到相關文件紀錄
  也就是在執行面有提到的『可查找性』，越快找到有用的資訊，Reviewer 就能越快依據資訊進行判斷。

交流要點二：API 原則

API 是 Assume Positive Intent 的縮寫，翻譯成中文是：預設善意意圖。API 原則強調我們應該預設每個人都希望把事情做好，並以善意來解讀對方的行為或意圖。特別是在文字溝通為主的非同步 Code Review 中，文字容易缺乏語境，這條原則就顯得更加重要。

當預設對方為善意時，自己也會比較想要幫助對方達成他想達成的目的，回饋自然也會更加正面且有建設性。舉個比方，我們都會想幫助小朋友探索這個世界，比如說學習走路（目的），這時我們的行動是提供幫助，有建設性的。但若對方是我的敵人，我只希望他失敗且不要再來煩我。

API 原則可以建立團隊互信，能讓 Code Review 溝通更為順暢，減少因語氣或誤解而引起的衝突。

交流要點三：明確、可行動的

提供的建議應該明確的點出問題，同時指引出可以行動的方向。但要注意不同人的眼中所看到的明確與可行動是不同的。這裡有兩個回饋，我們可以來思考看看：

1. 「建議考慮一些邊界情況。」
2. 「建議在 calculateCAGR 函式中加入對 starting_value 和 ending_value 是否為零的檢查。目前函式在輸入為零時會因除以零而拋出 ZeroDivisionError。」

對於資深開發者，1 的指引可能已經足夠。但對於新手或對代碼不熟悉的同事，則需要如 2. 提供更多細節。有效的 Review 需要針對對象持續調整，幫助團隊中不同經驗層級的成員，更精準地理解和採納 Review 建議。

案例解析

講到這邊就很想拿大神來當案例，我們來看一下大神的 code review （翻譯版本）：

我們用前面提到的幾點來檢視這個 Code Review Comment：

• 有效率的傳遞資訊：Reviewer 對系統非常理解
• API 原則：嗯，攻擊力滿點
• 明確、可行動的：回饋提供了明確的作法

那，問題來了，站在 Code Review 的角度來說，這樣子的回饋是好還是不好？對品質、對團隊的影響是正面還是負面？

開發流程面

前面我們討論了 Reviewer 可以做的事情，包含 Review 本身的執行以及 Reviewer 與開發者的知識交流。現在我們再把範圍拉大，從整體開發流程的角度來看，還有哪些可以優化的地方？

在功能規劃階段把規格定義與紀錄清楚

在執行面與知識交流面都有提到『規格』的重要性，功能規劃階段是影響開發效率和品質的關鍵。如果在這個階段能夠清楚定義需求，並將規格以文件形式完整記錄下來，那麼在 Code Review 階段就可以減少不必要的討論和反覆修改。例如，如果規格已明確描述 API 的輸入輸出格式、錯誤處理邏輯以及性能需求，那麼 Reviewer 就可以專注於驗證實作是否符合這些要求，而不是再花時間猜測或討論需求本身的細節。

早期把規格討論清楚還有個好處，如果在功能規劃時意識到某些需求並非必需，那麼這些不必要的功能就不會實作，就也不用浪費時間 Review。「The Best Code is No Code At All」，最好的程式碼就是那些根本不需要寫的程式碼。

這裡還是再次提醒，文件的可查找性很重要，在開發時務必讓程式碼與文件、規格緊密結合。這不僅對當下的 Code Review 有幫助，還能方便後續團隊成員對系統的理解。可能是在程式碼中註明相關文件連結，或將規格轉化為測試案例，讓 Reviewer 和開發者都能迅速參照變更的背景與依據，大大提升溝通效率和信心。

接下來我們看兩個統計圖表，透過數據理解 PR 大小跟 Review 效率的關係

PR 大小 vs Review 效用

從這張圖中可以看到，PR 包含的文件數量與其效用密度之間呈現負相關趨勢。當 PR 涉及的文件數量增加時，Review 的有效性開始下降。合理的推論是：大型的 PR 讓 Reviewer 無法全面理解，進一步降低了回饋所能提供的價值。

PR 大小 vs Review 耗時

第二張圖表分成兩個階段，在 PR 修改行數小於兩千時，修改行數越多，Review 和合併所需的時間就越長。當變更行數小於 50 時，平均合併時間僅需不到 2 天（約 36 小時），但當行數達到 500-1000 時，平均耗時攀升至近 4 天。不過當行數超過兩千，合併的時間反而不再增加。這有幾種可能：

1. 大型 PR 可能是一些格式化相關的變更，所以不太需要花時間審查

2. 超過兩千行的難以審查，甚至會跳過審查

整體來說，變更超過 100 行以上，平均合併時間就會攀升到四天，這對開發速度來說可不是個好消息。

精簡 Pull Request

越大的變更範圍，會產生越大的 PR，需要越複雜的架構、規格，也需要愈多時間來理解與審查。那麼，我們是否能反過來作，把要做的功能拆解成一個個小任務小 PR，縮減變更範圍、簡化架構與規格，也能夠降低審查需要的時間。我們可以這樣做：

1. 功能規劃階段把規格、相關文件理清
   重複著訴說功能規劃的重要性，明確的規劃才能讓後續要執行的實作更有依據，也更容易切割、分工

2. 把需求拆成半天可以完成的小任務
   將需求分解為小而可控的開發任務，能幫助開發者保持專注，避免一次性提交大量變更。例如，一個功能可拆分為 UI 部分、API 整合部分和後端實作部分，分別以獨立 PR 提交。這樣的拆分不僅方便審查，也讓每個 PR 的上下文更加明確。

3. 任務相依性拉出來
   任務與任務間的依賴關係需要清楚地建立，這樣才能合理安排每個任務的進行順序。例如，如果後端 API 的實作是前端開發的前置條件，那麼後端的 PR 必須優先完成，確保前端開發不會因等待而停滯。

4. 實作，一個任務一個 PR
   實踐一個任務一個 PR 的原則，讓每個 PR 的範圍可控且清晰。這樣的做法，能減少每次審查的認知負擔，同時降低因多任務糾纏導致的誤解或錯漏風險。這裡可以參考使用Stacked PR。

5. 目標：LOC < 500
   研究顯示，當 PR 的改動行數（Lines of Code, LOC）小於 500 行時，Reviewer 的效率和精確度最佳。因此，我們應盡量將每個 PR 的改動控制在此範圍內。期望這樣的限制，能減少 Reviewer 的負擔，讓審查更有品質。

Self Review：讓交付更有準備

最懂 PR 的人自然是實作的人，Self Review 的成本理論上會比 Reviewer 進行審核的成本來的低，因此不妨試試在交付 Code Review 之前，先進行 Self Review。這不僅能提高 PR 的品質，也能節省 Reviewer 心力。

執行方式有兩種

1. 想像自己就是 Reviewer，審查自己的 PR。

2. 透過 AI Coding Tool 幫忙 Review：
   現在 Copilot / Curosr / Windsurf 都有聊天的功能，可以透過對話請 AI 進行 Review 甚至是即時的修改

這裡提供一下 Review 實作以及邊界的 Prompt

I want you to performing a code review, ensure the following checklist is satisfied:

1. **Fulfilling functional requirements**: Ensuring all specified needs are met without omissions.
2. **Correct and concise logic**: Avoid unnecessary complexity.
3. **Robustness**: Handle unexpected inputs, edge cases, and failures gracefully without crashing.
4. **Secure**: Considered risks such as SQL injection, XSS, etc.
5. **Observability**: Including sufficient logs, traces, or metrics to support maintenance and status monitoring.

Review 邊界的 Prompt

I want you to performing a code review, ensure the following checklist is satisfied:

1. **Minimizing impact**: Ensure the interface are simplified and dependencies are reduced while meeting requirements.
2. **Consistency and the Principle of Least Surprise**: Ensure developers interacting with the interface can quickly understand their behavior.
3. **Hiding internal implementation details**: Expose only the necessary functions or interfaces to the outside.
4. **Existing systems working properly**: Ensure all affected parts function correctly.

附註：在 prompt 中，邊界的用字是 interface ，這是因為在編輯器裡比較難看出邊界在哪裡（要從 PR 看才會比較清楚），因此用 interface 這個比較好理解與判斷的字眼。

其他 AI 工具可以幫忙的

除了協助 Self Review，AI 工具也能在其他環節發揮作用，讓開發和 Code Review 更高效：

• 產生 PR Description （GitHub Copilot）：

• 產生規格文件 / 測試案例： 工程師可以產的有比如像是 API 說明、假資料等，甚至進一步產生一些測試案例，幫助測試或驗證

• 產生相關說明：把程式流程視覺化、解釋複雜邏輯等等

最後

你不一定需要 Code Review

Code Review 雖然是提升程式碼品質的重要手段，但並不是所有情境下都需要耗費團隊資源進行。以下幾個情境可以考慮跳過或簡化 Code Review：

• 高信心測試覆蓋： 如果專案擁有完整的測試覆蓋，對佈署有信心的狀況下，就可以降低對 Code Review 的依賴。

• 改動範圍小且低風險： 比如修改文案、配置檔案，或是與核心邏輯無關的部分，這類改動可以直接由開發者自檢並上線。

• 實驗性質的功能： 某些快速試驗的功能可能在短時間內就會被棄用或改寫，審查不一定有效益。

總結一下，針對 Code Review 有幾個要點：

1. 使用合適的形式： 複雜的改動偏向選擇同步的方式以取得最佳審查效率；一般改動則選擇非同步的 PR Review，讓團隊能依照自己步調進行。
2. 自動化： 靜態程式碼分析工具、自動化測試、CI / CD 這些都是目前開發上的標準配備，甚至是 AI 化 Code Review，幫助檢測一些基本問題。
3. 聚焦於高價值的部分： 將審查心力放在程式碼架構、介面、核心邏輯的審查。簡單的規範問題可以交給自動化工具處理。
4. 明確規格與需求： 在功能規劃階段，清楚定義需求並建立相關文件。清晰的目標能減少後續的誤解、減少不符規格的行為（也就是 bug）的發生機率，同時幫助 Reviewer 更專注於變更是否符合需求。
5. 縮減任務範圍 / PR 大小： 將任務分解為易於處理的小單元，每個 PR 限制在 500 行以下。縮減審查時間，提升審查品質。
6. 先 Self Review： 提交前進行自我檢查，也可透過 AI 工具幫助，確保 PR 已達到基本品質標準。

最後還是要強調，軟體開發是團隊運動，交流和協作是成功的基石。Code Review 不僅是一種提高品質的手段，更是一個能促進團隊凝聚力與技術分享的過程。希望這些整理可以讓你對 Code Review 有一些更深入的想法或作法，如果有想討論的也歡迎透過我的社群帳號找到我～

參考資料

• A Survey on Modern Code Review: Progresses, Challenges and Opportunities
• Automating Code Review Activities by Large-Scale Pre-training
• An Empirical Study on Code Review Activity Prediction and Its Impact in Practice
• Code Review Automation: Strengths and Weaknesses of the State of the Art
• Types of code reviews: Improve performance, velocity, and quality
• The Code Review Pyramid
• Stacked PR
• API Principle