首頁>資訊 >
【全球獨家】離開 Chrome 十年,我都有著怎樣的思考 2022-12-13 18:00:34  來源:36氪

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


(資料圖片)

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

我做了什么?

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

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

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

我為什么加入 Chrome 項目?

我加入 Google,后來又加入 Chrome,因為我認為自己是自由軟件社區(qū)的一員。大學期間,我們?yōu)榱藫碛幸粋€能正常使用的瀏覽器而絞盡腦汁,甚至在 Linux 電腦旁邊再擺一臺 Windows 電腦,只因為當時的 Web 只能用 Windows 上才有的 IE 來瀏覽。正如 Brad 寫道:“我等了一年之久,Mozilla(改名 Firefox 之前的開源版本)才變得不那么難用了?!蔽矣浀?,我曾在宿舍里嘗試在 Linux 上構建 Mozilla,結果失敗了,當時我心里默默地說,終有一天我一定會解決這個問題。而 Chrome 給了我這個機會。

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

為什么 Google 決定開發(fā) Chrome?

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

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

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

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

為什么 Chrome 成功了?

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

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

我認為我們最初推出的產品才是真正的好軟件。我們所做的一些事情,比如頁面之間的操作系統(tǒng)級沙盒隔離,其他瀏覽器需要花費數(shù)年時間才能實現(xiàn)。

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

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

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

一些回憶、插曲

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

回想起來,真是有趣。

打磨

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

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

漫畫

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

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

版本控制

最初,Chrome 使用的是 Google 管理代碼的版本控制系統(tǒng) Perforce,后來我們換成了內部托管的 SVN,為的是發(fā)布時通過 Google 的公共 SVN 托管服務開源代碼。然而,真正到了發(fā)布的時候,我們卻發(fā)現(xiàn)這個服務無法擴展到為 Chrome 這樣大的項目提供服務,導致我們不得不自行研究怎樣發(fā)布代碼。

最終,我們租用了 Google 網(wǎng)絡之外的服務器,系統(tǒng)管理也只能靠自己。對于在創(chuàng)業(yè)公司工作的人來說,這些工作都很熟悉,但在 Google 就很不正常,因為 Google 的服務器管理是高度自定義的、集中管理的,而且我們清楚這些服務器的每一個細節(jié)。我記得我甚至無法使用 Google 的硬件,因為在我們的數(shù)據(jù)中心或類似的地方運行非 Google 的軟件是一個很陌生的想法。

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

與蘋果公司合作

Chrome 大約一半的代碼來自 WebKit 的分支,在 Chrome 發(fā)布后,我們將其重新整合到了蘋果的上游。這意味著,在我們發(fā)布 Chrome 后不久,我們修改的代碼都需要得到蘋果工程師的批準。

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

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

我的“采訪”

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

獎賞

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

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

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

Web 應用與原生應用

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

我記得當時編寫了一段原生 UI 代碼來自定義文本布局以及鏈接,盡管頁面的外觀和行為看起來就像基于 Web 的搜索結果頁面。這就是說,在當時使用 HTML 來實現(xiàn)應用程序是一個很糟糕的想法,即使對于我們?yōu)g覽器開發(fā)人員來說,即使對于應該表現(xiàn)得像網(wǎng)頁的 UI 也是如此。

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

Chrome 與 Web

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

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

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

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

ChromeOS

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

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

如今的 Chrome

Linux Chrome 基本可以正常工作了,但我并沒有意識到自己的工作已經完成了。當時我還開玩笑說:“Chrome 12 [一個舊版本] 才是最佳版本”。但當我意識到真正需要的是一個速度非??斓臑g覽器之后,就發(fā)現(xiàn)大多數(shù)后續(xù)工作都是在添亂。當然,我們還需要修復渲染崩潰或提高滾動性能等,但大多數(shù)添加功能的工作都會讓它變得更大、更慢。

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

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

Web 的命運

我對 Web 的發(fā)展有點悲觀。在 Chrome 之后,我在一個產品上工作了三年,其創(chuàng)建目標是試圖找出某種“拯救報紙”的方法。

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

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

人們似乎認為屏蔽廣告是瀏覽器的工作,但我的觀點是,如果企業(yè)的業(yè)務開始讓人感到反感,那么用戶唯一能做的就是停止使用其業(yè)務。不知何故,一旦涉及到技術,人們就會開始談論他們有權單方面要求重新談判交易。做一個不太恰當?shù)念惐龋骸拔矣憛掃@家商店一根香蕉賣 10 美元,所以我就付2美元,然后拿走香蕉?!?/p>

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

原文鏈接:https://neugierig.org/software/blog/2022/12/chrome.html

關鍵詞: 的工程師 版本控制 記得當時

相關閱讀:
熱點
圖片 圖片