獨家揭秘Google軟件工程最佳實踐

本文梳理并總結了 Google 軟件開發中的關鍵工程實踐，并揭示了其成功之道，值得業界各路人馬參考借鑒。

1.簡介

Google已經是一個非常成功的公司了。 除了Google搜索和AdWords的成功之外，Google還提供了許多其它杰出的產品，包括Google地圖、Google新聞、Google翻 譯、Google語音識別、Chrome和Android 等。Google通過收購小型公司（如油Tube）獲得的產品大幅增強和擴展了大量產品，并對各種開源項目做出了重大貢獻。 Google已經展示了一些尚未推出的激動人心的產品，例如自駕車。

Google的成功有著很多原因，包括開明的領導力、偉大的人才、超高的招聘標準，以及在迅速成長的市場中成功利用早期領先優勢的財務實力。但其中一個原因是 Google開發了優秀的軟件工程實踐 ，幫助它取得成功。這些做法隨著時間的流逝，根據地球上眾多最有才華的軟件工程師積累和凝練的智慧而演變。我們愿與世界分享我們的實踐的經驗，包括分享我們從錯誤中學到的一些教訓。

本文的目的是梳理并簡要介紹Google的關鍵軟件工程實踐。然后，其他組織和個人可以將它們與自己的軟件工程實踐進行比較和對比，并考慮是否自己應用一些實踐經驗。

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

2.軟件開發

2.1源代碼倉庫

Google的大多數代碼存儲在一個統一的源代碼存儲庫中，并且可供 Google 所有軟件工程師訪問。請注意有些例外，特別是兩個大型開源項目 Chrome 和Android，它們使用單獨的開源倉庫，另外一些高價值或安全關鍵的代碼，其讀取訪問被鎖定得更緊，管得更嚴。但大多數 Google 項目共享相同的存儲庫。

截 至2015年1月，這個86 TB的存儲庫包含了10億個文件，包括900多萬個源代碼文件，包含總共20億行源代碼，歷史記錄3500萬次提交，每個工作日更改4萬次提交[18]。 控制對存儲庫的寫訪問：只有存儲庫的每個子樹的列出的所有者都可以批準對該子樹的更改。但一般來說，任何工程師都可以訪問任何代碼片段，可以檢出并構建 它，可以進行本地修改，可以測試它們，并可以發送更改供代碼所有者審核，如果所有者批準，可以簽入（提交）那些變化。在企業文化上，Google鼓勵工程 師修復他們看到的任何東西，并且知道如何修復它們，不管項目的邊界如何。這增強了工程師能力，帶來了更高質量的基礎設施，更好地滿足那些使用它的人們的需 求。

幾乎所有的開發都發生在倉庫的“頭”，而不是在分支上。這有助于及早識別集成問題，并最大限度地減少所需的合并工作量。它還使得更容易和更快地推出安全修復程序。

盡 管這并不總是可行，在測試的傳遞依賴性中的任何文件每次更改之后，自動化系統總是頻繁運行測試。通常在幾分鐘內，這些系統自動通知作者和審閱者任何導致測 試失敗的更改。大多數團隊通過安裝突出的顯示屏，甚至安裝帶有顏色編碼的燈（綠色為成功構建和所有測試通過，紅色為一些測試失敗，黑色為構建失敗）使他們 構建的當前狀態非常顯眼。這有助于將工程師的注意力集中在保持構建為綠色狀態。大多數更大的團隊還有一個“構建警察”，通過與錯誤的更改的作者合作，以快 速解決任何問題或回滾令人不安的更改，負責確保持續通過測試。（構建警察角色通常在團隊成員之間或在其經驗豐富的成員之間輪流充當）。這種關注保持構建綠 色狀態，使開發變得實用，即使對于非常大的團隊仍然如此。

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

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

2.2構建系統

Google使用一個稱為Blaze的分布式構建系統，該平臺負責編譯和鏈接軟件以及運行測試。它提供了用于構建和測試在整個存儲庫中工作的軟件的標準命令。這些標準命令和高度優化的實現意味著， 對于任何Google工程師來說，構建和測試存儲庫中的任何軟件通常非常簡單和快捷 。這種一致性是一個關鍵的推動因素，有助于使工程師能夠跨項目邊界進行更改。

程序員編寫“BUILD”文件，Blaze用它來確定如何構建他們的軟件。使用相當高級別的 聲明式構建規范 聲 明庫，程序和測試等構建實體，為每個實體指定其名稱，源文件以及它所依賴的庫或其他構建實體。這些構建規范包括稱為“構建規則”的聲明，每個都指定高級概 念，如“這里是一個C ++庫，這些源文件取決于這些其他庫”，并且由構建系統將每個構建規則映射到一組構建步驟，例如編譯每個源文件的步驟和用于鏈接的步驟，以及用于確定使用 哪個編譯器和編譯標志。

在某些情況 下，特別是Go程序，可以自動生成（和更新）構建文件，因為BUILD文件中的依賴性信息是（通常）源文件中的依賴性信息的抽象。但是，它們仍然檢入到存 儲庫里。這確保構建系統可以通過僅分析構建文件而不是源文件來快速確定依賴性，并且避免構建系統和用于所支持的許多不同編程語言的編譯器或分析工具之間的 過度耦合。

構建系統的實現使用Google的分布式計算基礎設施。每個構建的工作通常 分布在數百甚至數千個機器上 。這使得可以快速構建極大的程序或并行運行數千個測試。

各個構建步驟必須是“氣密的”：它們僅取決于他們所聲明的輸入。強制所有依賴關系正確聲明是分發構建的結果：只有聲明的輸入被發送到運行構建步驟的機器。因此，構建系統可以依賴于知道真正的依賴性。即使編譯系統調用的編譯器也被視為輸入。

單獨構建步驟是確定性的。 因此，構建系統可以緩存構建結果。軟件工程師可以將它們的工作空間同步到舊的更改號碼，并且可以重新構建，最終將獲得完全相同的二進制文件。此外，該高速 緩存可以在不同用戶之間安全地共享。（為了正常工作，我們必須消除由構建調用的工具中的不確定性，例如通過清除生成的輸出文件中的時間戳）。

構建系統是可靠的。 構建系統跟蹤對構建規則本身的更改的依賴關系，并且如果生成目標的操作發生變化，即使該操作的輸入沒有改變，也知道重新構建目標，例如當只更改編譯器選項 時也是如此。它還正確處理中斷構建部分的方式，或在構建期間修改源文件：在這種情況下，您只需要重新運行build命令。沒有任何需要運行相當于 “make clean”。

構建結果被緩存在“云中”。這包括中間結果。如果另一個構建請求需要相同的結果，即使請求來自不同的用戶，構建系統將自動重用它們而不是重新構建。

增量重新構建速度快。構建系統保持駐留在內存中，因此對于重新構建，它可以增量地分析自上次構建以來更改的文件。

預提交檢查。 Google提供了在啟動代碼審查和/或準備向存儲庫提交更改時自動運行一系列測試的工具。存儲庫的每個子樹可以包含配置文件，該配置文件確定要運行哪些 測試，以及是在代碼審查時還是在提交之前立即運行它們，還是兩種情況下都運行測試。測試可以是同步的，即在發送更改以進行審查之前和/或在將更改提交到存 儲庫之前運行（有利于快速運行測試）;或者是異步的，結果通過電子郵件發送到審查討論線程。 [審查線程是進行代碼審查的電子郵件線程；該線程中的所有信息也顯示在基于Web的代碼審查工具中。]

2.3代碼審查

Google已經建立了完善的基于Web的代碼審查工具

， 并與電子郵件集成，允許作者提出審查，并允許審查者查看并排顯示差異（使用漂亮的顏色編碼）并對其進行評論。當更改作者發起代碼審查時，系統會通過電子郵 件通知審查者，并提供指向該網頁更改工具網頁的鏈接。當審查人提交審查評論時，系統會發送電子郵件通知。此外，自動化工具可以發送通知，包含例如自動化測 試的結果或靜態分析工具的結果。

對主源代碼存儲庫的所有更改必須至少由另一位工程師審查。 此外，如果更改的作者不是正在修改的文件的所有者，則至少有一個所有者必須審查并批準該更改請求。在特殊情況下，子樹的所有者可以在審查之前簽入（提交） 該子樹的緊急更改，但審查者仍然必須命名，并且更改作者和審查者將自動對其進行標記，直到更改生效經過審查和批準。在這種情況下，為解決審查意見所需的任 何修改必須單獨進行，因為原始更改已經提交。

Google 有一些工具可以通過查看正在修改的代碼的所有權和作者身份，最近審查人的歷史記錄以及每個潛在審查者的待審代碼數量，自動為特定更改提示審查人。變更所影 響的每個子樹至少一個所有者必須審查并批準該更改請求。但除此之外，作者可以自由選擇審查者，因為他們認為合適做審查。

代 碼審查的一個潛在問題是，如果審查者的響應太慢，或者過于不愿意批準更改，這可能會減慢開發速度。代碼作者選擇他們的審查者的事實有助于避免這樣的問題， 允許工程師避免可能對他們的代碼過于占有的審查者，或者發送評論以對較不透徹的評論者進行簡單的改變，并且將更復雜的改變發送給更有經驗的審查者或幾個審 查者。

每個項目的代碼審查討論自動復制到項目維護者指定的郵件列表中。任何人都可以對任何更改發表評論，無論他們是否被指名為該更改的審查人，無論是在更改之前還是之后。如果發現錯誤，通常追蹤引入它的更改，并對原始代碼審查線程發表評論，指出錯誤，以便原始作者和審查者知道情況。

還可以向幾個審查者發送代碼審查，然后一旦其中一個審查者批準（當然作者或第一個作出回應的審查者是所有者，則在其他審查者評論之前）提交改變，隨后的審查意見將在后續更改中處理。這樣可以減少評論的周轉時間。

除了存儲庫的主要部分， 存儲庫中也存在一個“實驗性”部分，它不強制執行正常的代碼審查要求 。 但是，在生產環境中運行的代碼必須位于存儲庫的主要部分，并且非常強烈地鼓勵工程師在存儲庫的主要部分開發代碼，而不是開發實驗性代碼，然后將其移動到主 要部分，當代碼是開發時而不是之后，因為代碼審查是最有效的。實際上，工程師經常要求代碼審查，即使是實驗代碼也是如此。

Google鼓勵工程師堅持每個單獨的更改較小的原則， 較大的更改最好分成一系列較小的更改，審查者可以輕松地一次查看完畢。這也使作者對每篇作品的審查期間提出的主要變化作出反應更容易；非常大的更改通常太 僵硬，并阻礙審查者對更改提出建議。鼓勵保持更改較小原則的一種方式是代碼審查工具標記每個代碼審查與更改的大小描述，添加/刪除30-99行的更改標記 為“中型”和300行以上的更改標記具有越來越不相關的標簽，例如““large”（300-999），“freakinhuge” （1000-1999）等（但是，以一個典型的Google式的自娛自樂的方式，每年花上幾天用有趣的替代品替換這些熟悉的描述，正如像海盜行俠仗義似談 資。）

2.4測試

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

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

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

Google還提供用于測量測試覆蓋率的自動化工具。結果也作為源代碼瀏覽器中的可選層被整合進來。

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

2.5 Bug跟蹤

Google 使用一個名為Buganizer的錯誤跟蹤系統來跟蹤問題：bug，功能請求，客戶問題和流程（如發布或清理工作）。錯誤被分為層次化組件，每個組件可以 有一個默認的受托人和默認電子郵件列表到抄送列表（CC）。當發送源代碼更改以供審查時，系統會提示工程師將更改與特定的問題編號相關聯。

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

2.6編程語言

Google強烈鼓勵軟件工程師使用以下四種官方認可的編程語言之一進行編程： C ++，Java，Python或Go 。最小化所使用的不同編程語言的數量掃平了代碼重用和程序員協作的障礙。

另外，每種語言都有 Google 風格指南 ，以確保整個公司的代碼都具有類似的風格、布局、命名約定等。此外，還有一個公司范圍的 可讀性 培 訓流程，由經驗豐富的工程師關心代碼可讀性通過檢查一個實質性的變化或一系列變化，直到審查人確信作者知道如何用該語言編寫可讀代碼為止，來訓練其他工程 師如何以特定語言編寫可讀的慣用代碼。每個以特定語言添加不重要的新代碼的更改都必須由已通過該語言的“可讀性”培訓流程的人批準。

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

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

過程的通用性是 使開發變得容易的關鍵，即使具有巨大的代碼庫和多樣化的語言也是如此：無論什么項目或語言，有一組命令來執行所有常見的軟件工程任務（例如簽出、編輯、構 建、測試、審查、提交、文件錯誤報告等）和相同的命令可以使用。開發人員不需要學習新的開發過程，因為他們正在編輯的代碼恰好是不同項目的一部分或用不同 的語言編寫的。

2.7調試和剖析工具

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

2.8發布工程

在Google，只有幾個團隊有專門的發布工程師，但對于的大多數團隊，發布工程工作都是由一般軟件工程師完成的。

大多數軟件 頻繁發布 ； 每周或每兩周發布是比較常見的目標，一些團隊甚至每天發布。這是通過自動化大多數正常發布工程任務實現的。頻繁發布有助于保持工程師的積極性（如果在幾個 月甚至幾年后才發布，那么就很難激發工程師的積極性），并通過允許更多的迭代增加總體速度，從而獲得更多的反饋機會和更多在給定時間內響應反饋的機會。

通 常通過同步到最新的“綠色”構建（即，所有自動測試通過的最后一個改變）的更改號并進行發布分支，在新的工作區中開始發布。發布工程師可以選擇額外的更改 以“cherry-picked”，即從主分支合并到發布分支上。然后軟件將從頭重新構建并運行測試。如果存在任何測試失敗，則進行其他更改以修復故障， 并將這些附加更改挑選到發布分支上，之后將重新構建軟件并重新運行測試。當測試全部通過時，將構建的可執行文件和數據文件打包。所有這些步驟都是自動化 的，所以發布工程師只需要運行一些簡單的命令，甚至只需在菜單驅動的UI上選擇一些菜單項，選中哪些更改（如果有的話）即可。

一旦候選構建已經被打包，它通常被加載到“ 分段（Staging） ”服務器上，以便由小組用戶（有時僅僅是開發團隊）進行進一步的 集成測試 。

一 種有用的技術涉及將來自生產流量的請求的副本（子集）發送到分段（staging）服務器，但是也將這些相同請求發送到當前生產服務器用于實際處理。來自 分段服務器的響應被丟棄，并且來自實況生產服務器的響應被發送回給用戶。這有助于確保在將服務器投入生產之前，可以檢測到任何可能導致嚴重問題（例如服務 器崩潰）的問題。

下一步是通常推出到正在 處理實況生產流量子集 的一個或多個“ 金絲雀（canary） ”服務器。與“分段”服務器不同，這些是處理和響應真實用戶。

最后，該版本可以推廣到所有數據中心中的所有服務器。對于非常高流量，高可靠性的服務，這在幾天的時間內逐步推出，以幫助減少任何中斷的影響，因為新引入的bug沒有被任何以前的步驟捕獲到。

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

2.9啟動批準

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

啟動過程還旨在確保在任何重要的新產品或功能啟動時通知公司內的相應人員。

Google有一個內部啟動批準工具，用于跟蹤所需的審查和批準，以確保符合每個產品定義的啟動流程。此工具可輕松自定義，以便不同的產品或產品區域可以具有不同的所需的審查和批準。

有關啟動過程的更多信息，請參見SRE手冊[7]的第27章。

2.10復盤

每當我們的任何生產系統發生嚴重停機或類似事故時，所涉及的人員都必須寫一份復盤文檔。本文檔描述了事件，包括標題、摘要、影響、時間表、根本原因、什么正常工作/什么無法工作和行動措施。 重點是問題，以及如何避免它們在未來再次發生，而不是對人或分攤責任 。 影響部分嘗試根據中斷持續時間，丟失的查詢（或失敗的RPC等）數量和收入來量化事件的影響。時間線部分給出了導致中斷的事件的時間表，以及診斷和糾正它 所采取的步驟。“什么正常工作/什么無法工作”部分描述教訓 – 哪些實踐幫助迅速發現和解決問題，什么出現錯誤，采取什么具體行動（最好把錯誤分配給特定的人）可以采取減少未來類似問題的可能性和/或嚴重程度。

有關Google復盤文化的更多信息，請參閱SRE手冊[7]的第15章。

2.11頻繁重寫

Google大多數軟件每隔幾年就會重寫一次。

這 看起來似乎非常昂貴。事實上，它消耗了很大一部分Google資源。然而，它也有一些關鍵的好處，這是Google保持敏捷性和長期成功的關鍵所在。在幾 年的時間里，隨著軟件環境和其周圍的其他技術發生變化，以及隨著技術或市場的變化影響用戶需求、愿望和期望，產品的需求通常會發生顯著變化。幾年前的軟件 是圍繞一組較舊的需求設計的，通常不是以對當前需求最佳的方式設計的。此外，它通常累積了很多復雜性。重寫代碼減少了所有不必要的累積復雜性，這些復雜性 正在解決不再那么重要的要求。此外，重寫代碼是一種向新的團隊成員傳遞知識和所有權感的方式。這種所有權感對生產力至關重要：工程師自然會更努力地開發特 性，并在他們認為是“他們的”的代碼在解決問題。頻繁的重寫也鼓勵工程師在不同項目之間的換崗，有助于鼓勵想法的異質授粉。頻繁的重寫也有助于確保代碼使 用現代技術和方法書寫。

3.項目管理

3.1 20％的時間

Google允許工程師高達20％的時間花在他們選擇的任何項目上工作，而無需他們的經理或任何其他人的批準。 這種對工程師的信任是非常有價值的，有幾個原因。首先，它允許任何人有一個好主意（即使這是一個想法，其他人不會立即認出是值得的）有足夠的時間來開發原 型，演示或展示示，以證明他們的想法具有價值。其次，它向管理層提供可能隱藏活動的可見性。在沒有允許20％ 時間的官方政策其他公司中，工程師有時會在不通知管理層的情況下工作在“偷偷摸摸”的項目。如果工程師可以正大光明地從事這樣的項目，描述他們在這些項目 的工作的正常狀態更新，甚至在他們的管理可能不認可項目價值的情況下，這是更好的選擇。擁有一個全公司范圍的官方政策和支持它的企業文化使這成為可能。第 三，允許工程師花費一小部分時間在更有趣的東西上工作，保持工程師的動機和興奮，他們做什么，并阻止他們被燒毀，這很容易發生，如果他們覺得被迫花費 100％他們的時間工作在更繁瑣的任務上面。在工作積極性方面，積極性的工程師和燒壞的工程師之間的生產力差異是超過20％。第四，它鼓勵創新企業文化。 看到其他工程師工作在有趣的實驗性的20％項目鼓勵大家做同樣的事情。

3.2目標和關鍵結果（OKR）

Google的個人和團隊需要明確記錄他們的目標，并評估他們在實現這些目標方面取得的進展。 團隊制定季度和年度目標，可衡量的關鍵結果顯示在實現這些目標方面取得進展。這是在公司的每一個層面上進行的，一直到整個公司的定義目標。個人和小團隊的 目標應該與他們所參與的更廣泛團隊以及整個公司目標的更高級目標保持一致。在每個季度末，記錄可衡量的關鍵結果的進展，每個目標的得分為0.0（無進展） 至1.0（完成100％）。 OKR和OKR分數通常在Google整個公司上可見（對于特別敏感的信息，例如高度保密的項目偶爾有例外），但它們不直接用作個人績效評估的輸入。

OKR 應該往高設置：期望的目標總平均分是65％，這意味著鼓勵團隊將大約50％的任務設置為比它們可能實際完成的任務要多。如果一個團隊的得分明顯高于這個數 字，鼓勵他們在下一個季度設置更加雄心勃勃的OKR（反之，如果他們得分明顯低于這個數字，鼓勵他們在下個季度更加保守地設置OKR）。

OKR 提供了一個關鍵的機制，用于溝通公司的每個部分工作，并鼓勵員工通過社會獎勵良好的績效…工程師知道他們的團隊將有一個會議，OKR將得分，并有自然 的驅動力盡管OKR對績效考核或薪酬沒有直接影響，但是盡力取得好成績。定義客觀和可衡量的關鍵結果有助于確保這種良好表現的人類驅動力被引導到對實現共 同目標的進展具有實際具體可衡量影響的事情。

3.3項目審批

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

3.4機構重組

偶 爾，公司高層決定取消一個大型項目，然后許多工程師在該項目上工作可能需要在新的團隊上找到新的項目。類似地，偶爾進行“碎片整理”工作，其中分散在多個 地理位置的項目被合并到較少數量的地點，其中一些地點中的工程師被要求改變團隊和/或項目以實現這一點。在這種情況下，工程師通常可以自由地從他們的地理 地點可用的位置中選擇他們的新團隊和角色，或者在碎片整理的情況下，他們也可以被選擇留在同一個團隊和項目通過移動到不同的地點。

此外，其他類型的機構重組，如合并或拆分團隊和報告鏈中的變化，似乎是相當頻繁的事件，雖然我不知道Google如何與其他大公司比較有啥區別。在一個大型，技術驅動的組織中，可能需要進行頻繁的重組，以避免由于技術和需求的變化而導致組織效率低下。

4.人員管理

4.1角色

我們將在下面更詳細地解釋，Google將工程和管理職業發展階梯分離開，將技術主導角色與管理層分開，將研究嵌入工程，并支產品經理，項目經理和現場可靠性工程師（SRE）支持工程師 。看來，至少有一些做法對維持Google開發的創新文化很重要。

Google在工程中有少量不同的角色。在每個角色中，有一個職業發展有不同的可能發展途徑，一系列的水平，以及晉升（與相關的改善薪酬，如薪水）的可能性，以承認在下一個水平的績效。

主要角色是：

●工程經理

這是此列表中唯一的人員管理角色。具有其他角色的人員（例如軟件工程師）可以管理人員，但是工程經理總是管理人員。工程經理通常是前軟件工程師，并且總是有相當多的技術專長，以及管理人的技能。

技術領導和人員管理之間有著區別。工程經理不一定領導項目；項目由技術主管領導；技術主管可以是工程經理，但更多時候是軟件工程師。項目的技術主管對該項目的技術決策有最終決定權。

經理負責選擇技術主管，評估他們團隊的表現。他們執行指導和協助職業發展，做績效評估（使用同行反饋的意見，見下文），并且負責一些薪酬一些方面的事情。他們還負責招聘過程的某些環節。

工程經理通常直接管理3到30人之間，雖然8到12是最常見的。

●軟件工程師（SWE）

大多數做軟件開發工作的人都是這個角色。 Google的軟件工程師的招聘標準非常高；通過聘用特別好的軟件工程師，困擾其他組織的許多軟件問題被避免或最小化。

Google有著獨立的工程和管理職業發展序列。 雖然軟件工程師可以管理人員或轉移到工程經理角色，但管理人員不是升級的要求，即使是在最高級別。在更高層次，顯示領導才能是必需的，但可以有許多形式。 例如，創建具有巨大影響或被許多其他工程師使用的偉大軟件就足夠了。這是非常重要的，因為這意味著那些具有很強的技術技能但缺乏管理人的愿望或技能的人仍 然有良好的職業發展道路，不需要他們選擇管理道路。這避免了一些組織遭受的問題，其中人們由于職業晉升的原因而最終爬上管理職位，但忽略了他們團隊中的人 的管理。

●研究科學家

這 個角色的招聘標準非常嚴格，并且條件非常高，需要表現出杰出的研究能力，這是出色的出版記錄*和*編寫代碼的能力證明。許多非常有才能的學術界人士，如果 能夠獲得軟件工程師的資格，就不能在Google獲得研究科學家的資格；Google大多數獲得博士學位的人是軟件工程師，而不是研究科學家。研究科學家 被評估他們的研究貢獻，包括他們的出版物，但除此之外，不同的標題，軟件工程師和研究科學家在谷歌的作用沒有太大的區別。兩者都可以做原創研究和發表論 文，都可以開發新的產品思想和新技術，并可以寫代碼和開發產品。 Google的研究科學家通常與軟件工程師一起，在相同的團隊中在相同的產品或相同的研究上工作。這種在工程中嵌入研究的做法極大地促進了新的研究能夠被 容納到運輸產品中。

●站點可靠性工程師（SRE）

操作系統的維護由軟件工程團隊完成，而不是傳統的系統管理員類型，但SRE的軟件工程技能的招聘要求略低于軟件工程職位的要求。 SRE角色的性質和目的在SRE書[7]中有詳細的解釋，因此我們不在這里進一步討論。

●產品經理

產品經理負責管理產品；作為產品用戶的倡導者，他們協調軟件工程師的工作，對這些用戶傳播重要的功能，與其他團隊協調，跟蹤Bug和計劃，以及確保所需的一切都到位，以產生高質量的產品。產品經理通常 不會 自己編寫代碼，而是與軟件工程師合作，以確保編寫正確的代碼。

●項目經理/技術項目經理

項 目經理的角色與產品經理大致相似，但是他們不是管理產品，而是管理項目、流程或運維（例如數據收集）。技術計劃經理相似，但也需要與他們的工作有關的專門 的技術專門知識。處理語音數據的語言學。在整個組織中，軟件工程師與產品經理和計劃管理者的比例不盡相同，但一般較高，例如，在4：1至30：1的范圍 內。

4.2設施

Google 是以有趣的設施而聞名天下，它具有幻燈片、球技和游戲室等功能。這有助于吸引和留住優秀的人才。 Google優秀咖啡館對員工免費，提供了那些功能，也巧妙鼓勵Google員工留在辦公室；饑餓絕不是離開的理由。 “微型廚房”的頻繁安置，員工可以享用小吃和飲料，也提供同樣的功能，但也作為非正式的想法交流的重要來源，因為許多對話開始在那里展開。健身房、運動和 現場按摩幫助保持員工健身、健康和快樂，這提高了生產力和保持。

Google的座位是開放式的，通常相當密集。雖然有爭議[20]，這鼓勵溝通，雖然有時犧牲個人太過集中的利益，但是很經濟的。

員工被分配一個單獨的座位，但座位重新分配相當頻繁（通常由于組織擴展的結果，例如每6-12個月重新分配一次），由管理者安排座位，以促進和鼓勵溝通，這是相鄰之間或幾乎相鄰的個體溝通總是很容易。

Google的設施都配備最先進的視頻會議設施的會議室，連接到對方預訂的日歷邀請只是一個點擊在屏幕上就可完成。

4.3培訓

Google鼓勵員工在許多方面受到教育：

●新的Google員工（“Noogler”）有一個強制性的初始培訓課程。

●技術人員（SWE和研究科學家）從“Codelabs”開始：在線短期個人技術培訓課程，包括編碼練習。

●Google為員工提供各種在線和面對面培訓課程。

●Google還支持在外部機構學習。

此外，每個Noogler通常被任命為官方“導師”和一個單獨的“伙伴”，以幫助他們入職的速度。非正式指導還通過與其經理、小組會議、代碼審查、設計審查和非正式流程的定期會議進行。

4.4換崗

Google 鼓勵公司不同部門之間的換崗，以幫助在整個組織傳播知識和技術，并改善跨組織溝通。允許在12個月后處于良好狀態的員工在項目和/或辦公室之間進行轉移。 還鼓勵軟件工程師在組織的其他部門進行臨時指派任務。例如， SRE（站點可靠性工程）中的六個月“輪換”（臨時任務）。

4.5績效考核和獎勵

Google 極力鼓勵反饋。工程師可以通過“對等獎金”和“kudos”給彼此明確的積極反饋。任何員工都可以任何其他員工提名“同伴獎金” – 現金獎金100美元，每年最多兩次。超越正常的工作職責，只需填寫一個網絡表單來描述原因。當同伴獎勵被授予時，隊友也通常得到通知。員工也可以給予 “kudos”，形式化的贊美聲明，為良好的工作提供明確的社會認可，但沒有財政獎勵;對于“kudos”，沒有要求工作超出正常的職責，并且對它們可以 被授予的次數的限制沒有限制。

經理也可以發放獎金，包括現金獎金，例如項目完成。和許多公司一樣，Google員工根據其績效獲得年度績效獎金和股權獎勵。

Google有一個非常仔細和詳細的晉升過程，包括由毛遂自薦或經理提名、自我審查、同行評審、經理評價;然后由促進委員會根據這些意見作出實際決定，結果可以由促進上訴委員會進一步審查。確保正確的人得到晉升對于為員工維持適當的激勵是至關重要。

另一方面，績效不佳則由經理反饋處理，如果有必要，還需要制定績效改進計劃，其中包括制定非常明確的具體績效目標，并評估實現這些目標的進展情況。如果失敗，可能會導致效果不佳，但實際上這在Google上極為罕見。

經理績效通過反饋調查進行評估； 要求每個員工每年兩次填寫關于他們的經理業績的調查，結果被匿名化和聚合，然后提供給經理。這種向上反饋對于維護和提高整個組織的管理質量非常重要。

5結論

我們簡要介紹了Google使用的大多數關鍵軟件工程實踐。當然，Google現在是一個龐大而多元化的組織，組織的一些部門有不同的做法。但是這里描述的做法一般由Google的大多數團隊遵循。

由 于涉及這么多不同的軟件工程實踐，以及Google成功的許多其他原因與我們的軟件工程實踐無關，因此很難給出任何定量或客觀的證據，將個體實踐與改進的 結果聯系起來。然而，Google的這些做法是經受了時間考驗的，在那里他們受到了成千上萬的優秀軟件工程師的集體主觀判斷。

對于那些主張使用本文中描述的特定實踐的其他組織中的人來說，也許有助于說“對Google來說足夠好了”。

致謝

特 別感謝Alan Donovan的非常詳細和建設性的反饋，并感謝Y aroslav Volovich，UrsH?lzle，Brian Strope，Alexander Gutkin，Alex Gruenstein和Hameed Husaini對本文的早期草稿非常有幫助的意見。

參考文獻

[1] , Nathan York, http://google-engtools.blogspot.com/2011/06/build-in-cloud-accessing-source-code.html

[2] , Christian Kemper, http://google-engtools.blogspot.com/2011/08/build-in-cloud-how-build-system-works.htm

[3] Nathan York

http://google-engtools.blogspot.com/2011/09/build-in-cloud-distributing-build-steps.html

[4] Milos Besta, YevgeniyMiretskiy and Jeff Cox

http://google-engtools.blogspot.com/2011/10/build-in-cloud-distributing-build.html

[5]Testing at the speed and scale of Google ,Pooja Gupta, Mark Ivey, and John Penix, Google engineering tools blog, June2011.

http://google-engtools.blogspot.com/2011/06/testing-at-speed-and-scale-of-google.html

[6] Michael Barnathan, Greg Estren,Pepper

Lebeck-Jone, Google techtalk, http://www.油Tube.com/watch?v=2qv3fcXW1mg

[7] Site Reliability Engineering ,Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy, O’ReillyMedia, April 2016, ISBN 978-1-4919-2909-4.

https://landing.google.com/sre/book.html

[8] Eric Schmidt, Jonathan Rosenberg. http://www.howgoogleworks.net

[9] of the World ,Jeff Jarvis, Harper Business, 2011. https://books.google.co.uk/books/about/What_Would_Google_Do.html?id=GvkEcAAACAAJ&redir_esc=y

[10] Our Culture , JohnBattelle, 8 September 2005.

https://books.google.co.uk/books/about/The_Search.html?id=4MY8PgAACAAJ&redir_esc=y

[11] The Google Story ,David A. Vise, Pan Books, 2008. http://www.thegooglestory.com/

[12] J. David Morgenthaler, MishaGridnev, Raluca Sauciuc, and Sanjay Bhansali.

http://static.googleusercontent.com/media/research.google.com/en//pubs/archive/37755.pdf

[13]Development at the speed and scale of Google ,A. Kumar, December 2010, presentation, QCon. http: //www.infoq.com/presentations/Development-at-Google

[14]How Google Tests Software , J. A. Whittaker, J. Arbon, andJ. Carollo, Addison-Wesley, 2012.

[15]Release Engineering Practices and Pitfalls , H. K. Wright and D. E.Perry, in Proceedings of the 34th International Conference on Software Engineering ┥CSE ’, IEEE, 2012, pp. 1281–1284. http://www.hyrumwright.org/papers/icse2012.pdf

[16] , H. K. Wright, D.Jasper, M. Klimek, C. Carruth, Z. Wan, inProceedings of the 29th International Conference on Software Maintenance┥CSM ’, IEEE, 2013,pp. 548–551.

[17] Why Google Stores Billions of Lines of Code in a Single Repository ,Rachel Potvin, presentation. https://www.油Tube.com/watch?v=W71BTkUbdqE

[18]The Motivation for a Monolithic Codebase , RachelPotvin, Josh Levenberg, to be published in Communications of the ACM, July2016.

[19] Durham Goode, Siddharth P. Agarwa,非死book blog post, January 7th, 2014.

https://code.非死book.com/posts/218678814984400/scaling-mercurial-at-非死book/

[20] , David Fullerton, Stack Overflowblog post, January 16th, 2015.

https://blog.stackoverflow.com/2015/01/why-we-still-believe-in-private-offices/

[21] Continuous Integration at Google Scale ,John Micco, presentation, EclipseCon, 2013. http://eclipsecon.org/2013/sites/eclipsecon.org.2013/files/2013-0324%20Continuous%20Integration%20at%20Google%20Scale.pdf

 

來自：http://www.techug.com/post/google-best-practices.html