大規模變更與所有權 (Large-Scale Changes & Ownership)

• 大多數 VCS 的操作成本與變更規模呈線性：處理數十個檔案的提交毫無問題，但缺乏記憶體或算力去一次原子提交數千個檔案；集中式 VCS 在處理期間甚至可能阻塞其他寫入者。
• 變更越大，撞上合併衝突的機率越高。在 Google 這種全球公司，永遠有人正在改動 repo——沒辦法「趁週末沒人開發時偷偷提交觸及所有檔案的變更」。
• 把大型變更拆成較小的獨立區塊（chunk），就能繞過這兩道限制；代價是執行過程更複雜。

// 想像一個要在 50 萬處把 scoped_ptr 換成 std::unique_ptr 的變更。
// ❌ 一顆巨大原子 CL：VCS 吞不下、幾乎必然合併衝突、沒人審得完。
// ✅ 拆成上千個各自獨立、可原子提交的分片（shard），逐片跑管線。

• Google 的 CI 不只跑直接受影響的測試，還會遞移地跑所有依賴被改檔案的測試。在 25 個檔案的變更裡找到失敗根因很直接；在 10,000 個檔案的變更裡找一個，像大海撈針。
• 小型獨立的變更，影響的測試集較小、失敗更好診斷——這正是拆片的核心動機之一。取捨是相同測試會被多次重跑，但工程師追蹤失敗的時間遠比多跑測試的算力昂貴，Google 有意識地選了後者。
• 所有變更提交前都需審查，這條政策同樣適用於 LSC。但手動審一顆大型提交既繁瑣又易錯。把 LSC 拆分為獨立分片（shard），才讓審查重新變得可行。

為什麼不直接發布新 API，然後要求所有人自行遷移？因為那無法擴展，理由有三：

• 領域知識集中化：基礎設施團隊最懂底層系統，也最有能力備好處置手冊（playbook）快速修錯；讓每個消費端團隊各自重學一遍，全局極度低效。
• 避免無資金支持的強制命令（unfunded mandate）：好處分散在整個組織、個別團隊缺乏動機主動遷移。集中遷移並統一核算成本，幾乎總是更快更便宜。
• 激勵機制對齊：由「有切身利益移除舊系統」的團隊來負責，才能確保遷移真的被做完——自發性遷移（organic migration）很少能完全成功。

有了基礎設施後，LSC 大致分四個階段（邊界模糊）：

1. 授權（Authorization）：作者填一份簡短文件，說明變更原因、預估影響範圍（會拆出多少分片）、FAQ 與變更描述，並向被重構 API 的擁有者取得「領域審查」。提案交給約十二人的監督委員會——一群熟悉各語言細節的資深工程師。委員會的目標不是禁止 LSC，而是幫作者產出最高品質的變更，並作為衝突的升級裁決機構。真正被徹底拒絕的變更很少，只有危險的（如把所有 NULL 轉成 nullptr）或極低價值的（如英式↔美式拼寫互換）。
2. 變更產生（Change Creation）：盡可能自動化地產生實際編輯，好在使用者回退到舊用法、或發生文字合併衝突時能重新產生。產出的變更應盡量像人寫的——這是需要風格指南與自動格式化工具的原因。
3. 分片與提交（Sharding & Submitting）：見下一折頁。
4. 清理（Cleanup）：建立機制防止已被移除的符號被重新引入。Google 用 Tricorder 在 code review 時自動標記工程師引入新的已棄用物件。

分片與提交是 LSC 基礎設施最核心的一環。Google 的工具叫 Rosie：它把一筆巨大的綜合變更，依專案邊界與所有權規則拆成可原子提交的分片，讓每片獨立走「測試—寄送—審查—提交」管線。Rosie 會限制未完成分片數量、以較低優先級執行，避免壓垮共享的測試基礎設施。

每個分片經過：

• 測試：透過 TAP 遞移地跑所有依賴該片檔案的測試；絕大多數分片影響的測試少於一千個。
• 寄送審查者：Rosie 用一個理解 OWNERS 檔案的所有者偵測服務，依審查能力加權挑選 Reviewer；若某擁有者無回應，自動補上額外審查者。
• 審查：實務上，當地擁有者常過度信任 LSC 工程師、不會用審一般變更的嚴謹度來審。Google 因此只在需要上下文（而非僅需審批權限）時才發給當地擁有者，其餘交給全域審批者（global approver）——他們通常精通該語言／函式庫，不逐一審每筆變更，而是用獨立的模式比對工具自動批准符合預期的變更，只手動檢查因合併衝突或工具故障而異常的少數，讓流程能極好地擴展。
• 提交：通過各專案 precommit 檢查後正式提交。

// 全域審批者的心智模型（示意）：
// 不是逐一讀每筆 diff，而是驗證「這筆分片是否符合預期模式」。
function autoApprove(shard, expectedPattern) {
  if (matches(shard.diff, expectedPattern)) return "LGTM"; // 自動批准
  return "manual-review"; // 只有異常分片才進人工
}

透過 Rosie，Google 能每天有效地產生、測試、審查、提交數千個變更。

常規審查裡，一筆變更要提交需要三種面向的核准：同儕 LGTM（正確性與可理解性）、Code Owner 核准（適不適合進這塊 codebase）、以及 Readability 核准（符不符合語言風格）。分片審查改寫的，主要是中間那一項的「找誰」機制。

Google 的 codebase 是階層式目錄結構，每個目錄可放一個 OWNERS 檔案，列出對該目錄及其子目錄有 stewardship 的人。運作方式：

• 關係是階層累加的：一個檔案的 Owner，通常是其所有上層目錄 OWNERS 成員的聯集。
• OWNERS 檔案可引用其他 OWNERS 或外部存取控制清單，但最終都解析為個別人員名單。
• 根目錄的 OWNERS 可作為大規模變更的「全域核准者」——這正是 LSC 得以繞過各地方團隊、把審查導向單一專家的制度基礎。
• 它同時充當一種文件：人和工具都能藉由往上走訪目錄樹來找到負責人（Rosie 的所有者偵測服務就靠它）。
• 新專案不需向中央註冊，一個新的 OWNERS 檔案就夠了。