離開 Chrome 十年,我都有著怎樣的思考!

【CSDN 編者按】離開 Chrome 快 10 年了,這是作者的一篇回憶錄,從加入 Chrome 團隊從事 Linux 版本的 Chrome 開發,再到上線離開,期間都發生了哪些故事?為更貼近原文,本文譯者以第一人稱進行了編譯。

原文連結:https://neugierig.org/software/blog/2022/12/chrome.html

作者:Evan Martin 譯者:彎月

距離我在 Chrome 項目工作已過去約 10 年了。這期間發生的一些故事,因為年代久遠而變得模糊,我想趁著自己還沒有完全忘記之前將它們記錄下來。

我做了什麼?

我做了什麼?

2007 年~2012 年,我一直在從事 Chrome 開發,當時的我還未滿 30 歲。當然,我的生活中還有其他事情發生,例如結婚,但就我一生所做的事情而言,受到更廣泛關注的是 Chrome。如今,Chrome 擁有超過 25 億使用者。每當去咖啡館,看到鄰桌的人在使用「我開發的」軟體,就會感覺很奇妙。

我加入這個項目的目標是開發 Linux 版的 Chrome,也就是說,我首先要在 Windows 版的 Chrome 上工作幾年,之後再去領導 Linux 版 Chrome 團隊。加入一個全新的項目意味著每段程式碼都要親力親為,至今我仍然記得,我編寫的那段程式碼可以在使用者點選「星星」按鈕時讓它亮起。其實,背後不過是一個新的狀態布爾值以及一個額外的圖像資源。

那些年裡,我一直在更新一個關於 Chrome 的部落格(https://neugierig.org/software/chromium/notes/archive.html),裡面有很多技術細節,包括我的第一篇帖子,以及我離開時跟大家告別的帖子。

我為什麼加入 Chrome 項目?

我為什麼加入 Chrome 項目?

我加入 Google,後來又加入 Chrome,因為我認為自己是自由軟體社區的一員。大學期間,我們為了擁有一個能正常使用的瀏覽器而絞盡腦汁,甚至在 Linux 電腦旁邊再擺一臺 Windows 電腦,只因為當時的 Web 只能用 Windows 上才有的 IE 來瀏覽。正如 Brad 寫道:「我等了一年之久,Mozilla(改名 Firefox 之前的開源版本)才變得不那麼難用了。」我記得,我曾在宿舍裡嘗試在 Linux 上構建 Mozilla,結果失敗了,當時我心裡默默地說,終有一天我一定會解決這個問題。而 Chrome 給了我這個機會。

然而,很諷刺的是,最終事態卻滑向了相反的方向。我從痛苦的經歷中得到了教訓,明白了為什麼 Linux 上面向使用者的軟體(包括 Mozilla 和我的軟體)通常都不太理想的深層原因。同樣,我明白了免費軟體來自無私的付出和感恩的心,但最終都變成了企業的另一種武器。回想起來,這是一個古老的比喻,我試圖「從內部改變系統」,但最終被它吞噬了。

為什麼 Google 決定開發 Chrome?

如今回想起來,感覺 Chrome 的成功是很自然的事情,但在當時看來,Google 開發瀏覽器似乎是一件瘋狂的決定。(當時,即便是公司內部也反覆開玩笑說,這永遠不可能。)

透過歷史,我們可以清楚地看到這是一場篡奪網路控制權的陰謀,但當時這個事情非常簡單,至少像我這樣天真的小卒看來是這樣。Google 希望 Web 能取得成功,甚至派出了一個團隊協助 Firefox 開發。Google 希望能夠對 Firefox 發揮更大的影響力,Mozilla 對此很不滿,所以我們決定另闢蹊徑。這中間肯定有巨大的衝突,只不過我看不出來。據我所知,WebKit 分支也經歷了一段相似的歷史:他們希望 WebKit 提供蘋果沒有的功能,但最終發現過猶不及。

還有一個小插曲,有人說微軟對 Google 展開了惡意報復,而且還有人擔心微軟會藉助 IE 來建立反 Google 陣營。那時,每次 Windows 自動更新都會重置搜尋引擎設置,不過這是微軟一貫的作風。你甚至可以把當時 Valve 開發基於 Linux 的作業系統的嘗試解讀為對 Windows 應用商店的防範。我知道如今的微軟會重振雄風,但我仍然記得在 90 年代,經常有報道說這些大公司有多麼不堪。

第三,即便 Chrome 失敗,人們也希望它能夠為其他瀏覽器點一把火,我認為 Chrome 做到了,在版本 8 發佈之前,根本沒有人在意 JavaScript 基準測試。人們很容易忘記當時的網路有多糟糕,但 Chrome 的問世介於 IE7 和 IE8 之間的三年停頓期間。

為什麼 Chrome 成功了?

為什麼 Chrome 成功了?

Google 投入了大量資源(工程以及廣告)是一個重要因素。但 Google 投入大量資源,最終卻未能成功的例子也不罕見。

每當我對技術感到沮喪時,能讓我感到些許安慰的事情之一便是,X 公司那麼有錢,仍然無法做出讓客戶喜愛的產品 Y。有趣的是,在我寫這段的時候,正傳出了 Google 放棄克隆 Facebook 的訊息,似乎完美地證實了這一點。你也可以想想微軟和亞馬遜在手機領域的嘗試。

我認為我們最初推出的產品才是真正的好軟體。我們所做的一些事情,比如頁面之間的作業系統級沙盒隔離,其他瀏覽器需要花費數年時間才能實現。

其中很大一部分是因為當初我們之中有一些很偉大的工程師。想一想,有多少超級聰明的人才是你從未聽說過的,這些人就好像一種「暗物質」,永遠不會步入大眾視野。舉個例子,Antoine 是一位非常有才華的工程師,也是 ChromeOS 的功臣之一,但網際網路上幾乎聽不到他的任何訊息。

然而,我也見過很多優秀的工程師開發出並不怎麼成功的軟體。如果非要找出合作過的其他項目都缺乏的 Chrome 特有的優勢,我想大概是一致性:這款產品有一個明確的目的,每個人都知道並且都在朝著這個方向前進。我依稀記得一些設計細節,我們的設計師 Glen 為制定某個設計決策而權衡的所有因素。從那以後,我就堅信他非常清楚自己在做什麼。

也許這只能說明我們有很好的領導班子。很抱歉,無法在此給出更具體的成功秘訣。當然運氣也佔很大一部分。

一些回憶、插曲

一些回憶、插曲

最初,Chrome 只能在 Windows 上運行,而且自定義標題欄中的按鈕一看就是 Windows 風格。我一直催促 Glen 給我設計一些 Linux 風格的按鈕,我甚至搞了一出惡作劇,用他的頭像代替了關閉按鈕。

回想起來,真是有趣。

打磨

在即將發佈第一版 Chrome 時,我們選擇了一個發佈日期,並計劃抓緊最後的一段時間消滅所有 bug,來不及完成的功能只能統統放棄。例如,我曾付出了很大努力開發一項與 RSS 相關的功能,但發佈前暫時放棄了,之後再也沒有機會繼續。後來,項目出現了一些危機,我不記得具體情況了,但一些新聞報道給我們帶來了很大的負面影響,最終導致發佈推遲了一個月。

雖然我們多出了一個月的時間,卻無法添加真正的功能,我們只能利用這些時間來打磨產品,修復所有通常在發佈最後一刻沒有時間處理的細節問題。回想起來,這對產品來說是也許是一件好事。打磨產品其實非常重要,只不過一般我們更願意將精力投入到功能開發上。

漫畫

這則漫畫中竟然提到了我(https://www.google.com/googlebooks/chrome/small_02.html),作者是 Scott McCloud,他的漫畫真的很棒。

原本我們打算在發佈瀏覽器的時候同步發佈漫畫,作為發佈時的支持文件之一。但由於(發行?)出了問題,有人在我們發佈實際產品之前拿到了漫畫,因此有關漫畫和瀏覽器的評論分別出現在新聞中。現在回想起來,這也不錯,因為一些感興趣的使用者會被產品的創意所吸引,不會太過在意產品的視覺細節。

版本控制

最初,Chrome 使用的是 Google 管理程式碼的版本控制系統 Perforce,後來我們換成了內部託管的 SVN,為的是發佈時通過 Google 的公共 SVN 託管服務開源程式碼。然而,真正到了發佈的時候,我們卻發現這個服務無法擴展到為 Chrome 這樣大的項目提供服務,導致我們不得不自行研究怎樣發佈程式碼。

最終,我們租用了 Google 網路之外的伺服器,系統管理也只能靠自己。對於在創業公司工作的人來說,這些工作都很熟悉,但在 Google 就很不正常,因為 Google 的伺服器管理是高度自定義的、集中管理的,而且我們清楚這些伺服器的每一個細節。我記得我甚至無法使用 Google 的硬體,因為在我們的資料中心或類似的地方運行非 Google 的軟體是一個很陌生的想法。

與此同時,我對版本控制充滿了熱情,而且我非常肯定有一天 Git 會廣泛普及。因此,我編寫了一個與 Git 有關的工具用於管理 Chrome,以便將 Git 集成到我們基於 SVN 的程式碼審查流程中。回想起來,我認為這是我作為領導失策的地方。許多年後,Chrome 項目不得不全權依賴 Git,我們花費了幾年的時間才將 SVN 去掉。如果我多花點時間來推進,相信能為很多人節省很多時間。

與蘋果公司合作

與蘋果公司合作

Chrome 大約一半的程式碼來自 WebKit 的分支,在 Chrome 發佈後,我們將其重新整合到了蘋果的上游。這意味著,在我們發佈 Chrome 後不久,我們修改的程式碼都需要得到蘋果工程師的批准。

回想起來,我挺喜歡那段時間的工作,原因有兩個。第一,讓經驗豐富的工程師審查自己的程式碼是程式設計師迅速成長的最佳方式之一,而蘋果有著完全不同的工程師文化,他們沒有單元測試,沒有註釋,但他們也能構建出高質量的產品。第二,蘋果的批准流程相當於一道門檻,為了向 Chrome 添加功能,我們必須向蘋果證明添加這項功能非常有意義。

然而,我並沒有從事太多這方面的工作,我知道這項工作的壓力很大,部分原因是雙方的目標有很大不同。雖然個別工程師可能不同意這種看法,但我可以毫不誇張地說,從結構上講,蘋果關心的是製作一款能夠充分渲染網頁的瀏覽器,而真正的應用程序不屬於瀏覽器。此外,雙方也有很多技術方面的分歧。也許是我很幸運,也許是我忘記了,我只記得當時的程式碼審查是一段溫暖的回憶。

我的「採訪」

我的「採訪」

有一次,我度假回來收到了一封電子郵件,上面寫著:「一家 Linux 雜誌想採訪你,但你不在,所以我們幫你寫了回覆,你可以根據需要編輯。」回想起來,他們的這種行為很不恰當,我也不知道為什麼當時自己沒在意。如今,你仍然可以看到「我的」那篇回覆(https://www.linuxjournal.com/magazine/google-chrome-making-cross-platform-browser),文中包含很多讓人很無語的言論,比如「之所以構建了 Google Chrome 瀏覽器,是因為我們可以為使用者帶來真正的價值。」

獎賞

Google 有一個規定,在正常的薪酬之外,偶爾還會選出某些方面非常出色的項目獎勵大筆股票。Chrome 得過一次獎,也許那是最後一次,但我也不是很清楚,因為他們頒佈此獎項總是秘而不宣。

我提到這件事,是因為當時我們得知自己的項目獲獎了,而且每個人都知道自己能拿到多少獎金,但很快團隊中的一位資深人士就宣佈他即將離開公司。我記得當時自己特別驚訝,並問了他關於這件事,他的答案令我終生難忘,他說:「現在我知道自己留在這家公司能獲得的最高報酬,那麼就能與其他選擇做比較了。」

一般,公司的獎賞都是為了鼓勵員工努力為公司工作,然而這個故事顯然是一個反面教訓。與之類似,雖然我能理解為什麼一家公司為他們想獎勵的行為給予超額獎金,但為了留住人才,用獎賞來吊人胃口,這種行為讓我深感不齒。

Web 應用與原生應用

Web 應用與原生應用

如今,我們想當然地認為所有軟體都應該構建在 Web 之上。但我的經歷描繪了一段不同的時代:在推出 Chrome 時,我們有一個搜尋功能,瀏覽器會顯示一個選項卡,上面顯示了一些連結和文字片段,就像一個網路搜尋結果頁面。

我記得當時編寫了一段原生 UI 程式碼來自定義文字佈局以及連結,儘管頁面的外觀和行為看起來就像基於 Web 的搜尋結果頁面。這就是說,在當時使用 HTML 來實現應用程序是一個很糟糕的想法,即使對於我們瀏覽器開發人員來說,即使對於應該表現得像網頁的 UI 也是如此。

後來,我下了一番功夫公開了基於 HTML 的瀏覽器 UI,我記得自己當時還在團隊內大力倡導 Web 開發。從那以來,很多瀏覽器的 UI 都開始使用 HTML 來實現。當然,現如今在 Electron 的世界中,桌面應用程序不使用 HTML 實現的情況越來越罕見……

Chrome 與 Web

當 Chrome 還不成氣候的時候,各個網站都不會主動解決 Chrome 錯誤。我們必須去適應他們。當時我們為了解決 MediaWiki(維基百科)中的這個錯誤(https://bugs.webkit.org/show_bug.cgi?id=28350)花費了不少心思。這個 bug 從 2009 年開始就有了,一直存在了十年。

有一次,我們遇到了一個問題:瀏覽器應該支持多少次重定向?假設你嘗試載入 A,但A重定向到了B,B又重定向到了C,依此類推,直到某個時刻,你必須放棄,然後報告錯誤。有人選擇了一個看似合理的閾值,比如 10 次左右,超過這個數量 Chrome 就會放棄。然而,Darin 曾經從事過 Firefox 開發,他說:「不,至少應該支持30次,否則紐約時報就會出問題——經驗之談。」

後來,Chrome 越來越強大,很多網站開始測試,確保他們能夠處理 Chrome 的錯誤。再到後來,Chrome 足夠強大,成為了制定規則的人。但我感到很焦慮,因為我們無從判斷這些決定沒問題。

網路的發展速度很快,但大多數時候我們都依賴於少數幾個決策制定者的「善意」。標準流程的失敗導致了 HTML 5 的割裂,這正說明了隨意讓一個機構定義標準也行不通。我認為這是一個需要平衡的問題,沒有簡單的答案。

ChromeOS

曾有人問我是否願意加入 ChromeOS 項目,我心愛的Linux Chrome 也是其中的一個重要部分——我對此非常懷疑。

但 ChromeOS 的結果讓我感到驚訝,尤其是在安全和更新方面。他們通過某種方式讓合適的人在合適的地方做出了卓越的產品。

如今的 Chrome

如今的 Chrome

Linux Chrome 基本可以正常工作了,但我並沒有意識到自己的工作已經完成了。當時我還開玩笑說:「Chrome 12 [一箇舊版本] 才是最佳版本」。但當我意識到真正需要的是一個速度非常快的瀏覽器之後,就發現大多數後續工作都是在添亂。當然,我們還需要修復渲染崩潰或提高滾動性能等,但大多數添加功能的工作都會讓它變得更大、更慢。

從長遠來看,我很榮幸自己投入了很多精力在這款產品上,我為自己當時所做的工作感到自豪,但這款產品本身是一種我無法控制的生物,從很久以前開始它前進的方向就與我的意見相左。Google 對隱私的處理讓我感到特別失望,舊版的 Google 更值得令人尊敬。

反思我們花了多少時間來製作最簡單的雛形也很有趣,最初 Chrome 沒有「主頁」按鈕,我記得有一段時間裡,我們一直在爭論是否將它作為一個選項添加進來,然而如今的瀏覽器裝滿了按鈕和設置。

Web 的命運

Web 的命運

我對 Web 的發展有點悲觀。在 Chrome 之後,我在一個產品上工作了三年,其創建目標是試圖找出某種「拯救報紙」的方法。

每個人都討厭廣告,但沒有人針對新聞業如何獲得資金提出合理的計劃,我認為那個項目的嘗試不會成功。在這類的討論中,難免有人會說一些沒有任何幫助的話,比如「如果報紙有合理的支付系統,我會花錢購買」,但紙上談兵和實際爭取到資金完全是兩碼事。

如今的 Web 感覺就像一個底部圍繞著廣告的螺旋。雖然我們可以利用 Web 技術製作一些非常漂亮的東西,例如 Figma,但是製作對使用者有敵意的垃圾也更容易,而我們獲得的大多數產品也跟垃圾差不多。

人們似乎認為遮蔽廣告是瀏覽器的工作,但我的觀點是,如果企業的業務開始讓人感到反感,那麼使用者唯一能做的就是停止使用其業務。不知何故,一旦涉及到技術,人們就會開始談論他們有權單方面要求重新談判交易。做一個不太恰當的類比:「我討厭這家商店一根香蕉賣 10 美元,所以我就付2美元,然後拿走香蕉。」

與此同時,唯一真正的非 Web 平臺都是由科技巨頭(蘋果/Google/微軟)運營的,他們會毫不手軟地打擊競爭對手。也許,我不過是對技術整體的發展方向感到悲觀。

相關文章

吳峰光殺進 Linux 核心

吳峰光殺進 Linux 核心

【編者按】吳峰光,Linux 核心守護者,學生時代被同學戲稱為「老神仙」,兩耳不聞窗外事,一心只搞 Linux。吳峰光的 Linux 核心之...

最強 AI ChatGPT 真要取代程式設計師?

最強 AI ChatGPT 真要取代程式設計師?

【CSDN 編者按】ChatGPT 一出,「程式設計師要失業了」、「程式設計師要下崗了」之聲不絕於耳,引得程式設計師們不由得一陣驚慌,最強 ...