在 Google，幾乎每一筆變更在進入 codebase 前都必須經過作者以外的人審查——這是少數強制要求全體工程師參與的通用流程。它確實會拖慢新程式碼上線的速度，但換來的是六項長期效益：正確性、可理解性、一致性、集體擁有感、知識共享，以及一份歷史紀錄。令人意外的是，抓 bug 並不是主要收穫。
🧠 為什麼值得這個成本
程式碼被閱讀的次數遠多於被撰寫的次數，而 code review 往往是「作者以外的人第一次看到這段程式碼」的時刻。這個外部視角能做到連最強的工程師都做不到的事：提供不受作者盲點影響的回饋。
- 正確性（Correctness）：另一雙眼睛檢查測試是否足夠、設計是否合理、功能是否正確高效。IBM 的研究指出缺陷發現得越早，修復成本越低——前提是審查流程本身保持輕量。但這不是 Google 的主要效益。
- 可理解性（Comprehension）：Reviewer 現在提出的每個疑問，未來都會被更多人反覆提出。對理解度的問題，採「顧客永遠是對的」原則——把每個疑問都當成有效的。你不一定要改邏輯，但可能需要解釋得更清楚。
- 一致性（Consistency）：規模化環境下，你的程式碼會被他人維護、被工具重構。透過 Readability 認證確保程式碼符合語言最佳實踐、風格一致、避免過度複雜——一致的模式讓自動化重構成為可能。
- 知識共享（Knowledge Sharing）：這是最被低估的管道。Reviewer 傳授領域知識，作者解釋設計理由，雙向學習。工程師不一定讀每封 email，但通常會回應每次 review。
- 歷史紀錄（Historical Record）：每筆變更連同其審查討論都成為 codebase 的一部分，支撐日後的「程式碼考古」（archeology）。
- 心理與文化效益：強化「程式碼是團隊的、不是你的」的集體擁有感；流程本身扮演「壞警察」緩衝批評的衝擊，Reviewer 得以當「好警察」。
NOTE
程式碼本身就是一種負債（liability）。 它或許必要，但就其本身而言只是給未來某人的維護任務。所以在動手前應先確認需求真的存在、是否已有類似實作。Google 內部甚至有句話：「如果你從零開始寫，那你就做錯了！」但要注意：code review 不是重新辯論設計決策的場合——那該在更早的設計提案、API 審查階段完成。
⚖️ 三種核准，一次審查
Google 的變更要提交，需要三個面向的「核准」，但關鍵優化是：通常一位 Reviewer 就能同時扮演三種角色。
① 正確性與理解度 — LGTM 位元
由另一位工程師確認「這段程式碼做了它宣稱的事，而且可理解」。這反映在 LGTM（looks good to me）權限位元上。預設只需一位 Reviewer 的 LGTM，變更即可提交。這是「至少兩雙眼睛看過」文化的底線。
// 一個小而聚焦的變更：加上邊界檢查。
// Reviewer 一眼就能判斷「正確 + 可理解」→ 給 LGTM。
function discountFor(order) {
if (order.total <= 0) return 0; // ← 這次變更：防止負數折扣
return order.total * 0.1;
}② Code Owner 核准 — 這段能進我這塊 codebase 嗎
Google 的 codebase 是階層式目錄，每個目錄可有 OWNERS 檔案，列出對該目錄負「管理職責（stewardship）」的人。Owner 關注的問題和 Peer Reviewer 不同：「這容易還是難以維護？」「它增加了我的技術債嗎？」「我的團隊有能力維護它嗎？」若作者本身就是 Owner，此核准可隱含完成。
③ Readability 核准 — 符合語言風格與最佳實踐嗎
由具備該語言 Readability 認證的工程師確認程式碼一致、避免過度複雜。Java 程式碼要 Java readability、Go 要 Go readability。若作者已有該認證，此核准亦隱含完成。這三個位元可任意組合：一位身兼 Owner 與 Readability 的 Tech Lead，只需一個同儕 LGTM 就能提交。
TIP
為何不總是找「三合一」的人審查全部？答案是規模化（scale）。把三種角色拆開讓流程有彈性——可以先讓團隊成員來回數輪確認正確性拿到 LGTM，最後再找 Owner 快速核准。最重要的 LGTM 永遠是第一個；後續的邊際效益遞減。
🔑 Takeaways
- Code review 的六大效益是正確性、可理解性、一致性、集體擁有感、知識共享、歷史紀錄——而抓 bug 不是主要那項。
- 為讀者最佳化：程式碼被讀遠多於被寫，外部視角是無法替代的。對理解度的疑問一律當成有效的。
- 三種核准（LGTM / Owner / Readability）常由一人兼任；預設只需一個 LGTM，確保至少兩雙眼睛。
- Code review 不是重辯設計的場合，設計討論該在更早階段完成；它同時也是留給後世的歷史紀錄。
No notes yet — jot your takeaways or Q&A here.