Google Code Review 官方指南

後設資料

URL：https://google.github.io/eng-practices/review/
作者：Google Engineering Practices
發表日：官方頁面未標示
擷取日：2026-09-15
語言：en
文件範圍：
- Reviewer guide：https://google.github.io/eng-practices/review/reviewer/
- CL author guide：https://google.github.io/eng-practices/review/developer/

Code-Review 是作者與 reviewer 共同維護 codebase health 的協作機制：reviewer 用一致標準快速給出可行回饋，作者則以清楚的變更脈絡、小而自洽的 CL 與合作式回應降低審查成本。

官方總覽把 code review 定義為「由程式碼作者以外的人檢視程式碼」，並說明這套文件是 Google code review 流程與政策的 canonical description。
Reviewer 與作者不是對立關係；雙方共同目標是讓整體 codebase health 隨時間改善，同時維持團隊能持續前進的速度。
Reviewer 的最高層原則是：當 CL 明確改善整體 code health 時，即使不完美，也應傾向批准；但不能用這條原則替會讓 codebase 退步的改動辯護。

先看整體設計，再看細節：依序確認改動是否值得做、主體設計是否合理，再按適當順序看完其餘內容；若主設計有問題，應立即回覆，避免作者在錯誤方向上繼續投入。
完整審查面向：design、functionality、complexity、tests、naming、comments、style、documentation、every line、context 與 good things；UI、併發、安全、隱私、無障礙等情境需要實際驗證或適任 reviewer。
速度看 response time：優化目標是整個團隊的交付速度，不是單一 reviewer 的局部產出。若不在專注工作中，最遲應在一個工作天內回應；無法完整 review 時也可先給 broad comments、時間預期或建議其他 reviewer。
評論要可分流：評論 code 而非 developer，解釋理由，並用 Nit:、Optional / Consider、FYI 等標籤區分必要修改、建議與資訊，避免作者把所有留言都當成 blocking。
讓解釋回到 code：若 reviewer 看不懂，作者通常應先簡化 code，必要時補能服務未來讀者的 code comment；只留在 review tool 的解釋無法改善長期可維護性。
處理 pushback：先判斷作者是否因更接近 code 而有更好的技術理由；論證成立就接受，否則補充 code-health 理由並保持禮貌。新引入的複雜度通常應在本 CL 清掉，既有周邊問題若無法同時處理則建立可追蹤的 bug / TODO。

描述是長期公開紀錄：CL description 應同時回答「改了什麼」與「為什麼這樣改」；第一行用簡短、可獨立理解的祈使句摘要，正文補問題、取捨、限制、bug / benchmark / design doc 等脈絡。
小的定義是自洽，不只是行數少：理想 CL 聚焦一項最小、自成一體的變更，包含相關測試，合入後系統仍可正常工作，也提供 reviewer 理解改動所需的完整脈絡。
拆分降低多種成本：小 CL 較快且較完整地被審查、較容易推理與 rollback、減少 merge conflict 與錯誤方向造成的浪費；可按檔案、水平層次、垂直功能或 refactor / behavior change 拆分。
每個依賴步驟都不能破壞 build：多個相依 CL 應安排成每一步合入後仍維持可用；refactor 通常與 feature / bug fix 分開，但相關測試要與行為改動同行。
把評論視為共同解題：先確認自己理解 reviewer 的要求；不同意時用 trade-off、使用者與 codebase 脈絡討論，不把評論個人化，也不在情緒中留下永久性回覆。

連結到此來源衍生 / 更新的 wiki 頁：

候選掃描：

Code-Review — 已存在。本次以 Google 官方 canonical guide 取代單靠中文二手整理的證據位置，並補入原頁較少展開的 CL author 責任。
Pull-Request — 已存在。Google 文件使用 CL（changelist）而非特定平台的 PR，但其「what + why 的永久描述」「一項自洽變更」「相關測試同行」可直接校準 PR / MR 作者端工法。
Google — 已存在。將 Engineering Practices 從「透過二手文章得知的 Google 指南」提升為已 ingest 的官方一手文件。
程式碼風格指南 / 完成的定義 — 已存在。前者補入大規模 reformat 與功能改動分離原則；後者補入一項自洽變更、測試同行、每步合入後仍可運作與新複雜度不延後清理的 CL 級完成邊界。

未新建候選：

CL / Changelist — Google 內部版本控制術語；在一般開發情境可對位 PR / MR / patch，不足以獨立建概念頁。
LGTM — review 結果與溝通標記，仍併入 Code-Review，不建立薄頁。
Small CL — 是 code review / PR 的拆分工法，先併入 Code-Review 與 Pull-Request；待 stacked changes 或專門變更分解來源累積再評估。

來源關係與證據邊界：

2026-05-06-Google-Code-Review 是 Ryan Yang 的中文二手整理，保留其中文轉譯與當時 ingest 決策，不回寫來源層。
本頁直接以 Google Engineering Practices 官方頁為一手來源，並覆蓋 reviewer guide 與 CL author guide；保存的是結構化摘要與逐頁入口，不逐字複製整站內容。
官方文件未標示發布日，故不推測日期；擷取日固定為 2026-09-15，後續內容若改版應另行校準。

觀察清單同步：

已完成 Google Engineering Practices Code Review Guidelines（reviewer + CL author）官方文件 ingest，從「待 ingest 外部資源」移除。
本次沒有新建 wiki 頁，不改 MOC 候選來源數；官方指南與 2026-05-06 中文整理屬同一知識來源鏈，不重複計為兩份獨立領域來源。

官方文件由多個網頁組成，本頁採摘要式保存，避免複製整站。Canonical overview、reviewer guide 與 CL author guide 的逐頁入口已列於「後設資料」；需要核對措辭或最新版本時，以官方頁為準。

tags	來源/文章, 領域/開發, 主題/code-review
aliases	Google Code Review Guidelines, Google Engineering Practices Code Review Guidelines, Google 程式碼審查官方指南