實戰流程：Critique 審查工具 (Code Review in Practice)

作者在工作區寫好變更，上傳一個快照（snapshot）到 Critique，觸發自動化分析器（analyzers）執行。此時 Critique 讓作者換上 Reviewer 的帽子：以審查者視角看自己的 diff、看分析結果，先自我打磨。

• diff 元件基於最佳化的 LCS 演算法，支援語法高亮、交叉引用（Kythe）、字元級行內差異、忽略空白、搬移偵測（不天真地顯示成「這刪那增」）。
• 支援疊加與**並排（side-by-side）**兩種模式。
• 作者可把變更連到特定 bug 提供脈絡，送審時還能附上初步評論、直接向 Reviewer 提問。

作者對 diff 與分析結果滿意後，把變更「寄送（mail）」給一或多位 Reviewer。在 Google 規模下「找誰審」本身是個問題，Critique 會建議一組足以核准的 Reviewer，考量：誰擁有這段程式碼（ownership）、誰最近改過它、誰現在有空（未休假、同時區佳），以及 GwsQ 團隊別名設定。指派同時觸發 presubmit hook（跑測試、強制專案規範等）。

評論是僅次於看 diff 的第二常見操作，且任何人都能評論（所謂 drive-by review）。

• 評論預設為 unresolved（未解決），代表作者必須處理；也可加 resolved 的資訊性/選擇性評論。
• 評論是逐條草擬、最後一次性「發佈」（atomic publish）——讓 Reviewer 看完整個變更再一口氣給出完整想法。
• 快捷回覆：作者按「Done」表示已處理、按「Ack」表示已閱讀（多用於資訊性評論）。
• Attention set（關注集合）：Critique 標示目前輪到誰，名字以粗體呈現，回應了 code review「回合制」的本質。

// Reviewer 在這一行留下 unresolved 評論：
//   「這裡沒處理 items 為空陣列的情況，reduce 會丟錯 → Please Fix」
function averagePrice(items) {
  return items.reduce((s, i) => s + i.price, 0) / items.length;
}

// 作者上傳新快照回應，並按下 Done：
function averagePrice(items) {
  if (items.length === 0) return 0; // ← 依評論修正
  return items.reduce((s, i) => s + i.price, 0) / items.length;
}

步驟 3 與 4 可能來回多次；作者與 Reviewer 隨時能比較任兩個快照的差異。

變更的「評分」分三部分：LGTM（我審過、符合標準、處理完評論即可提交）、Approval（作為把關者，我允許它進 codebase）、以及未解決評論數。當變更至少一個 LGTM + 足夠 Approval + 零未解決評論時即可提交，UI 以綠色頁首醒目標示。

• 每個變更都需要 LGTM（不論 Approval），確保至少兩雙眼睛看過。
• LGTM/Approval 是硬性要求（只有 Reviewer 能給、可隨時撤回）；未解決評論是軟性要求（作者可自行標為已解決）。
• 刻意簡化：評等永遠是正面的（拿掉了早期的「Needs More Work」）；要求重審就加評論但不給 LGTM。所有負面回饋都必須綁定具體待修項（unresolved comment），Reviewer 不能只「按反對」而不給有用回饋。

Critique 提供一個提交按鈕，讓作者不必切到命令列——在同一工具內走完「建立到提交」的完整生命週期。若 presubmit 通過，變更即進 codebase。提交後，Critique 仍是**變更考古（change archaeology）**的工具：任何人都能瀏覽一般可見檔案的變更歷史、評論與演化過程，支援日後稽核、理解「為何這樣改」或「bug 如何被引入」。甚至支援提交後繼續評論。