程式碼審查實務準則 (Code Review Best Practices)

• 「小型」通常指約 200 行程式碼以內；Google 約 35% 的變更只動一個檔案。
• 小型且原子性的變更更容易追蹤 bug 來源、也更容易 rollback。
• 幾乎所有 review 都只由一位 Reviewer 審——正是小顆變更讓這個優化成為可能。

// ❌ 一顆變更塞了三件事：重構 + 新功能 + 順手修 bug
//    Reviewer 難以聚焦，rollback 時三件事被綁死。

// ✅ 拆成三顆各自聚焦的 CL：
//    CL 1: refactor — 抽出 calculateTax()（無行為改變）
//    CL 2: feat     — 新增 applyCoupon()
//    CL 3: fix      — 修正四捨五入誤差 + 對應測試
function calculateTax(order) {
  return order.taxableTotal * order.region.rate;
}

每顆都聚焦單一議題，好審、好追、好回退。

• 大多數變更預期在約一天內收到初始回饋（不是一天內完成審查，而是一天內給出初步回應）。
• 對 Reviewer 的硬性期待：在 24 個工作小時內回覆；若當下無法完成，至少回一句「收到、會盡快」。
• 不要零碎地（piecemeal）給回饋——沒什麼比作者回應完一輪後又收到不相關的新意見更令人沮喪。一次講完。

• 大多數 review 恰好由一位 Reviewer 審。
• 業界傾向找更多人、求一致同意，但 Google 發現這是邊際效益遞減——最重要的 LGTM 是第一個，額外 Reviewer 的成本很快超過價值。
• 若真需多人，各 Reviewer 應聚焦不同面向，而非重複審同一件事。變更可 CC 給相關團隊，但只有主要 Reviewer 需要給 LGTM。

• 第一行至關重要：它會成為 review 工具的摘要、email 主旨、以及 Code Search 中的歷史摘要行。
• 描述要講清楚改了什麼和為什麼改。「Bug fix」對 Reviewer 和未來考古者都毫無幫助。

// ❌ Bug fix
// ✅ fix: 折扣金額出現負數時回傳 0
//
//    當 order.total 為負（退貨情境）時，discountFor() 會算出
//    負折扣並被錯誤地當成加值。加上邊界檢查與對應測試。

• Reviewer：尊重作者的實作方式，只在方法有明確缺陷時才建議替代方案；若作者能證明多種方法同樣有效，接受作者偏好；在問「為什麼這樣做」之前，別假設它是錯的。
• 作者：記住「你不等於你的程式碼」（you are not your code）；把每條評論當成 TODO——不一定照做，但必須回應；在雙方都有機會提替代方案前，別擅自把評論標成已解決。意見不一致時可提替代方案並請 Reviewer PTAL（please take another look）。

• Code review 是人工流程，但機械性的部分該自動化——投資工具會回本。
• Google 的 Presubmit 機制：變更送出前先跑格式、lint、測試等檢查，把問題擋在「寄出尷尬 email 給 Reviewer」之前，要求作者先修。
• 自動化讓 Reviewer 專注在真正重要的議題上，而不是格式細節。