鑽石舞台

很多年以前，我曾在谷歌短暫地工作了一段時間，沒錯，我也算是谷歌的一名前員工。雖然從谷歌離職後，周圍的很多事都發生了不小的變化，但即使只是短暫地接觸了谷歌的內部開發工具，也給我留下了深刻的印象。

谷歌內部的開發工具從很多方面來說，都可以算是世界上最領先的。谷歌不僅領頭開發了自身軟件系統，還優先探索如何大規模且高效地構建軟件。多年來，谷歌無論是在代碼庫規模，還是代碼可發現性、組織知識共享和多服務部署相關等問題的解決方案，都是很多其他公司無法企及的。

圖源Sourcegraph

然而，從另一個角度來看，谷歌的內部工具是非常局限的。幾乎所有的這些工具都和谷歌的內部生態系統緊密相連。所以，這意味着，如果從谷歌離開，你不能把這些工具也一起帶走。

從谷歌離職的員工，成為很多其他公司的人才，他們在加入其他公司時，也常會分享在谷歌吸取的經驗與教訓。但是對於他們來說，使用過最前沿的工具之後，想要適應谷歌以外的編程開發環境並不容易，尤其是在他們已經產生依賴的工具無法使用之後。

這些年，我從自身的經歷和其他從谷歌離職的人中學到了許多。

Sourcegraph早期的許多客戶，就是因為在離開谷歌后，想念谷歌的代碼搜索功能從而尋求我們的幫助。通過和他們密切合作，我們了解他們需要填補的空白，從而更好地構建Sourcegraph以滿足他們的需求。一些谷歌前員工在不斷探索將開發工具引入新公司的方法，結合他們在谷歌使用開發工具的經驗，創造了一些模式。有的探索成效顯著，有的則效果不佳。

所以，我認為寫一本注重實操的關於谷歌以外的開發工具指南是很有必要的。當然，很多谷歌前員工都希望能夠簡單地將谷歌內部生態克隆到新的公司，但這顯然行不通。

下面我將談談我的看法，關於谷歌前員工該從哪裡開始的建議，以及能夠使其團隊高效運作的一些普遍的方法。

谷歌內部工具的軟件開發生命周期：使用 or 不使用

剛從谷歌離職的員工在進入一家新公司後，可能有一種挫敗感，因效率大不如前。你想要做出一些改變，但是從哪裡開始呢？我認為，第一步應該是從日常工作中找出問題所在。

無論是在谷歌內部還是其他組織，軟件開發的生命周期都大同小異：

開發者列出要構建的功能或者需要修復的錯誤；

通過閱讀一堆代碼、設計文檔，和同事討論，了解問題所在，以及給出一個能基本適應現有系統的解決方案；

編寫代碼。首要目的是讓代碼先運行起來。期間可能需要反覆查看文檔，或者再讀幾遍代碼；

雖然代碼已經可以運行，但是還沒準備好交付。修復破壞了的測試，再做一些測試。重構代碼讓代碼更整潔，並且讓下一個接手的人更容易理解。將代碼推送至代碼庫生成分支，等待CI運行，期間開發者可能還會進行一些額外的修復和細微的改進；

提交修補程序進行審核。根據團隊的其他成員提出的意見進行修改。修改以後，在審核人員通過修改以前，這個過程可能還需要重複幾輪；

合併補丁，進行部署；

監控系統將檢查代碼是否存在生產問題。如果新的補丁造成中斷，就需要再進行修復。

在上述的每一個階段，通常會需要工具來輔助開發者。工具能夠塑造開發者的工作周期，並且對於生產力有巨大的影響。

為了提高生產力，開發者需要更好的工具。我推薦一個有用的GitHub存儲庫，其中包括谷歌內部幾乎所有工具以及谷歌之外的公司擁有的最接近的工具。（鏈接：https://github.com/jhuangtw/xg2xg）這個列表很全面，但是讓人眼花繚亂。那麼，應該從哪裡開始呢？

新工具放一邊，先熟悉現有工具

開始的第一個月，不要試圖改變，只需要聆聽+學習。

作為團隊的新成員，你可能沒有影響力或權限來更改團隊使用的工具。另外，你還缺乏一些對於團隊行事風格和原因的了解，以及使用現有工具的理由。簡單的複製粘貼谷歌的工具並不一定就適合你的新團隊。所以，你需要通過多聽多學來了解什麼是對團隊有用的，而什麼是團隊不需要的。

從易到難

代碼搜索是個好工具。作為代碼搜索公司的聯合創始人，我這麼說像是自賣自誇。但我這麼說是有理由的：

首先這是谷歌前員工最想念的工具之一；

你可以嘗試不同的代碼搜索引擎，找出好用的再推薦給其他人。這意味着你既不需要獲得批准，也不需要花費寶貴的時間來說服其他人使用你自己都沒用過的工具；

大多數團隊還沒有代碼搜索工具，所以其他人不會被迫改變現有的習慣。（如果你的團隊已經開始頻繁地使用出色的代碼搜索工具，可跳過本節。）

如果你的新公司有多個團隊，你可能會需要處理更多的代碼，並且一個人摸索。即使你在一家規模較小的公司，也有可能通過依賴項獲取大量的開源代碼。這些代碼是你在構建新功能或者跟蹤某些關鍵Bug來源時需要深入研究的。

考慮到現在開發者必須要處理的代碼的規模，如果缺乏代碼搜索，就會嚴重影響開發的進度。

在選擇代碼搜索引擎時，需要考慮以下幾點：

查詢語言：正則表達式只是入場券。代碼搜索引擎應該確保代碼搜索查詢語言具有很好的表現力，且易於使用的。文字搜索應該是直觀的，另外，更高級的模式匹配也是必要的；

擴展性：代碼搜索引擎要能夠適應代碼庫的規模。如果代碼庫超過幾千兆字節，那麼關鍵就要看代碼搜索引擎是否使用了三元組索引，因為這樣你才能在大型代碼庫中實現正則表達式匹配；

代碼瀏覽：使用過谷歌代碼搜索的人都知道的，搜索並非是其全部。用戶希望單擊後能跳轉到定義並查找引用，就像在IDE開發環境中查看代碼一樣簡單。但是，如果沒有出色的代碼瀏覽，用戶就需要經常在編輯器和代碼搜索引擎之間來回切換；

權限：如果公司強制實施代碼庫權限，那麼就需要考慮代碼搜索引擎是否符合這些權限；

總體成本：考慮代碼搜索引擎的價格和保持工具在線的維護開銷。

以下一些常見的代碼搜索引擎：

OpenGrok：一個非常老但生命力持久的代碼搜索引擎，現在由Oracle維護；

Hound：由Etsy的工程師創建和開源的代碼搜索引擎；

Livegrep：由Stripe的Nelson Elhage創建的代碼搜索引擎；

當然，還有我們的Sourcegraph。

獲得良好的監測

另一個需要儘早改進的方面是監測。工程師總有些時候必須要處理一些在生產環境中出現的問題。生產和開發截然不同——不能只是設置斷點或者添加printf就能馬上看到效果。在很多方面，對於生產環境進行更新會產生巨大的開銷，比如消耗計算資源，以及花費開發者大量的時間。

在過去的5-10年的時間裡，部署發生了巨變。微服務、Kubernetes，雲遷移等技術，極大地改變了公司部署軟件方式。許多公司已經採用了這些新方式和技術，但這些公司還沒有更新其監測基礎結構，以便在新的生產環境中輕鬆地進行調試。

幸運的是，近年來，優秀的新開源工具和公司湧現，它們極大地改善了谷歌之外的世界中的監測和可觀察性狀態。

Prometheus：一個時間序列指標跟蹤器和可視化工具，類似於Borgmon。它能夠讓用戶通過檢測應用程序來跟蹤隨CPU 利用率、錯誤率和p90延遲等指標的變化；

Grafana：一個類似於Viceroy的儀錶板工具。一種常見的方式是將Grafana與Prometheus連接起來，這樣用戶就可以構建指示整體應用程序運行狀況的關鍵指標的單頁視圖。

谷歌率先推出了分布式跟蹤，這是一種日益常見的多服務架構的重要工具。Dapper的創造者之一Ben Sigelman繼創建了Lightstep。分布式跟蹤現在是許多監測系統的一個功能，包括像Honeycomb和Sentry這樣的付費產品，以及像Uber工程師構建的Jaeger這樣的開源項目。

考慮到監測必須集成到生產環境中，所以引入監測比引入代碼搜索要更加棘手。通常會涉及到更改部署環境，而更改部署環境可能意味着要說服部署環境的團隊。監測可能還需要添加監測代碼，這需要向擁有所檢測代碼的各個團隊提交補丁。這看起來非常麻煩。但是，從某種意義上來說，引入新工具不需要任何人改變現有的習慣。讓開發者自由地使用新的工具，這似乎可以減少很多反對的聲音。

代碼審查

引入代碼搜索和監測都不需要團隊改變現有的工作流，但是如果代碼審查工具發生變化，那麼工作流就會改變。

如果你曾在谷歌工作了一段時間，那麼你可能會不適應在谷歌之外進行代碼審查的方式。GitHub Pull Requests是最常見的代碼審查工具，但Google前員工通常會對此有一些抱怨：

不夠直觀。有時無法查看自上一輪審核以來所做的更改。簡單路徑僅允許查看顯著的差異；

不支持堆疊的CR；

變更集中所有文件的全部差異顯示為一個巨大的頁面，並且很難跟蹤所查看的內容；

GitHub PR的審核機制非常不友好。如果不添加額外的第三方集成，審核流程可能看起來很鬆散，即使使用了第三方集成，它仍然可能缺乏執行更精確的審核和簽出策略的能力；

對於某些語言，模糊跳轉到定義或者查找引用存在限制，但是它遠比不上谷歌內部使用的Critique的水平。

在谷歌之外，和Critique最接近的是Gerrit。Gerrit最初是Rietveld的一個分支，而Rietveld本身就是谷歌原始代碼審查工具Mondrian的開源分支。因此，谷歌前員工應該對它有種親切感，因為它來自一系列工具，而這些工具是為了支持谷歌進行代碼審查的方式而創建的。

另一種穀歌前員工似乎更喜歡代碼審查工具是Phabricator。Phabricator最初是Facebook的內部代碼審查工具，隨後被開源並向外界發布。這款工具由Phacility公司提供託管實例和支持，以防用戶因不想為維護自己的實例而陷入麻煩。

還有一個值得研究的工具是Reviewable，它由前谷歌員工Piotr Kaminski創建。不同於Gerrit或Phabricator，Reviewable僅限雲的，但能夠提供最類似谷歌內部的代碼審查體驗。

向團隊的其他成員推銷Gerrit，Phabricator或Reviewable的前提是，現有的代碼審查工具讓團隊感覺很痛苦。

以下是一些通過從類似GitHub-Pull-Request的工具切換到類似Gerrit的工具來解決一些常見問題的方法：

通過明確的簽發，Gerrit能夠提供更具有結構化的審核流程，這對於希望審核策略更加嚴苛的組織來說是個助力；

Gerrit可以讓審閱大量的差異變得更加輕鬆，因為用戶可以逐個文件查看、查看自上一輪評審以來的更改以及堆疊CR，以便於更快、更徹底地進行審查。

最後一步

在軟件開發生命周期中，最棘手的部分通常是CI和構建系統。因為要理解構建，通常需要理解整個代碼庫的每一個部分。而不斷有人在嘗試各種方法來加速構建，於是有越來越多的黑客參與構建代碼，進行的優化也逐漸增多，直到人們發現不產生負面影響的更改屈指可數。

總之，構建系統就像是一團亂麻，所以在利用底層開發人員的成果之前，需要更加的謹慎。想要早發現早解決的話，Blaze是很好的選擇，谷歌甚至幫助開源了Blaze的衍生產品Bazel。但Bazel不是Blaze——首先，它缺乏一個免費的大規模分布式構建集群，畢竟谷歌以外的世界和谷歌不盡相同。

然而，Bazel也不是萬能的。Bazel首次發布時，Go社區中的許多開源項目紛紛轉向使用Bazel。後來，由於其使用的複雜性、難上手以及Bazel的構建速度實際上較慢等缺點，在一年之內，許多開源項目又將工具切換了回來。不過，自那以後，Bazel對Go的支持有了重大改進。如果你選擇再次使用它，還是需要對這些改進進行嚴格地評估。

進行這些嚴格的評估需要大量出色的開發工具，特別是需要出色的代碼搜索工具，這樣你才能深入研究代碼庫各個部分中的構建腳本，並且了解它們的來龍去脈。代碼審查工具也是非常重要的，因為更改構建系統將是一個複雜的過程，需要獲得許多不同工程團隊的批准。

在萬事俱備之前，你還需要知道，除了Bazel之外，還有許多構建工具，這些工具旨在實現大型代碼庫中的可擴展構建。包括以下幾種：

Buck：來自Facebook；

Gradle：Java界的寵兒；

Pants：由前谷歌前員工最初為Twitter和Foursquare創建；

Please：一個由谷歌前員工創建的新手構建工具；

還有YourBase，它不是一個構建工具，而是由谷歌前員工Yves Junqueira發起的CI服務，旨在為Google以外的世界帶來超快速和可擴展的構建，而與使用的底層構建工具無關。

總結

和大多數公司不同的是，谷歌優先考慮開發人員體驗和開發人員工具。無論是谷歌的員工還是已經離職的前員工，都擁有使用一流開發工具的第一手經驗，這些工具使其如虎添翼。

離開谷歌后，這些經驗就變成了競爭優勢，利用這些經驗將新的開發工具帶到新的組織中，讓自身以及團隊的生產力更上一層樓。

大規模構建軟件是非常困難的。讀過《人月神話》的人都知道，創建好的軟件不能單靠雇用更多的工程師。你需要更好的工具，正如軟件是最終用戶生產力的乘積一樣，開發工具也是軟件工程師生產力的乘積。如果你認可新公司的使命，那麼你的首要任務就是充分運用你在谷歌獲得的專業知識，並為其提供最好的開發者工具。