1 新智元編譯

本文梳理并介紹了Google軟件開發(fā)中的關鍵步驟。

作者介紹：作為軟件工程師，F(xiàn)ergus Henderson已在Google工作了10年以上。1979年他剛開始編程時還是一個孩子，之后逐漸走上了編程語言設計和實現(xiàn)的學術道路。他和他的博士生導師在墨爾本大學共同創(chuàng)立了一個研究小組，開發(fā)了編程語言水星。他是8個國際會議的計劃委員會成員，并發(fā)布了超過50萬行的開源代碼。他是Usenet新聞組comp.std.c 的前主席，并且是ISO C和C 委員會官方認可的“技術專家”。他擁有超過15年的商業(yè)類軟件的行業(yè)經驗。在Google，他是Blaze（一個正在Google上使用的構建工具）的原創(chuàng)開發(fā)人員之一，并致力于語音識別、操作和合成的服務器端軟件（在Siri之前?。Ｋ壳柏撠烥oogle的文字轉語音工程小組，但仍然撰寫和審查了大量的代碼。他寫的軟件安裝在十億多個設備上，每天被使用超過十億次。

以下是新智元對整份報告的重點翻譯。

目錄

摘要

關于作者

1.概述

2.軟件開發(fā)

2.1.源碼庫

2.2.編譯系統(tǒng)

2.3.代碼審查 2.4.測試

2.5.Bug追蹤

2.6.編程語言

2.7.調試和分析工具

2.8.工程發(fā)布（Release Engineering）

2.9.驗收

2.10.復盤

2.11.頻繁修改

3.項目管理

3.1.20%時間

3.2.目標和關鍵結果

3.3.項目驗收

3.4.團隊重組

4.人員管理

4.1.角色

4.2.設施

4.3.培訓

4.4.人員變動

4.5.表現(xiàn)評估與獎賞

5.結論

致謝

參考書目

1. 概述

Google已經是一個非常成功的公司。除了Google搜索和AdWords之外，Google還貢獻了許多其他杰出的產品，包括Google地圖、Google新聞、Google翻譯、Google語音識別、Chrome和Android。Google還大幅增強和擴展了許多通過購買小型公司（如YouTube）獲得的產品，并對各種開源項目做出了重大貢獻。同時Google還展示了一些尚未推出的驚人產品，例如無人駕駛汽車。

Google的成功有很多原因，包括開明的領導力、優(yōu)秀的人才、嚴苛的招聘標準，以及在迅速成長的市場中占據先機而積累的資金實力，而其中一個原因是Google形成了優(yōu)秀的軟件開發(fā)流程。這些源自地球上最有才華的軟件工程師智慧的做法隨著時間的推移而逐漸進化。我們希望和世界分享，其中也包括從錯誤中學到的教訓。

本文的目的是梳理并簡要介紹Google軟件開發(fā)的核心流程。然后，其他組織和個人可以將它們與自己的軟件開發(fā)流程進行比較，并考慮是否有借鑒價值。

許多作者（例如[9]，[10]，[11]）都撰有分析Google的成功和歷史的書籍或文章。 但大多數(shù)主要涉及商業(yè)、管理和文化; 只有一小部分作者（例如[1,2,3,4,5,6,7,13,14,16,21]）探索了軟件開發(fā)方面的事情，并且大多數(shù)只涉及一個方面; 尚且沒有一篇文章提供了Google整體軟件開發(fā)實踐的簡要概述，正如本文旨在做的那樣。

2. 軟件開發(fā)

2.1.源碼庫

Google的大多數(shù)代碼存儲在一個統(tǒng)一的源代碼存儲庫中，并且可供Google的所有軟件工程師訪問。有一些值得注意的例外，尤其是兩個大型開源項目Chrome和Android，它們使用單獨的開源存儲庫，另外還有一些高價值或牽涉到核心安全的代碼，其讀取訪問被鎖定得更緊。但大多數(shù)Google項目共享相同的存儲庫。截至2015年1月，這個86TB的存儲庫包含了10億個文件，包括超過900萬個源代碼文件（總共包含20億行源代碼），具有3500萬提交的歷史和每工作日4萬提交的變化率[18]。對存儲庫的寫訪問是被控制的：只有存儲庫的每個子樹的listed owner可以批準對該子樹的更改。但一般來說，任何工程師都可以訪問任何代碼段，可以檢查，構建，可以進行本地修改，可以測試，并可以發(fā)送更改供代碼的owner審核。如果所有者批準，就可以寫入那些變化。在企業(yè)文化上，我們鼓勵工程師修復他們看到的任何東西，并且去獲知如何修復，而無所謂項目的界限。這強化了工程師的能力，并導向了更高質量的基礎設施，以更好地滿足使用它的人的需求。

幾乎所有的軟件開發(fā)都發(fā)生在存儲庫的“頭”，而不是在分支上。這有助于及早識別集成問題，并最大限度地減少所需的合并工作量，同時也便于更快推出安全修復程序。

盡管不是每次都可行，一旦帶有傳遞依賴性的文件發(fā)生變化，系統(tǒng)會頻繁地自動運行測試。一般在幾分鐘內，這些系統(tǒng)會自動通知作者和審閱者測試失敗的任何更改。大多數(shù)團隊通過顯示標記甚至含有特定含義的光來表明他們的工程狀態(tài)（綠色表示構建成功，所有測試通過；紅色說明一些測試是失敗的；黑色則表明整體構建已經坍塌）這有助于將工程師的注意力集中在保持綠色狀態(tài)。大多數(shù)更大的團隊還有一個“構建警察”，通過與更改的作者合作，快速解決任何問題或消除令人不安的更改，從而確保測試持續(xù)通過 （這一警察角色通常由全部團隊成員或是經驗豐富的成員輪流擔任）。即使對于非常大的團隊，這種對于變化的關注也有助于保持整個構建的綠色狀態(tài)，使整個開發(fā)始終保持可行性。

代碼所有權。存儲庫的每個子樹都有一個文件，列出了該子樹“所有者”的用戶ID。子目錄繼承父目錄的所有者，但也可以選擇禁用。每個子樹的所有者控制對該子樹的寫訪問，如下面的代碼復查部分所述。每個子樹要求至少有兩個所有者，雖然通常有更多，特別是在不在同一地理位置的團隊。將整個團隊列在所有者文件中也是常見的。Google的任何人都可以對子樹進行更改，而不僅僅是所有者，但必須獲得所有者的批準。這確保每個更改都由了解整個軟件修改狀況的工程師進行審核。

有關Google源代碼存儲庫的更多信息，請參閱[17,18,21];關于另一家大公司如何應對同樣的挑戰(zhàn)，見[19]。

2.3 代碼審核（Code Review）

Google已經建立了完善的基于網絡的代碼審查工具，并與電子郵件集成，讓代碼作者發(fā)起審查，并允許審核者并排查看差異（使用漂亮的色彩編碼）并對其進行評論。當更改作者發(fā)起代碼審查時，系統(tǒng)會通過電子郵件通知審閱者，并提供指向該網頁查看工具頁面的更改鏈接。當審核人提交審核評論時，系統(tǒng)會發(fā)送電子郵件通知。此外，自動化工具可以發(fā)送通知，其中包含自動化測試的結果或靜態(tài)分析工具的結果。

對主源代碼存儲庫的所有更改必須至少由另一位工程師審核。 此外，如果更改人不是正在修改的文件的所有者，則至少有一個所有者必須審核并批準該更改。

2.4 測試（Testing）

我們強烈鼓勵并廣泛采用單位測試。生產中使用的所有代碼都需要進行單元測試，如果添加了源文件而沒有相應的測試，代碼審查工具將突出顯示。代碼審查人員通常要求對于添加新功能的任何更改，都應添加新測試以涵蓋新功能。模擬框架（Mocking frameworks，允許構建輕量級單元測試，甚至對于重量級庫的依賴的代碼）是相當普遍的。

集成測試和回歸測試也廣泛應用。

如上面“預提交檢查”中所述，測試可以作為代碼審查和提交過程的一部分自動執(zhí)行。

Google還提供用于衡量測試覆蓋率的自動化工具。結果也被集成為源代碼瀏覽中。

Google還有一個重點是在部署之前進行負載測試。團隊需要生成一個表格或圖，展示關鍵指標（特別是延遲和錯誤率）如何隨傳入請求而變化。

2.5. Bug 追蹤（Bug tracking）

Google使用一個叫 Buganizer 的錯誤跟蹤系統(tǒng)來跟蹤各種問題：錯誤、功能需求、客戶問題和流程（如發(fā)布或清理工作）。錯誤被分為層次化組件，每個組件有一個默認的負責人和默認電子郵件列表以便CC。當發(fā)送源更改以供審查時，系統(tǒng)會提示工程師將用問題的關聯(lián)編號提示工程師。

Google的團隊通常（但不是普遍的）定期掃描其組件中的開放問題，確定優(yōu)先級，并在適當時將其分配給特定工程師。一些團隊有一個特定的人負責錯誤分類，其他人在他們的常規(guī)團隊會議中進行錯誤分類。Google的許多小組都使用錯誤標簽來指示是否已對錯誤進行了分類，以及每個錯誤所針對的版本。

2.6.編程語言（Programming languages）

強烈鼓勵 Google 的軟件工程師使用以下四種官方認可的編程語言之一進行編程：C ，Java，Python 或 Go。盡可能少地使用的不同編程，這能減少了代碼重用和程序員協(xié)作的障礙。

每種語言都有相應的 Google 風格指南，以確保整個公司的代碼都具有類似的風格、布局、命名約定等。此外，還有一個公司范圍的可讀性培訓流程，由那些關心代碼可讀性的、經驗豐富的工程師來訓練其他工程師如何以特定語言編寫可讀的慣用代碼。他們檢查每一個連續(xù)修改或一系列變化，直到審查人確信作者知道如何用該語言編寫可讀代碼。每次以某種語言添加較重要的新代碼，都必須經過已通過該語言的“可讀性”培訓流程的人同意。

除了這四種語言之外，還有許多專用的領域專用語言用于特定目的（例如用于構建目標及其依賴性的構建語言）。

這些不同的編程語言之間的互操作主要使用“協(xié)議緩沖區(qū)”（Protocol Buffers.）。協(xié)議緩沖區(qū)是一種高效但可擴展的方式，用以編碼結構化數(shù)據。它包括一種用于結構化數(shù)據的特定領域語言，以及一個編譯器。編譯器可以接受這種描述，并生成 C ，Java，Python 的代碼，以構建、訪問、序列化和反序列化這些對象。Google 的 Protocol Buffers版本與Google的 RPC 庫集成，支持簡單的跨語言 RPC，對 RPC 框架自動處理的請求和響應進行序列化和反序列化。

過程的通用性是使開發(fā)變得容易的關鍵因素，即使具有巨大的代碼庫和多樣化的語言：有一組命令來執(zhí)行所有常見的軟件工程任務（例如check out, edit, build, test, review, commit, file bug report 等），并且無論什么項目或語言都可以用相同的命令。開發(fā)人員不需要因為他們用的代碼是不同項目的一部分或用不同的語言編寫的，而學習新的開發(fā)過程。

2.7.調試和分析工具 (Debugging and Profiling tools)

Google 服務器與庫相鏈接，這些庫提供了許多工具用于調試運行服務器。在服務器崩潰的情況下，信號處理程序將自動把堆棧跟蹤轉儲到日志文件，并且保存核心文件。如果崩潰是由于堆內存泄漏，將轉儲堆對象樣本子集的分配點的堆棧跟蹤。還有用于調試的網絡接口，其允許檢查傳入和傳出RPC（包括定時、錯誤率、速率限制等），改變命令行標志值（例如以增加特定模塊的日志冗長度），資源消耗， 性能分析等等。這些工具大大增加了整個調試過程的便利性，以至于很少需要啟動傳統(tǒng)的調試器（如gdb）。

2.8. 發(fā)布工程（Release engineering）

有幾個小組有專門的發(fā)布工程師，但對于 Google 的大多數(shù)小組，發(fā)布工程工作都是由通常的軟件工程師完成的。

大多數(shù)軟件發(fā)布比較頻繁; 通常的目標是每周或每兩周發(fā)布一次，有一些團隊甚至每天發(fā)布。這是通過自動化大多數(shù)正常發(fā)布工程任務實現(xiàn)的。經常發(fā)布有助于保持工程師的積極性（如果它在幾個月甚至幾年后才會發(fā)布，就很難激發(fā)），并通過更多的迭代增加總體速度，從在一定時間內獲得更多的反饋機會和更多的機會回應反饋。

最后，該發(fā)布可以推廣到所有數(shù)據中心中的所有服務器。對于非常高流量，高可靠性的服務，會在幾天的時間內逐步推出，以幫助減少因為新引入的錯誤沒有被發(fā)現(xiàn)而帶來的影響。

有關Google發(fā)布工程的更多信息，請參見SRE手冊[7]的第8章。也參見[15]。

2.9. 批準發(fā)布（Launch approval）

任何用戶可見的更改或重大設計更改，需要來自實施更改的核心工程團隊之外的許多人員的批準。在某些特殊的審批（通常需要詳細審查），要確保代碼符合法律要求，隱私要求，安全要求，可靠性要求（例如，具有自動監(jiān)控以檢測服務器中斷并自動通知相應的工程師），業(yè)務要求等等。

2.10. 事故分析（Post-mortems）

2.11. 頻繁重寫（Frequent rewrites）

大多數(shù)Google的軟件每隔幾年就要重寫。

這看起來非常昂貴。確實，它消耗了Google資源的很大一部分。然而，它也帶來了一些重要的好處，這是谷歌的敏捷性和長期成功的關鍵。在幾年的時間里，隨著軟件環(huán)境和周圍的其他技術發(fā)生變化，以及隨著技術或市場的變化影響用戶需求、愿望和期望，產品的需求通常會發(fā)生顯著變化。

幾年前的軟件是圍繞一套老的需求設計的，通常不是以當前需求的最佳方式設計的。此外，它通常積累了很多復雜性。重寫代碼消除了所有不必要的累積復雜性，這些復雜性只是解決了不再那么重要的需求。另外，重寫代碼可以向新的團隊成員傳遞知識和所有權感。這種所有權感對生產力至關重要：工程師自然會更努力地開發(fā)特性，并在“他們的”的代碼中解決問題。頻繁的重寫也鼓勵工程師在不同項目之間的移動，有助于鼓勵想法的雜交。頻繁的重寫也有助于確保代碼使用現(xiàn)代技術和方法編寫。

3.項目管理

3.1. 20% 的時間

工程師被允許花高達20％的時間在他們選擇的任何項目上工作，而無需他們的老板或任何其他人的批準。

3.2. 目標和關鍵結果 (Objectives and Key Results -OKRs)

Google的個人和團隊需要明確記錄他們的目標，并評估他們在實現(xiàn)這些目標方面取得的進展。

3.3. 項目批準（Project approval）

盡管有一個明確定義的啟動批準流程，但Google沒有明確定義的項目審批或取消流程。盡管我已經在Google工作了近10年，現(xiàn)在已經成為一名經理，我仍然不能完全理解如何做出這樣的決定。部分是因為在整個公司，這種方法是不統(tǒng)一的。每個級別的經理都對他們的團隊的項目負責，并且在他們認為合適的時候行使其自由裁量權。在某些情況下，這意味著這種決策是以自下而上的方式做出的，工程師可以在其團隊職能范圍內自由選擇做什么項目。在其他情況下，這種決策以更自上而下的方式做出的，管理人員或管理人員決定哪些項目將進行，哪個項目獲得額外的資源，哪個將被取消。

3.4. 公司重組（Corporate reorganizations）

少數(shù)情況下，執(zhí)行者決定取消一個大型項目，然后該項目的工程師可能需要在新的團隊上找到新的項目。

4.人員管理

略

5.結論

我們簡要介紹了大部分在Google使用的重要軟件工程實踐。當然，Google現(xiàn)在是一個龐大而多樣化的組織，它 的某些部分有不同的做法。但是這里描述的做法通常被大多數(shù)團隊遵循。

由于涉及這么多不同的軟件工程實踐，以及Google成功的許多其他方面的原因，因此很難給出任何定量或客觀的證據，將個人做法與結果改進聯(lián)系起來。然而，這些做法是經受了谷歌時間考驗的，成千上萬的優(yōu)秀軟件工程師的集體遵守它。

對于那些在其它組織被倡導的實踐，正好在本文中也被描述了，或許可以輔助說明“這對Google來說足夠好了”。

【尋找AI獨角獸】新智元聯(lián)手10大資本

啟動2017創(chuàng)業(yè)大賽

AI 創(chuàng)業(yè)大賽由新智元與10 家主流 AI 創(chuàng)投機構：藍馳創(chuàng)投、紅杉資本中國基金、高瓴智成人工智能基金、藍湖資本、藍象資本、IDG資本、高榕資本、中信建投證券、明勢資本、松禾遠望基金攜手發(fā)起，由新智元主辦，北京市中關村科技園區(qū)管理委員會、中關村科技園區(qū)海淀園管理委員會支持，是一場聚合了 AI 技術領袖和投資領袖的盛會。新智元向滿懷雄心的未來AI獨角獸提供強大的創(chuàng)投資源對接機會，頂級風投 TS 等你來拿。

http://form.mikecrm.com/gthejw

點擊文章下方閱讀原文，在線填寫報名申請報名表。該報名表為參與評選必填資料。

如有更多介紹資料（例如BP等），可發(fā)送至 xzy100@aiera.com.cn，郵件標題請注明公司名稱。如有任何咨詢問題，也歡迎向該郵箱發(fā)信聯(lián)系。