谷歌的內部開發工具是世界領先的，其針對大規模軟體開發的多方面痛點提供了解決方案。但幾乎所有工具均與谷歌獨有的內部生態系統緊密耦合，無法在其它環境中使用。本文介紹了如何在軟體開發中引入好的開發工具，提高自己和團隊成員的生產力，進而在大規模軟體開發中傳播有效的最佳實踐，為公司帶來工程化效率提升。
本文最初發表於about.sourcegraph.com（《An ex-Googler's guide to dev tools》），經原作者授權，由 InfoQ 翻譯並分享。
多年前我曾在谷歌短期任職。儘管此後歷經滄海桑田，但在谷歌期間接觸其內部開發工具的經歷，對我產生了長遠的影響。從很多方面看，谷歌的內部開發人員工具是世界最領先的。谷歌不僅在自身軟體系統的擴張上走在了前列，而且在大規模軟體的高效構建方法上也是領先的。谷歌針對代碼庫規模、代碼可發現性、組織知識的分享以及多服務部署等方面的問題提供了解決方案，達到了大多數企業尚未企及的高度。作為參考，推薦《谷歌軟體工程》（「Software Engineering at Google」）一書。
但從另一方面看，谷歌的內部工具是非常有局限的。事實上，幾乎所有此類工具均與谷歌獨有的內部生態系統緊密耦合。這意味著人們一旦離職，很不幸就無法在其它環境中使用這些工具。
儘管如此，這些才華橫溢的谷歌離職人員汲取了在世界領先技術組織工作中的經驗教訓，進而為其他許多組織注入了新的動力。但適應谷歌之外的編程開發環境並非易事，尤其是他們已經形成依賴的一些工具沒辦法在使用了。
這些年來，我從自身以及許多其他離職谷歌的人身上學到了不少。Sourcegraph 的許多早期客戶，就是因為離職谷歌后想念原公司的代碼搜索功能而找到了我們。通過與客戶的緊密合作，我們了解到他們迫切需要填補的空白，進而去構建 Sourcegraph 的功能來滿足他們的需求。谷歌前員工正在探索如何在當前組織中使用新開發工具的模式。這一工作的靈感源自於他們使用谷歌開發工具而具備的經驗。當然，一些探索是成功的，也有些折戟沉沙。
就此問題，我認為撰寫一份著眼於實操和實用的外部開發工具指南是非常有意義的。能將谷歌的內部開發工具生態系統直接克隆到新公司中，無疑是不少谷歌前員工的願望，但也應切忌好高騖遠。下面我就會談談我的看法，講一講前谷歌員工如何開始尋找讓他們和他們的新團隊儘可能高效工作的工具。
軟體開發的生命周期
對於剛離職谷歌並加入其他公司的人而言，可能一時難以適應大不如前的工作效率。儘管大家都覺得需要做出一些改進，但應從何入手呢？第一步需要認真考慮的，是如何從日常工作中發現真正的痛點所在。
無論對於谷歌內部還是其他組織來說，軟體開發的生命周期基本都是這個樣子：
列出需構建的特性，或是需要修正的軟體缺陷；通過大量閱讀代碼和文檔，以及與同事開展交流，建立對問題的認識，並給出一個大體適合現有系統的解決方案；著手編程工作。首先做出來能運行的東西，期間可能需要反覆地查看文檔及部分代碼。一旦代碼達到能運行的程度，這時不要急於交付。做代碼測試，修復缺陷並做進一步測試。進而重構代碼，生成整潔並便於接手者理解的代碼。將代碼推送到代碼庫生成分支，等待運行持續集成。期間的代碼可能實現了一些額外修復和小部分改進。提交供審核的代碼補丁，根據團隊成員給出的評論進行更改。這一過程可能需反覆數輪，直至代碼審核人員通過更改。歸併補丁，並做部署。監控已部署系統的運行情況，判定生產環境中是否存在問題。如果新打的補丁導致系統宕機，負責修復問題。這一過程中的每個階段，都需要在適用的開發工具輔助下開展。開發工具引導開發人員按章行事，主導著工作流程，控制著工作效率。
選定適合的工具，才能提高開發效率。我推薦一個 Github 代碼庫，地址為https://github.com/jhuangtw/xg2xg。其中列出了近乎所有的谷歌內部工具，以及具備對應功能的外部工具。列表非常詳盡，但是略為冗長。
開始階段：熟悉現有工具，不要引入新工具
我們在剛參與到一個項目中時，不要試圖對現狀做任何改變，只需蕭規曹隨。
做為一名團隊中的新人，不太可能有權或能影響整個團隊去迎合你個人對工具的喜好。此外，你也缺少對團隊做事方式和事情前因後果的了解。生搬硬套谷歌那一套，也許並不適用於新團隊。因此，首先是要領悟新團隊的工作方式和禁忌。
從易於改進之處著手
我認為首先可加以改進的，就是代碼搜索功能。鑑於我本身就是一家代碼搜索企業的聯合創始人，當然會這麼認為。同時，下面給出更具說服力的原因。如果讀者並不認同，大可跳過此節。
代碼搜索是谷歌離職員工通常缺失的日常工具之一。你可以自己嘗試各種代碼搜尋引擎，找出確實好用的選項再給別人推薦。也就是說你不需要得到領導的許可，也不用冒搭上自己人品的風險去說服他人嘗試你自己都沒用過的工具。大多數團隊尚未使用代碼搜索工具，因此不存在強迫別人改變現有習慣的問題。如果團隊已經在頻繁使用很好的代碼搜索工具，盡可跳過本節！新公司中可能有多個團隊，這時我們難免會處理超出個人合理能力範圍的代碼。即使在一家規模較小的公司工作，我們也有可能會通過依賴項獲取大量的開原始碼。在構建新功能時，或是追蹤某些嚴重錯誤的來源時，一些情況下需要深入研究所有這些代碼。
考慮到當前幾乎所有開發人員需面對的代碼規模，無疑低效的代碼搜索會嚴重阻礙開發的進度，導致步步維艱。
選擇代碼搜尋引擎時，需考慮如下因素：
查詢語言：正則表達式是標配。確保代碼搜索查詢語言具有很好的表達力，並易於使用。提供直觀的按詞搜索，並提供高級的模式匹配功能。擴展性：確保代碼搜尋引擎適合代碼庫當前的規模。如果代碼庫規模達數個GB，需考慮搜尋引擎是否支持三元詞索引技術。該技術適用於大規模代碼庫中的正則表達式匹配。代碼瀏覽：使用過Google Code Search的人都明白，搜索只完成了部分工作。查看搜索結果時，類似於在IDE開發環境中查看代碼一樣，需要支持跳轉到定義功能，並便於查找引用。如果代碼瀏覽功能不夠強大，那麼就需在編輯器和搜尋引擎之間頻繁切換。權限：如果企業強制了代碼庫的權限，需考慮代碼搜尋引擎對權限的適配性。整體代價：需考慮部署代碼搜尋引擎的代價，以及在線使用的整體維護代價。當前人們使用的主要代碼搜尋引擎包括：
OpenGrok：Oracle的產品，最具歷史，也一直在用。Hound：一款由Etsy工程人員創建並開源的代碼搜尋引擎。Livegrep: 由Stripe的Nelson Elhage創建的代碼搜尋引擎。當然，還有我們的Sourcegraph。良好的監控
監控是另一個需要考慮儘早改進的方面。工程師有時候必須去處理生產環境中出現的問題。但生產是與開發截然不同的，無法通過設置斷點或直接添加 printf 而在數秒內看到效果。從計算資源、開發人員時間、以及最糟糕的是給用戶和客戶帶來痛苦等多個方面看，生產環境中做更新的代價尤其高昂。
部署在過去的五到十年間發生了巨大的改變。微服務、Kubernetes、雲端遷移等技術，極大地改進了企業的軟體部署方式。很多企業採用了這些新方式和新技術，但尚未相應地更新監控架構來方便地調試新的生產環境。
好消息是現在已經有了一些很好的開源工具和企業，極大地改進了谷歌之外的監控和可觀察性現狀。
Prometheus：一款對標Borgmon的時序度量追蹤和可視化工具。為用戶提供儀錶盤顯示的應用追蹤度量，例如CPU使用、錯誤率、p90延遲等隨時間變化的情況。Grafana：一款對標Viceroy的儀錶盤工具。常用場景是連接到Prometheus，構建在單頁上顯示一系列關鍵指標的視圖，展示應用的整體健康情況。分布式追蹤是日益普及的多服務架構的必備工具，對此，Google Dapper居於領先地位。Lightstep是由Dapper的創建者之一Ben Sigelman推出的項目。分布式追蹤已是許多監控系統提供的特性，包括付費工具Honeycomb和Sentry等，以及Uber工程師推出的開源工具Jaeger等。考慮到監視必須集成到生產環境中，因此要比引入代碼搜索更具難度。引入監視需更改部署環境，這意味著要說服管控部署環境的團隊。監視還可能需要添加儀錶盤代碼，這涉及向所有儀錶盤代碼相關團隊提交補丁。但引入此類新工具並不需要任何人改變現有的習慣，從某種意義上說也並非不可為之。人們可以自由選擇是否使用新工具，這可避免在推行新工具時面對強烈的反對意見。
步步為營：代碼審查
引入代碼搜索和監控，並不會更改其他團隊人員現有的工作流程。但是改進代碼審核工具，則需大家配合。
對於具有谷歌工作經驗的人而言，很有可能不太適應谷歌之外的代碼審查方式。對於常用的代碼審核工具 GitHub Pull Request（PR），抱怨集中於以下幾點：
不夠直觀，有時無法查看自上一輪審核以來所做的更改。簡單路徑僅支持查看顯著差異；不支持積壓的更改請求（Stacked CR）；在同一頁中整體顯示所有文件的全部差異，難以追蹤已審核項；GitHub PR的審核實現方式毫無特點（unopinionated）。如果不額外添加第三方集成，審核過程松松垮垮。即便添加了第三方集成，依然缺乏強制的細粒度審核和籤出策略功能；儘管對部分語言提供對模糊「跳轉到定義」（jump-to-def）和「查找參考引用」(find-references）的有限支持，但遠未達到谷歌內部使用的Critique的水平。與 Critique 最接近的谷歌之外工具是 Gerrit。Gerrit 最早是 Rietveld 的一個分支，而 Rietveld 本身是谷歌最初代碼審核工具 Mondrian 的一個開源分支。因為工具線的傳承，二者看上去非常相似，設計用於創建谷歌支持的代碼審核方式。
Phabricator 是谷歌前員工喜歡替代 Github PR 的另一款工具。Phabricator 一開始是 Facebook 的代碼審核工具，隨後開源並對外發布。該工具由Phacility公司支持，為不想自己維護實例的用戶提供託管實例和服務支持。
由谷歌前員工 Piotr Kaminski 創建的 Reviewable 是另一款值得推薦的工具。不同於 Gerrit 和 Phabricator，Reviewable 僅用於雲端，提供類似於谷歌內部的代碼審核體驗。
要向團隊其他成員推薦 Gerrit、Phabricator或 Reviewable 的優點，重要的是指出團隊現有代碼審核工具在使用上的痛點。下面給出由 Github PR 類工具轉向類 Gerrit 工具所解決的部分痛點：
Gerrit提供明確的籤發（sign-off），有助於審核過程更加結構化。如果系統擴大團隊並在整個組織中強制更嚴格的審核策略，該特性非常好用；Gerrit便於審核大量差異，支持對逐個文件、上一輪審核後的更改以及積壓CR的審核，提供更快、更全面的審核。Gerrit、Phabricator 和 Reviewable 可實現類似谷歌內部的審核流程，但都尚未提供可對標的代碼智能功能。如果當前代碼審核工具中並不具備代碼智能，或是發現 GitHub PR 中缺失代碼智能，可嘗試Sourcegraph的瀏覽器擴展。它連接 Sourcegraph 實例，為代碼審核提供工具幫助、跳轉到定義和交叉引用，支持 GitHub PR、Phabricato 和 Bitbucket 伺服器，正實現對 Gerrit 的支持。
準備屠龍大招
軟體開發生命周期中最棘手的部分，通常是持續集成和構建系統。因為要理解構建，通常需要細緻理解整個代碼庫的每一部分。加快構建速度是所有人的願望，因此大家在構建代碼中越來越多地使用了一些技巧和優化措施，進而導致真正能確保當前進展中所做更改不會產生任何負面影響的人數屈指可數。
簡而言之，構建系統通常千頭萬緒（giant hairball）。在尊重底層開發人員提高開發效率的做法的同時，需慎重地逐一釐清。想要早發現苗頭早解決的話，Blaze 是最好的工具，谷歌甚至為 Blaze 的衍生產品 Bazel 開源提供幫助。但 Bazel 終究並非 Blaze，谷歌外部環境也並非適用谷歌的工具。舉一個例子，Blaze 中缺少在 Bazel 中打包提供的大規模分布式構建集群功能。
Bazel 也並非靈丹妙藥（silver bullet）。在 Bazel 首次發布時，Go 社區中的很多開源項目出於對標準 Go 構建工具的喜愛而紛紛轉向使用 Bazel。但在一年內，面對 Bazel 的複雜性和難以上手的缺陷（並且看上去使用 Bazel 的構建速度也較慢），很多項目又轉回 Go 社區。雖然當前 Bazel 對 Go 的支持已做了很大的改進，但在轉向使用它時，還是需要對所獲得的改進做出認真的評估。
開展嚴格的評估，需要手頭有一些好用的開發工具。尤其需要很好的代碼搜索工具，這樣才能切實深入研究代碼庫各個部分的構建腳本，理解它們的來龍去脈。還需要很好的代碼審查工具，因為更改構建系統是一項複雜的事情，需要多個不同工程團隊的支持。
一旦準備好屠龍，在 Bazel 之外還有其它一些從設計上支持大規模代碼庫中可擴展構建的工具。包括：
Facebook提供的Buck；Java領域廣為使用的Gradle；Pants，由一名谷歌前員工為Twitter和Foursquare開發；Please，也是由谷歌前員工新推出的構建工具，主要借鑑了Blaze。還有同是谷歌前員工 Yves Junqueira 推出的YourBase。YourBase 本身並非構建工具，而是一款持續集成工具，獨立於後臺使用的具體構建工具，在谷歌之外提供快速、可擴展的構建。
總結
谷歌獨樹一幟地提供了優先考慮開發人員經驗和開發人員工具，使得谷歌員工和前員工能受益於使用一流開發工具而獲得的一手經驗。這些工具極大地影響著他們的天賦和能力。
一旦離開谷歌，對這些經驗的利用就成為一種競爭優勢。人們可以將出色的新開發工具帶入新組織，提高自己和團隊成員的生產力。通過使用這些工具，在大規模軟體開發中傳播有效的最佳實踐，可為新公司帶來組織的有效工程化，這是谷歌的一項主要競爭優勢。
誠然，大規模軟體構建絕非易事。正如《人月神話》（The Mythical Man Month knows）一書所說，好的軟體並非通過僱傭更多開發人員就能實現。鑑於軟體是最終用戶生產率的倍增器，而開發工具是軟體構建人員生產率的倍增器，我們需要更好的工具。如果你認可新企業的理念，那麼就發揮做為谷歌前員工的獨到見解，為新企業帶來最好用的開發人員工具。
原文連結：
An ex-Googler's guide to dev tools
https://about.sourcegraph.com/blog/ex-googler-guide-dev-tools/
關注我並轉發此篇文章，私信我「領取資料」，即可免費獲得InfoQ價值4999元迷你書，點擊文末「了解更多」，即可移步InfoQ官網，獲取最新資訊～