Google 的軟體工程實務與電腦科學教育：專訪 Titus Winters

Titus Winters 曾任 Google 工程師、主掌內部 readability 計畫，現在在 Adobe 帶領開發者體驗（developer experience）團隊。他主張，大學資訊工程系課程大多應該重整，因為現在教的仍是 1990 年代為資料庫打造所需的那套東西。這場訪談大部分時間談 Google 的工程史——一次涉及 2.5 億行的 C++ 重構、2006 年決定強制要求測試，以及 readability 審查制度——之後才轉向 AI 如何打破傳統的生產力指標，以及為什麼應屆畢業生該用提示（prompt）與測試來評分，而不是用程式碼。

Winters 在兩邊都極具發言分量。他在 Google 在職十多年，是《Software Engineering at Google》的第一作者，2023 年仍是 ACM/IEEE 大學資訊工程課程指導委員會中唯一一位仍在第一線寫程式的軟體工程師。以下內容涵蓋他對 Google 強制測試政策的說明、那場重構的運作機制、為何確定性的重寫工具勝過不斷呼叫 AI 推論，以及他認為 AI 的價值展現在更難的工作上，而不是更快完成同樣的工作。

Google 在 2006 年因搜尋失去發布節奏而強制要求測試

Winters 把 Google 的測試文化追溯到一次具體的失敗。大約 2006 年，搜尋失去了按固定節奏出貨的能力——公司目標是每月發布，實際卻只能做到大約每季一次，原因是層出不窮的迴歸問題。當時的架構沒有乾淨切分，改動 Gmail 可能影響搜尋。發布工程師因此劃下紅線：沒有測試就不準合併任何變更，不管副總裁怎麼說；沒有測試的變更一律回滾。

「沒有測試，這個變更就不準合併，就這樣。我們不管副總裁說什麼。」

Winters 說，這條紅線連那些認為寫測試有失身分的工程師都改變了態度。它也讓後來的重構得以進行：接手由員工編號只有兩位數的元老們所寫的舊 C++ 基礎設施之所以安全，正是因為測試安全網已經存在。他更宏觀的原則是——他說這寫在書的最前面幾頁——只要任何有價值的變更都能安全地做出，這個程式碼庫就是可持續的。選擇不做某個變更是可以的；但做不到，就是高風險的賭注，尤其隨著安全壓力日益升高。

他把這個道理延伸到個別工程師身上。新人不敢推程式碼，要不是身處設計不良的系統，就是到職訓練做得太差——兩者必居其一。他怪罪大學教育灌輸了錯誤的直覺：學生被評分的方式是有沒有正確答案，所以他們進來時期待的是判斷對錯，而不是權衡取捨。而人類唯一會去讀大學生程式碼的時候，就是為了打分數。

Abseil 清理是一場 2.5 億行的重構，而且沒讓大樓停工

Abseil 是 Google 的開源 C++ 通用函式庫，大約在這場訪談的十年前（約 2015–2016 年）啟動，時間點就在轉向雲端之後不久、公司改組為 Alphabet 的期間。目標是把低階的 C++ 慣用寫法外部化——快取、容器、字串處理、命令列旗標——Google 內部所有東西都是用這些寫成的。其中有些慣用寫法「又醜又宅」，所以在永久定案之前先清理乾淨。

以 Winters 的說法，規模如下：

他稱這是「人類史上最大的重構任務」，還開玩笑說團隊的工作就像在帝國大廈底下換地基，既不能關閉大樓也不能擋住交通，而且還發現地下室埋了核廢料。主持人補充背景：Uber 在 AI 時代之前的 iOS 與 Android App，各約一百萬行，由大約 200 名工程師花數年寫成；Anthropic 的 Bun 則是約 50 萬至 90 萬行的重寫。

運作機制值得細看，因為它預示了今天關於 AI 輔助重構的爭論：

flowchart TD
    A["把每個 C++ 編譯單元解析成 AST"] --> B["依上下文精確比對函式呼叫，而非只比對文字"]
    B --> C["為 5 萬個以上的呼叫點產生文字編輯"]
    C --> D["新舊 API 在拼寫上並存"]
    D --> E["依目錄平行處理編輯，避免合併衝突"]
    E --> F["搶時間阻止大家繼續複製貼上舊 API"]
    F --> G["刪除舊 API，讓新 API 成為預設"]

有兩個限制形塑了整個做法。第一是空白字元：團隊能產生編輯，卻無法正確擺放空白，所以 Clang Format 之所以存在，部分正是因為 Winters 希望有這個工具。第二是編輯規模：單一涉及 1 萬到 2 萬個檔案的變更，根本不可能在別的工程師的編輯撞上來之前完成測試與重新同步，而要一間一萬人的公司暫停動這個 repo 也不可行。解法就是新舊並存加上平行化，如此重複幾百次。工程師一開始抗拒自己的程式碼被改，後來卻變得依賴它：複製貼上反而成了正確答案，因為任何錯誤都已經被修掉了。

確定性的重寫工具勝過不斷呼叫 AI 推論，而 AI 最適合用來寫這些工具

Winters 認為 Google 的模式已經開始重現，只是改成由 AI 產生確定性的工具，而不是由 AI 親自幹活。在 Java 生態裡，Open Rewrite 接受一份每次執行時的設定，描述要尋找的模式與要套用的重寫，然後橫掃所有原始碼檔案。他說，AI 工具非常擅長產生 Open Rewrite 的 recipe——更省 Token、更準確、更快，而且可稽核。他引用 Netflix、Uber 等公司的演講，指出它們都得出相同結論，並點名由朋友創辦的新創 Bronto Source，把宣告式的重寫模式套用到 C++。

他認同 Kelsey Hightower 的「零 Token 架構」（zero token architecture）說法：用 AI 產生負責幹活的確定性工具，把推論留給工具涵蓋不到的缺口，以及判斷何時該呼叫工具。主持人補充一個平行案例：某位工程主管原本用昂貴又緩慢的 AI 程式碼審查，現在改成每當模型發現問題，就讓它產生一條 lint 規則，使這項檢查變得便宜、可重複且確定。Winters 把這連結到 Uber 在 AI 時代之前的 lint 文化：當時把架構規則寫成 lint 規則，例如某個 builder 不能繼承錯的類別。

「讓我們盡量只把痛苦的教訓學一次，把那些規則寫進某個確定性的地方，平等、適切且公平地套用，然後把程式碼審查中有趣的部分留給人。」

Readability 審查是一套規模達數萬名工程師的導師制度

Google 的每一項變更都需要兩個許可權位元：一個是有權動這些檔案的人，另一個是被認證能在該語言與該程式碼庫寫出道地程式碼的人。後者就是 readability。它最初是員工編號三號的那位，坐下來陪每位新人走過他們的第一個變更；當這種做法無法規模化，就訓練代理人來代替他。久而久之，這種一次性的審查感覺像在整新人，於是改成明確的導師制度：團隊簽核之後，從該語言的導師池中輪流指派一位導師，找出任何值得評論的實質問題。

Winters 在離開 Google 前（約三年前，也就是 2023 年左右）是這套計畫的總負責人。他稱這可能是科技業最大的教育計畫，任何時刻都有數萬人參與。他也承認有些人對此「超不爽」。他描述的程序是：先處理評論意見，接著因為自尊心而想讓評論變少，然後做到零評論，再來自己成為 readability 專家，最後換你給回饋、看到程式碼庫的其他角落——這是一條藏在水面下的微妙資訊交流管道。

AI 的價值對生產力指標是隱形的，因為它展現在更難的工作上

在 Adobe，Winters 負責開發者體驗，他稱這是對「生產力」這門生意「一種客氣的虛構」——虛構之處在於生產力可以被衡量。他和主持人都對麥肯錫式的衡量方式抱持懷疑，兩人一拍即合。他自己嘗試的解法借鏡經濟學：建立一個指數型指標，把許多指標（發布次數、測試覆蓋率、PR 數量）打包起來，再用資深工程師之間的兩兩比較來校準權重——一種取捨版的「我這樣算好看嗎」評分，精神上就是群眾智慧。他說 Adobe 正在做類似的事，而且比他最初的構想稍微聰明一點。

接著他說明為什麼這套方法抓不到 AI 的影響，援引他談「開發、部署、營運」的論文。他歸納出科技業的四種影響形式：

AI 的價值大多落在第四類，而這是指標看不見的，因為指標裡沒有任何一項會說「同樣大小的變更，價值已經變了」。三年前，說自己能在幾週內寫出一個 JPEG 解析器，會被當成瘋話。他引用一位資深工程師的報告：程式碼量增加 70%、事故增加 30%、功能數量不變——而無法得知的是，這些功能是不是更有價值。他對「十倍生產力」的說法存疑，指出他沒看過任何研究資料顯示 AI 之後的生產力提升超過 20–30%，並把這個落差歸因於 AI 讓人能做更難、更有價值的工作，而不是把同樣的工作做得更快。

主持人提供一個具體案例：某家中型公司的技術長原本在考慮裁員，直到一位工程師把某個授權元件的規格與測試框架餵給 AI，產出了更快、更好的實作。原本的供應商眼看分潤生意要飛了，便付錢要求維持封閉並重新授權——結果這家公司不必裁員就轉為現金流為正。

團隊與心理安全感仍決定結果，而裁員正悄悄對兩者課稅

Winters 認為，不管對 AI 抱持什麼信念，軟體工程終究是團隊運動。如果代理（agent）是未來，工程師就變成代理團隊的管理者，卻沒有受過訓練、也沒有任何支援架構；如果代理只是工具，人類團隊依然圍繞著它們運作。他引用 DORA 的研究，指出一個團隊能否達成目標，約有 30% 的變異可由文化題項的分數解釋——「比其他任何訊號都更有解釋力」。他援引 Fred Brooks 的《人月神話》，說「外科手術式團隊」是他最不喜歡的一章，因為它假設只有單一專案，而真實工作是反覆進行的賽局：把工作交給在監督下做得到的最資淺的人，成長才會發生。

Winters 同意兩者差異極大。談到裁員，他描述那種長達數週甚至數月的時期：每次一對一都以「你還好嗎」開場，大家在更新履歷，一對一時間變成心理諮商——這是一項他懷疑高層根本沒算到的隱形成本。他讚許 Adobe 近年避免大規模裁員，並提到該公司任期很長的執行長從 2008 年那波裁員得到的結論：裁員對士氣與生產力的傷害，超過數字上所節省的成本。

資工課程需要重建，評分方式應轉向提示與測試

Winters 曾任 ACM/IEEE/AI 大學資工課程要求指導委員會成員，負責管理軟體工程相關要求，也是其中唯一一位仍在第一線工作的工程師。他的結論是：大部分課程自 2000 年左右、甚至更早以來就沒有實質改變，教的「正是 1990 年代打造資料庫或作業系統所需的東西」。課程要求只會不斷累積——新主題加進來，既有主題的深度則削減一點點。他希望能有更多反覆演練以達到熟練，而不是橫跨上百萬個主題的冷知識；他說根本沒人需要自己實作鏈結串列，考量到記憶體延遲，那太慢了。

「資工系的註冊人數會暴跌，但軟體工程學程會崛起。」

他主張，AI 時代真正重要的技能是團隊合作、溝通、設計與規格制定，以及測試與驗證——「一整套軟體工程」。他提議評分要看過程，不只看成品：你用了哪些提示、提供了哪些測試、有沒有證據顯示你曾經卡關並從中學習。他指出，成品一直以來都只是努力的替代指標。他也希望開更多專題課程，一部分是因為只有一門專題課、所有人背景都相同時，會教出錯誤的團隊合作觀念；另一部分則是讓學生能在「給出批評又不惹人厭」這件事上被評分——而情緒分析就交給 AI 來做。

他勾勒的課程藍圖，第一學期不借助 AI，讓學生有能力讀程式碼、看懂控制流程。他會把 CS0 設計成不分主修與非主修的介面入門課——核取方塊與選項按鈕的差別、什麼時候該用按鈕、命令列旗標、位置引數——這樣即使只是 AI 生成、供個人使用的「垃圾」，也還有一套連貫的設計語彙。他舉自己住的大樓洗衣 App 用選單介面來當按鈕為反例。理論應該在學生為瞭解決手邊問題而需要它時才出現，而不是當成孤立的冷知識。

談到學生的現況，他轉述教授們的觀察：頂尖學生（B+ 以上）比以往更強，因為他們有一個無限耐心、隨傳隨到、偶爾會胡說八道的家教，而不是每週只開放幾小時的助教。最差的學生現在則能產出垃圾。中間那群則塌陷了——那些寧可去派對、先複製貼上一次、然後再貼一次的學生。一些還不錯的學校的教授擔心，B 以下的學生可能根本不懂程式碼怎麼運作。他直言「禁止使用 AI」這種反應是胡鬧，把它比作拒絕教組合語言以上的東西，並與學界人士在《Communications of the ACM》共同發表文章，主張若把防線守到 2040 年，學生將什麼都學不到。

他指出，一個資工學位所花的時數大約等於 15 個月的全職工作，還包含所有理論課程；相較之下，六個月的 bootcamp 則完全聚焦在立即可用的技能。他很羨慕加拿大的學校，尤其是 Waterloo，其建教合作（co-op）學程讓畢業生在畢業前就累積四段實習——大約一整年在公司裡的經驗。

給學生的建議，他的結語相當反主流：他大部分的成功來自於不做大家都在做的事。找到一件你真心感興趣的事，尤其是當它比同儕的興趣更古怪時，因為這能讓你在面試官面前說出一個新鮮的故事。他擔心 AI 輔助工程會降低純工程技能的溢價，而取而代之的是更深的領域理解——「不是『我是 C++ 工程師』，而是『我是嵌入式音訊領域的工程師』」——他認為這可能降低業界的流動性。他推薦的書是 Kat Hicks 的《Psychology of Software Teams》，特別點出書中「罐子裡的大腦」這個比喻，說他真想把它下載到每位主管的腦袋裡。

貫穿全場的主軸是把教訓只寫下來一次，而 AI 讓這件事更加迫切

這場訪談有三條線彼此呼應。Google 2006 年的強制測試政策、readability 制度，以及面對 AI 程式碼審查時以 lint 規則回應，本質上都是同一招：把昂貴的人類判斷轉換成確定性、一視同仁的規則，然後只把人的注意力花在真正需要的地方。Winters 把這套邏輯套用到重構（AST 轉換、Open Rewrite、Bronto Source）與教育（評分看提示與測試，不看成品）。尚未解決的張力在於衡量。如果 AI 的回報落在「改變遊戲規則」這一類——兩週寫出 JPEG 解析器、取代掉一個授權元件——那麼連 Winters 自己參與設計的指數型指標都會顯示持平，而底下的業務早已改變。第二個未解的問題是制度面的：改革會從資工系內部發生，還是透過獨立的軟體工程學程推動？Waterloo 式的建教合作模式又能否擴散得夠快、足以產生影響？Winters 自己的答案——沒有人握有標準答案——正是截至這次錄音為止，這個領域最誠實的寫照。