回到 Blog 中文 EN
協作技能 2026-05-29 · 11 分鐘讀

Code Review 怎麼做？
8 個讓 PR 不被 reject 的技巧

Code Review 不是「審判」、是「教學現場」。寫 PR 的人不該被批評、Review 的人不該擺架子 ─ 兩邊都用對方法、Code Review 會變成整個 team 變強的最低成本管道。這篇拆給寫 PR 的人 + 看 PR 的人各 8 條心法。

先建立3 個共識

01 Review 的是code、不是人

這個觀念聽起來簡單、實務上 70% 衝突都來自混淆這條。

  • 對：「這段 code 假設了 input 一定是 array、漏掉 null 的情況」
  • 錯：「你沒考慮 null、太粗心了」

差別在 ─ 第一句是描述 code、第二句是評價人。永遠講 code、不講人。

02 Reviewer 不是守門員、是合作者

很多 reviewer 把自己當「守關卡的」 ─ 看誰能闖過自己的標準。

真正的 senior reviewer 把自己當「幫作者把這個 PR 變更好的人」。同一邊、不是對立。

03 作者不是被審、是請求 input

開 PR 不是「拜託大家放我過」、是「我做了這個、請大家幫我看有沒有想到的」。

姿態對了、PR review 才會變成有產出的對話、不是政治攻防。

給寫 PR 的人 ─ 8 個讓 reviewer 想 approve 的習慣

01 PR title 寫成「action + scope」

❌ Reviewer 看了想關掉

fix bug
update file
WIP
more changes

✅ Reviewer 看了想點開

fix(auth): handle expired token in middleware
feat(payment): add Stripe webhook for refunds
refactor(order): extract pricing logic to service

PR title 是 reviewer 看到的第一個東西、它傳達你有沒有用心。

02 PR description 寫「why」、不只寫「what」

一個好 PR description 模板： 

## Why
[為什麼需要這個改動？背景、痛點、相關 ticket]

## What
[改了什麼？高層次描述、不用列每個檔案]

## How
[關鍵設計決策、特別是「為什麼選 A 不選 B」]

## Testing
[怎麼測？有什麼 edge case 已考慮 / 沒考慮]

## Screenshots (if UI)
[before / after 對比]

## Reviewer hints
[reviewer 該特別看哪邊？哪邊是 trade-off？]

5 分鐘寫這個 description、可以省你後續 30 分鐘的「為什麼？」往返。

03 一個 PR 只做一件事

常見的爛 PR：「重構 auth + 修 payment bug + 加新 API + 更新 deps」 ─ reviewer 不知道該看哪。

好 PR：1 個明確主題、即使你順便修了小東西、也分開 commit、讓 reviewer 看得出來。

原則 ─ 1 個 PR 不超過 400 行改動。超過、拆成多個。

04 自己先 review 一次

開 PR 前、用 GitHub 的 "Files changed" tab 自己看一遍。

你會發現：

  • 剩下沒刪的 console.log
  • 沒清乾淨的註解 // TODO 之後改
  • 不小心 commit 的測試資料
  • 明顯命名 typo

這些小東西自己抓、別讓 reviewer 抓。Reviewer 抓到這些、會降低對你「整體用心程度」的評價。

05 給 reviewer「導讀」

PR 大的時候、用 inline comment 自己先標重點： 

// PR 上的 inline comment：
"@reviewer 這段是新的 pricing logic、
從 OrderService 拆出來、邏輯本身沒改、
只是改 dependency injection 方式。"

這叫「幫 reviewer 省時間」 ─ senior 工程師都會這樣做。

06 不要 push back所有建議

有些作者收到 comment 第一反應是「解釋自己為什麼這樣寫」。

這沒錯、但要分情況：

  • Reviewer 講的明顯有理 → 直接改、不要辯
  • 有設計取捨需要說明 → 寫 1-2 句解釋
  • 真的有不同意見 → 列 trade-off、邀請討論

每個 comment 都 push back 的人、reviewer 下次不想 review 你的 PR。

07 CI 失敗別讓 reviewer 等

常見壞習慣：開 PR 後 CI 紅了、不修、把責任推給 reviewer 「幫我看一下吧」。

Senior 工程師 ─ CI 紅了、自己先修。修完 CI 綠了再 ping reviewer。

這是對 reviewer 時間的尊重。

08 Approve 後也要追蹤

很多人 PR approved 就忘了。

Senior 工程師：

  • Merge 後追線上 deploy 有沒有問題
  • 有 metric 的話、看 KPI 有沒有變化
  • 1 週後回頭看 ─ 這個改動有達到當初目的嗎？

這叫「對自己的 code 負責到底」、不是「丟給 reviewer 就結束」。

給看 PR 的人 ─ 8 個 reviewer 心法

01 看 PR 前、先問「它想解決什麼」

不要打開 PR 直接看 code diff。

順序：

  1. 讀 PR description ─ 它想做什麼？
  2. 讀相關 ticket / spec（如果有）
  3. 再看 code diff

沒有脈絡看 diff、你會 review 出無關緊要的東西、漏掉真正的問題。

02 從大方向看到細節

Review 的順序：

  1. 架構 / 設計 ─ 這個 PR 的 approach 對嗎？
  2. 邊界 / 介面 ─ 新增的 function / API 命名跟責任清楚嗎？
  3. 邏輯 ─ 實作有沒有 bug？edge case 處理了嗎？
  4. 測試 ─ 有對應的測試嗎？
  5. 細節 ─ 命名、code style、註解

順序顛倒 = 你會花 30 分鐘挑命名、然後發現整個 approach 都錯、要重來。

03 用「nit」前綴標記非阻擋意見

不是所有意見都同等重要。 

// 範例
nit: 這個變數名可以改成 userCount 更清楚
suggestion: 這裡可以考慮抽成 helper function
question: 這段的 trade-off 想了哪些方案？
blocking: 這個 query 會 N+1、上線會炸
  • nit：小事、作者可以選擇改不改
  • suggestion：建議、不阻擋 merge
  • question：問問題、不是要求改
  • blocking：必須改才能 merge

這樣作者知道「哪些一定要改、哪些可以留 backlog」。

04 每個 comment 寫「為什麼建議改」

❌ 沒人能學到東西

「這裡寫得不好」
「用 for 不好」
「這個太複雜」
「這不對」

✅ 作者下次自己會

「這裡 if 巢狀超過 3 層、抽 helper function 讓邏輯線性」
「for + push 改用 map、會更明確表達『轉換陣列』的意圖」
「現在 4 個 state 互相依賴、改用 useReducer 集中管理會比較好維護」

每個 comment 至少包含：是什麼問題 + 建議怎麼改 + 為什麼。

05 找1-2 個值得讚的點

這是最被低估的 review 技巧。

作者開 PR 心理上是緊張的（怕被批評）。你留 1-2 個正面 comment ─「這個拆分很乾淨」、「這個命名很到位」、「這個測試案例想得很全面」 ─ 會讓作者更願意收下你的批評。

這不是「表面客套」、是「心理學上有效」。

06 留 1 個「我學到了」

找 PR 裡讓你「哇、這樣寫真好」的地方、寫一句 comment：

「沒想到 Promise.allSettled 用在這個場景這麼乾淨、我學到了。」

兩個效果：

  1. 作者被肯定、下次更願意接受你 review
  2. 你真的會記住這個 pattern、自己之後也會用

07 不確定就問、不要假裝懂

看不懂某段 code 的時候、最差做法是「假裝懂、approve」。

正確做法：留 question comment：

「這段的 timing 我沒看懂 ─ 為什麼是 200ms？是有 spec 要求嗎？」

問問題不丟臉。假裝懂、出事就是你連帶責任。

08 不要當最後一道防線

Reviewer 最容易過度承擔的責任 ─ 覺得「我得抓出所有 bug、不然 merge 進去就是我的鍋」。

錯。

Reviewer 不可能取代測試、不可能取代 CI、不可能取代 monitoring。你的工作是「盡力幫忙、不是 100% 保證」。

如果你的 team 把所有品質責任推到 reviewer 身上 ─ 流程是錯的、不是你的問題。

爭執處理 ─ 3 個原則

01 區分「原則」跟「偏好」

  • 原則：違反會出事的（安全、效能、測試）→ 不讓步
  • 偏好：你喜歡 A、他喜歡 B、兩個都沒錯 → 作者決定

多數爭執是「偏好」 ─ Reviewer 喜歡 functional、作者喜歡 imperative。沒有對錯、讓作者選。

02 講不清楚就跳出文字

PR comment 來回 5 次還沒共識 ─ 直接約 15 分鐘語音通話。

90% 的爭執其實是「文字溝通不到位」、不是真的意見不合。語音 5 分鐘解決、不要在 GitHub 上吵 1 整天。

03 真的拍板不下、找第三方

兩個人各執一詞、誰也說服不了誰 ─ 找 tech lead、或團隊 senior 拍板。

重點 ─ 找拍板的人、不是「誰大聲誰贏」。

AI 時代的 Code Review

2025-2026 年、AI code review 工具（CodeRabbit、GitHub Copilot Review、Cursor Review）越來越強。

AI 能做的

  • 抓 lint / type / 明顯 bug
  • 建議命名、code style
  • 點出潛在 null / undefined
  • 檢查測試覆蓋率

AI 做不到的

  • 判斷「這個架構選擇對嗎」
  • 判斷「這個 trade-off 適合我們團隊嗎」
  • 知道「上次類似 feature 怎麼做的」
  • 提供「政治脈絡」（這個改動會不會影響另一個 team）

建議組合方式：

  1. PR 開出來 ─ AI 先自動 review 抓 nit / 明顯 bug
  2. 作者根據 AI feedback 改一輪
  3. 人類 reviewer 進場、專注在架構、設計、商業脈絡

這樣人類 reviewer 不用浪費時間挑分號 / 命名、能專注在「AI 看不到的」價值。

最後一個提醒

Code Review 的長期價值不在「抓 bug」、在「傳遞 team 的工程文化」。
新人從你 review 的方式、學到 team 在乎什麼、討厭什麼、追求什麼。
一個 team 的水準 ─ 往往就是它 PR comment 的水準。

這也是為什麼資深工程師花這麼多時間 review ─ 它是用最低成本、把整個 team 拉到自己水準的方法。

下次 review 別人 PR、別只想著「有沒有 bug」 ─ 想想「這個 comment、3 年後新人看到、學到什麼」。

Code Review 卡關、想要有人 sanity check？

30 分鐘 1-on-1 諮詢 NT$1,500 ─ 帶你 mock review 你最近一個 PR、給你具體的改善方向。

LINE 預約諮詢 先訂閱 Newsletter