矽谷技術大牛 Steve Yegge：退休後面試主管，他們居然讓我寫代碼

作者 | Steve Yegge

譯者 | Joe Chen、Yaohui Wang

策劃 | Tina

Steve Yegge 的職業生涯從 1992 年開始，曾先後任職于亞馬遜、谷歌、Grab 等企業。他因寫有關程式設計語言、生産力和軟體文化的技術部落格而受到廣泛關注，一些程式員——包括 Python Web Development with Django 的合著者 Paul Bissex——将 Steve 的部落格描述為“必讀”。

其中關于招聘和面試的一系列文章，因為辛辣調侃和特别的文風，尤其受到關注。

2011 年，在谷歌任職時，Steve 寫了一篇 3,700 字的評論，在文章中點評了亞馬遜和谷歌兩家的企業文化，并說道“亞馬遜每件事都做錯了，而谷歌每件事都做對了”。當時他本來想在 Google+ 上和谷歌的員工進行内部讨論，結果不小心把圈子設成了 Public，這篇吐槽文章就公開給了所有人，Steve 也是以在全球爆紅。

2018 年，在谷歌工作十三年後，Steve Yegge 決定離開谷歌。至于離職原因，他寫了一個更長的文章，表示“因為谷歌已經失去創新的能力了！”然後事情就再次失去控制了：

至今我依然不能完全肯定，當初那篇“我為何從谷歌離職”部落格文章怎麼就引起了那麼大的關注。基本上我隻是表達了“我就是一個喜歡頻繁換工作的普通人……”之類的觀點，差不多就這意思。可就這麼一篇文章被翻譯成了大概 80 種語言，甚至變得比 Natalie Portman 的兩性專欄更火，老實說，她的專欄内容可有趣多了。

......

最近，Steve Yegge 又換了一次工作，結束了短暫的退休生活，入職 Sourcegraph 擔任工程主管。

這次他在 Sourcegraph 官方部落格給大家分享了一些關于代碼智能平台的價值觀點，經 Steve 授權，我們将他的文章翻譯了出來分享給大家（有删節）。

編譯器的進化浪潮

每過十年左右，在編譯器領域都會發生一次大型技術變革。

上世紀九十年代的變革發生在 Borland，它們曾經在程式設計語言工具領域擁有傳奇式的創新，包括 Turbo C、Borland C++ 和 Turbo Pascal 等等。那一場創新浪潮一直持續到 21 世紀初并轉移到微軟；與此同時，Borland 的編譯器團隊卻面臨着被資本無情摧毀的困局，最後也難逃落寞。

微軟此後也在程式設計語言工具領域發起了一輪傳奇式的輝煌創新，包括今天我們所能看到的 CLR、C#/.NET、Visual Studio、VS Code 以及其它許多驚豔的産品。

你看，編譯器圈子為形形色色的開發者工具創造了代碼智能作為底層能力支撐，當這些編譯器極客們每過幾年一起聚在一塊時，就說明影響全世界開發者的變革即将發生。

到 21 世紀初，這場變革開始向谷歌轉移。

這正是我曾經工作的地方，和微軟在同一條街上的谷歌柯克蘭 (Kirkland) 辦公室。當微軟的開發者在谷歌工作的時候，他們會因為缺乏合适的工具而大發雷霆。盡管所有關于建構、開發和部署的要素都齊全，但是他們無法自如地探索和浏覽谷歌的代碼倉庫，讓人感覺一切都是對他們隐形的。

2008 年，我終于受夠了他們準确但老實說很傷人的抱怨。我決定建構一個強大的代碼智能平台，并取名為 Grok。這個平台可以從生産環境的編譯器中擷取代碼智能資訊并聚合為可查詢的知識圖譜，然後再以 API 的形式将這些智能資訊提供給其它工具。這是一種可以幫助所有工具讓你更輕松地浏覽代碼的方法。

Grok 本身并不是一個産品；它隻是一個為其它産品提供底層能力的引擎。

Grok 在谷歌獲得了持續性的成功，為編輯器、批處理自動化工具、代碼審查工作流、搜尋引擎、代碼浏覽器、IDE、指令行、代碼查詢引擎、Notebooks 以及其它許多臨時和定制工具提供代碼智能。

Google Code Search 當屬由 Grok 賦能過的最為強大的工具了，我猜你肯定已經從任何曾經在谷歌寫代碼的人那裡聽說過它了。

即使站在 2022 年的今天的角度來看，Grok 和代碼搜尋這對黃金組合所建立的事物也是前所未有的。代碼搜尋團隊在谷歌的可複用搜尋基礎架構上建構出了谷歌規模的代碼搜尋。即便沒有精确的代碼智能，代碼搜尋自身也是一款非常硬核的産品。

Grok 的作用當然是提供了世界一流的代碼智能，使得代碼搜尋可以提高産品的精确度、準确性乃至整體的可信度。

就開發者工具而言，信任就是一切。所有的程式設計語言工具和 IDE 已經在準确性和精确度上設定了非常高的标準。

谷歌代碼搜尋對使用者而言就像黑客帝國 (The Matrix) 一樣 ，它在谷歌内部調研中獲得了近乎完美的滿意度，幾乎每個離開谷歌的開發者都會想念它。

今天，谷歌的工程師可以比其它任何具有同等量級環境的開發團隊能更好地探索和了解數以億計的代碼庫。

你會理所當然的認為有人應該已經幫谷歌以外的我們實作了同等功能。

平庸工具拖累了開發者的生産力

長話短說，在谷歌之外已經出現過對代碼搜尋的嘗試，可以達到谷歌代碼搜尋被 Grok 賦能之前的不錯水準。但距離 Grok 的誕生已經 14 年過去了，依舊沒有人能夠在谷歌之外真正地完成這項工作。

實不相瞞，我也曾想過自己來擔起這份重任；遺憾的是，谷歌并不願為此花錢。至此，這個項目就進入了擱置期，而我又被雲計算、廣告業務、遊戲業務等等其它事情分去了精力。

我就不相信不可能沒有别人願意去做這件事！是吧？

其實在那以後已經有許多關于代碼智能方面的創新了，包括微軟、JetBrains 等等。可惜就是沒有人做出能夠和 Grok 與之媲美的東西。誠然，即使在谷歌這樣具備世界一流的排程基礎設施的加持、單一建構系統、少量程式設計語言和單個大倉的情況下也已經難如登天。

這世界上不會再有比谷歌更加同構的環境，卻還是讓 Grok 險些難産。何談在谷歌之外建立另一個 Grok？如何支援異構的企業級代碼部署環境？可以說是指數級的難度暴增，必須要海量的金錢、人力投入與資源協調才存在一絲可能。

結果就是我們的行業充斥着大量平庸的工具。大多數非 IDE 類型的工具都采用了啟發式（或者叫錯誤的）智能而不是編譯器級别的精準智能。這意味着開發者會在使用它們的過程中遇到數以千計的不爽之處，拖累了開發者的生産力。

有一點很清楚：我們唯一能夠見證代碼智能複興的時機是全世界的編譯器從業者能夠自由地聚集在一起。

這就很燒錢了。

代碼智能平台之路異常艱辛。整整十年，也許更久吧，我已經對其他人的嘗試感到絕望。不過我仍希望有一天我可以重拾舊夢。

Sourcegraph 面試挑戰：他們讓我寫點代碼

幾個月前，Sourcegraph 兩位創始人 Quinn 和 Beyang 聯系了我，看看是否适合擔任 Sourcegraph 工程團隊的負責人。

某些程度上講，Sourcegraph 頗受谷歌内部的代碼搜尋工具（Google Code Search）所啟發，Beyang 此前撰文寫過谷歌工作時的故事。從一個局外人視角，我一直很欣賞 Sourcegraph。他們一直以來都在嘗試做一些與我想法非常契合的事情。

Sourcegraph 主要關注在代碼搜尋部分（而我在谷歌時沒做這塊），而且很明顯，Sourcegraph 也一直想做更多的代碼智能（Code Intelligence）的工作，但代碼搜尋本身就是一個極具挑戰的工程難題。

去年（2021 年），某個創業公司的董事會成員問我，為什麼他們公司不能用 Sourcegraph 作為源碼分析工具？我深入調研了下，留意到 Sourcegraph 在使用 LSIF 索引方案。LSIF 在 Sourcegraph 的使用場景下湊合着能用；但 LSIF 本身是一種有損的格式，作為代碼智能平台的索引資料選型方案而言不太夠格。

如果接下來要我搞 LSIF，那我跟 Sourcegraph 緣分就到此為止了。但我決定還是繼續看下情況，因為 Sourcegraph 的營收和企業客戶付費在過去兩年着實開始爆發。

我跟他們的團隊成員聊了很多次，然後了解到更多他們的開放式公司文化。這是一個完全遠端、重度異步協同的公司，在疫情下簡直是初創公司的經典樣闆。我開始更多地了解他們的産品，這幾年來 Sourcegraph 的産品不斷在發展成熟。

這一切都非常有趣，但并沒有到比其他公司更值得我去選的份兒上。

但随後一個出乎意料的事情出現了：他們讓我寫點代碼。

這是過去 12 個月（我接觸了 20 多家公司）的上司力面試環節中，第一次有人讓我寫點代碼。他們希望我寫點代碼來修複個 Sourcegraph 的 Bug、或添加個功能，或者實作點其他什麼的。至于具體我寫什麼代碼，這都不重要。

是以我就去寫代碼了。我接受了這個挑戰，然後寫了點代碼。

親愛的朋友們，這就是為什麼我選擇加入了 Sourcegraph。

因為當我在做這個編碼作業時，我發現了兩件非常了不得的事情。首先，我發現在跨多個源碼倉庫的場景下，Sourcegraph 是浏覽并了解跨庫源碼的最佳工具。我當時希望盡快搞定面試編碼作業，這意味着我要盡快了解 Sourcegraph 自身的代碼。我手頭有各種各樣的工具：Emacs、指令行、GoLand、VS Code、GitHub，我可以任選它們來完成這個作業。然後我發現當我在嘗試梳理 Sourcegraph 前後端邏輯及其他代碼時，我用 Sourcegraph 來輔助我的時間比其他工具加起來還多 50%。我并沒有刻意為之，用 Sourcegraph 隻是恰好是最趁手的方式。

重返編譯器行業

我還發現了點别的：Sourcegraph 自己搞了個 Grok。這項工作是秘密進行的。準确來講是一個公開的秘密，畢竟 Sourcegraph 源碼都是開源可見的。但這年頭搜代碼也不容易，呵呵。

但這甚至對公司的許多其他人而言也是個秘密！或者至少，它的重要意義和改變世界的潛力被很多雜事掩蓋住了。這可以了解，真的。畢竟大家事兒都不少。就像我剛說的，Sourcegraph 眼下是個工業級的跨倉庫的代碼搜尋及浏覽工具，做到這點需要大量的投入。

當這一切都在進行時，Sourcegraph 後端工程師的一小撮群體，在難得的空閑時間裡，不知怎麼地将代碼智能從原型方案一路打磨到企業級可用（仿佛把魔戒從霍比特人村子千裡迢迢爬山涉水帶到了末日山），與此同時他們一邊還要應對代碼搜尋功能在不斷擴充的規模下的技術挑戰。

這群編譯器極客小分隊創造了 SCIP — 代碼智能協定（the Source Code Intelligence Protocol）。一個不大不小的玩意，你想要注意到它猶如大海撈針。

但在我與他們的技術面試的編碼馬拉松中，我注意到了 Sourcegraph 底層實作上發生的變化：這是一場革命！這些人正在悄無聲息地把 LSIF 替換成 SCIP，作為 Sourcegraph 新的底層架構。

Sourcegraph 的 SCIP 代表着 Grok 的王者歸來。它是基于啟發式搜尋的代碼智能實作，它的結構範式定義能為開發者效率實作上千倍的效能提升。它在 Sourcegraph 裡潛伏了幾個月了。

但在被實際使用之前，SCIP 總是被轉換回 LSIF 格式！這就是為什麼說 SCIP 是仿佛不存在一般。

是以，具有諷刺意味的是，他們打造的這個令人難以置信的代碼智能引擎，有着噴射機發動機的性能，卻被調成拖拉機檔位在工作。

但它就在那兒。在 SCIP 的基礎上進行擴充開發是相對容易的，因為你隻需讓索引工具收集更多資訊即可。Grok 和 SCIP 背後的設計理念是它們是可擴充的。你可以不斷地将來自社群、工業界和學術界的智能化資料進行模組化。一旦有資料開始産生，SCIP 的廣泛采用将勢不可擋。

Sourcegraph 正在建立一個代碼智能平台！想象一下我的震驚。了解我的人都知道，這對我來說是一個多麼不可思議的比對。這就是我未曾完成的事業！很高興地告訴大家，我作為工程團隊的負責人加入了 Sourcegraph，并将一起把 Sourcegraph 帶到新高度。我們将很快推出 Sourcegraph 代碼智能平台。

還記得 Borland 風頭正盛的時候嗎？那時候 80% 世界上最好的編譯器作者齊聚一堂推動了一場 IDE 工具的複興。然後它在微軟又一次發生了，并且規模大得多，僅僅在 Borland 歲月的 10-15 年之後。

如今，15 年又過去了，我們又要開始引領這場變革了。編譯器社群是一個非常小的圈子，大家彼此都很熟，我們将邀請所有的程式設計語言、靜态分析、建構系統、代碼托管和開發工具生态的社群夥伴們一起共建。SCIP 是一種互通的格式。它提供了一條讓我們彼此共識、且一同進步的路徑。它将帶來開發者工具的巨大變局。

原文連結：

https://about.sourcegraph.com/blog/introducing-steve-yegge

譯者介紹：

Joe Chen，Sourcegraph 軟體工程師。

Yaohui Wang, 資深 Bug 飼養專家，從事雲研發工具建設。