谷歌的軟件工程

2017年1月31日

弗格斯·亨德森

<fergus@google.com>（工作）<fergus.henderson@gmail.com>（私人）

摘要

本文記載和描述了谷歌關(guān)鍵的軟件工程實踐叠洗。

作者簡介

??弗格斯·亨德森在谷歌從事了超過10年的軟件工程師工作。在1979年還是孩子時他就開始編程麻养，之后進(jìn)行編程語言設(shè)計和實踐的學(xué)術(shù)研究壹店。他和他的博士學(xué)位導(dǎo)師在墨爾本大學(xué)合作創(chuàng)立的研究小組開發(fā)出了Mercury語言。他是八次國際性會議的程序委員會委員求泰，并且已經(jīng)提交了超過50萬行開源代碼央渣。他曾是Usenet的comp.std.c++新聞組主持人，并被官方認(rèn)可為ISO C和C++ 委員會的“技術(shù)專家”渴频。弗格斯有超過15年商業(yè)軟件產(chǎn)業(yè)經(jīng)驗芽丹，他是谷歌軟件構(gòu)建工具Blaze最初的開發(fā)者之一，如今Blaze已經(jīng)在谷歌內(nèi)部廣泛使用卜朗。他參與了服務(wù)器端軟件背后的語音識別拔第、語音操作（早于Siri）和語音合成工作咕村。他目前主管著谷歌的文本到語音轉(zhuǎn)化工程團(tuán)隊，但他仍在編寫和評審大量的代碼蚊俺。他寫出的軟件如今安裝在超過10億臺設(shè)備上懈涛，每天被使用超過10億次。

目錄

摘要
作者簡介
目錄
1.引言
2.軟件開發(fā)
? 2.1. 源碼倉庫
? 2.2. 構(gòu)建系統(tǒng)
? 2.3. 代碼評審
? 2.4. 測試
? 2.5. 缺陷追蹤
? 2.6. 編程語言
? 2.7. 調(diào)試和分析工具
? 2.8. 發(fā)布工程
? 2.9. 啟動批準(zhǔn)
? 2.10. 事后剖析
? 2.11. 頻繁重寫

3.項目管理
? 3.1. 20%時間
? 3.2. 目標(biāo)和關(guān)鍵成果（OKRs）
? 3.3. 項目批準(zhǔn)
? 3.4. 企業(yè)重組

4.人員管理
? 4.1. 角色
? 4.2. 設(shè)施
? 4.3. 培訓(xùn)
? 4.4. 調(diào)動
? 4.5. 績效考核與獎勵

5.結(jié)論

致謝

參考文獻(xiàn)

1.引言

??谷歌是一家取得巨大成功的公司泳猬。同它成功的搜索引擎和AdWords一樣批钠，谷歌還開發(fā)了許多其他杰出的產(chǎn)品，包括谷歌地圖得封、谷歌新聞埋心、谷歌翻譯、谷歌語音識別忙上、Chrome和Android等拷呆。谷歌同樣大大提升和擴(kuò)展了許多通過收購YouTube等小公司得到的產(chǎn)品，而且對許多開源項目做出了顯著的貢獻(xiàn)疫粥。谷歌還展示了許多將要發(fā)布的驚人產(chǎn)品茬斧，無人駕駛汽車就在其列。

??谷歌成功的原因有很多：開明的領(lǐng)導(dǎo)手形、偉大的人物啥供、極高的招聘條件，以及在一個極速增長的市場中成功通過早期確立的領(lǐng)先優(yōu)勢帶來的財務(wù)實力库糠。還有一個引領(lǐng)谷歌走向成功的原因是伙狐，谷歌開發(fā)出了杰出的軟件工程實踐。基于世界上最有才華的軟件工程師們智慧的積累和提煉瞬欧，這些實踐隨著時間推移一直在進(jìn)步贷屎。我們想要和全世界分享這些實踐中的知識，以及我們一路上在犯錯中學(xué)習(xí)到的東西艘虎。

??這篇文章旨在簡要地記載唉侄、描述谷歌關(guān)鍵的軟件工程實踐。其他組織或個人可以將其與自己的軟件工程實踐進(jìn)行比較和對比野建，考慮是否應(yīng)用其中的一些實踐属划。

??許多作者（如引用[9]、[10]候生、[11]）都寫了書籍或文章來分析谷歌的成功和歷史同眯，但其中絕大多數(shù)都主要關(guān)注商業(yè)、管理和企業(yè)文化唯鸭；只有一小部分（如引用[1]须蜗、[2]、[3]、[4]明肮、[5]菱农、[6]、[7]柿估、[13]循未、[14]、[16]秫舌、[21]）研究過軟件工程方面只厘，這些書籍和文章中的大多數(shù)都只探討一個方面；并且所有書籍和文章都沒有進(jìn)行關(guān)于谷歌軟件工程實踐的總結(jié)舅巷，所以本文將提供一個整體的谷歌軟件工程實踐概述。

2.軟件開發(fā)

2.1. 源碼倉庫

??谷歌的絕大多數(shù)代碼都存放在一個統(tǒng)一的源碼倉庫中河咽，所有為谷歌工作的軟件工程師都可以訪問它钠右。有一些值得關(guān)注的例外，特別是兩個大型開源項目Chrome和Android飒房，它們存放在單獨的開源倉庫中狠毯，還有一些高價值和涉及重要安全的代碼被嚴(yán)格控制其訪問權(quán)限嚼松。總的來說献酗，大多數(shù)谷歌的項目都分享使用同一個源碼倉庫京闰，截止2015年1月俏站，這個86TB的倉庫中存儲有10億個文件，包括含有總計20億行代碼的900萬個源碼文件萌丈，這些代碼已經(jīng)有了3500萬次的提交歷史，并且提交數(shù)量以每天4萬次的速度不斷增長著[18]。這個倉庫的寫入權(quán)限被以下方式控制：只有在被列出的倉庫子樹所有者才能批準(zhǔn)對子樹的變更。但通常情況下，所有軟件工程師都可以訪問任意一部分代碼钧萍，他們可以查看公般、構(gòu)建、做本地修改、測試，還可以將變更發(fā)送給代碼所有者進(jìn)行評審草姻，如果評審?fù)ㄟ^，這部分變更就會被提交到倉庫中。無論項目的邊界如何，谷歌的企業(yè)文化鼓勵所有工程師學(xué)習(xí)如何修復(fù)代碼并且實踐于任何他們覺得存在錯誤的項目中。這增加了工程師的自主權(quán)并使工程師能夠獲得更高質(zhì)量的基礎(chǔ)架構(gòu)，從而更好滿足用戶的需求展哭。

??幾乎所有的開發(fā)活動都發(fā)生在倉庫的“頭部”而非分支觉痛，這樣有助于盡快識別集成問題所在榕莺、極大地減小合并分支的工作量吧史，還可以更快更容易地推出安全修復(fù)程序岩睁。

??自動化測試系統(tǒng)頻繁工作，通常在每次測試的傳遞依賴項中任何文件更改后運行焚刚，盡管這么做并不總是可行肃拜。當(dāng)某次變更導(dǎo)致測試結(jié)果失敗時士聪，系統(tǒng)會在幾分鐘內(nèi)自動通知變更提交者和評審員曼库。很多團(tuán)隊通過放置醒目的標(biāo)志物甚至是掛有彩色編碼燈的雕塑來使自己的構(gòu)建狀態(tài)變得顯眼（綠色表示構(gòu)建成功并且所有測試用例通過，紅色表示有一些測試用例沒有通過，黑色表示構(gòu)建失敗），這種方法有助于讓軟件工程師追求成功的構(gòu)建。大多數(shù)大型團(tuán)隊還有一名“構(gòu)建警察”來保證測試持續(xù)通過，他們在提交違規(guī)變更的開發(fā)者身旁工作來快速修復(fù)問題或者回滾違規(guī)變更（這些構(gòu)建警察一般是團(tuán)隊成員輪流擔(dān)任纠炮，或者由團(tuán)隊中有經(jīng)驗的成員擔(dān)任）穷躁。即使在非常巨大的團(tuán)隊中，這種專注于成功構(gòu)建的模式也能使得開發(fā)工作變得更加實用。

??代碼所有權(quán)。倉庫中每個子樹中都有一個存儲著子樹“所有者”用戶id的文件，子目錄一般從父目錄那里繼承所有者，也可以選擇抑制繼承画拾。如下文的代碼評審部分所述，每個子樹的所有者控制著子樹的寫入權(quán)限。每個子樹——尤其是那些地理位置上分散的團(tuán)隊——需要有至少兩名所有者，實際應(yīng)用中人數(shù)會更多旧巾。常見情況是團(tuán)隊中所有成員都會被列為子樹所有者。因為不僅是團(tuán)隊成員，谷歌的任意工程師都會向子樹提交變更，所以變更必須得到團(tuán)隊成員的批準(zhǔn)。這樣可以確保每次變更都被了解這個軟件的工程師所評審。

??想要了解更多關(guān)于谷歌源碼倉庫的內(nèi)容滨达，可以閱讀引用[17]、[18]和[21]；想了解另一個大公司如何應(yīng)對類似的挑戰(zhàn)，可以閱讀引用[19]。

2.2. 構(gòu)建系統(tǒng)

??谷歌使用分布式系統(tǒng)Blaze來進(jìn)行編譯浇冰、鏈接軟件以及運行測試用例漂佩。Blaze提供用于跨整個倉庫工作的構(gòu)建軟件和測試軟件的標(biāo)準(zhǔn)命令瘩缆。這些標(biāo)準(zhǔn)命令和高度優(yōu)化的實現(xiàn)意味著任何谷歌的軟件工程師通常都可以十分簡單迅捷地構(gòu)建和測試倉庫中的任何軟件谐算，這種一致性是工程師跨項目邊界進(jìn)行變更活動的關(guān)鍵推動因素。

??程序員編寫B(tài)laze所使用的如何構(gòu)建目標(biāo)軟件的“BUILD”文件，例如庫馅闽、程序和測試用例等構(gòu)建實體是使用相當(dāng)高級的聲明性構(gòu)建規(guī)范聲明的攀圈，規(guī)范對每個構(gòu)建實體指定名稱、源文件以及它所依賴的庫或其他構(gòu)建實體。這些構(gòu)建規(guī)范由名為“構(gòu)建準(zhǔn)則”的聲明組成，每個聲明都指定如“這個C++庫帶有這些源文件，這些源文件依賴于這些其他庫”這樣的高級概念萝玷，構(gòu)建系統(tǒng)需要將每個構(gòu)建規(guī)則映射到一組構(gòu)建步驟，例如：編譯、鏈接每個源文件的步驟辽装，以及要確定所使用的編譯器和編譯標(biāo)志的步驟。

??在某些情況下肛度，特別是Go語言程序伪煤，構(gòu)建文件可以被自動生成（并更新）蝙砌，因為BUILD文件中的依賴關(guān)系（通常）是源文件中依賴關(guān)系信息的抽象肚邢，但是它們?nèi)匀粫粚懭雮}庫峻厚。這樣保證了構(gòu)建系統(tǒng)能夠僅通過分析構(gòu)建文件（而不需要源文件）來確定依賴關(guān)系辜王，避免了構(gòu)建系統(tǒng)與所支持的許多不同語言的編譯器汹来、分析工具間的過度耦合续膳。

??構(gòu)建系統(tǒng)的實現(xiàn)使用到谷歌分布式計算基礎(chǔ)架構(gòu)，每個構(gòu)建工作通常分布在成百上千的物理機(jī)器中運行收班，這使得構(gòu)建超大項目或者并行執(zhí)行數(shù)千個測試用例成為可能。

??單個的構(gòu)建步驟必須是“封閉”的闺阱，它們僅僅依賴于聲明的輸入炮车。分布構(gòu)建的結(jié)果是強制所有的依賴都要被正確聲明舵变，只有聲明的輸入才可以被送到運行構(gòu)建步驟的機(jī)器酣溃。因此瘦穆，可以根據(jù)構(gòu)建系統(tǒng)來了解真正的依賴關(guān)系，甚至是構(gòu)建系統(tǒng)調(diào)用到的編譯器也可以被一并視為輸入赊豌。

??單個的構(gòu)建步驟是確定的扛或，因此構(gòu)建系統(tǒng)能緩存構(gòu)建結(jié)果。軟件工程師能從一個舊的變更版本同步自己的工作區(qū)碘饼，也可以重新構(gòu)建并且將會得到和之前完全一致的二進(jìn)制文件熙兔。另外，這個緩存機(jī)制能在不同用戶間安全地共享艾恼。（為了讓緩存機(jī)制正常工作住涉，我們必須消除構(gòu)建調(diào)用的工具中的非確定因素，例如：清除生成輸出文件中的時間戳钠绍。）

??構(gòu)建系統(tǒng)是可靠的舆声。它會追蹤構(gòu)建準(zhǔn)則本身變更的依賴性，如果產(chǎn)生目標(biāo)文件的操作變更時柳爽，即便是操作的輸入沒有改變媳握，系統(tǒng)也知道重新構(gòu)建目標(biāo)文件，如構(gòu)建時編譯器選項的更改就會導(dǎo)致上述構(gòu)建系統(tǒng)行為磷脯。構(gòu)建系統(tǒng)還能適當(dāng)處理以部分方式中斷構(gòu)建的問題蛾找，或在構(gòu)建過程中更改源碼文件問題：這種情況下你只需要重新運行構(gòu)建命令。所以永遠(yuǎn)沒必要在這個構(gòu)建系統(tǒng)上運行類似“make clean”的命令赵誓。

??構(gòu)建結(jié)果打毛，包括中間結(jié)果都緩存在云平臺上。即便是不同用戶的另一個構(gòu)建請求需要相同的結(jié)果俩功，構(gòu)建系統(tǒng)也不會重新構(gòu)建隘冲，而是自動復(fù)用結(jié)果。

??增量重新構(gòu)建是很快的绑雄。構(gòu)建系統(tǒng)會駐留在內(nèi)存中展辞，所以對于重新構(gòu)建命令，系統(tǒng)會分析出自上次構(gòu)建以來更改過的文件万牺。

??提交前檢查罗珍。當(dāng)初始化一次代碼評審和/或準(zhǔn)備提交一次變更時，谷歌有會自動運行的一系列測試工具開始工作脚粟。源碼倉庫的每個子樹都有一份配置文件覆旱，文件里確定哪些測試需要運行，在代碼評審時運行核无、在提交前立即運行還是兩種情況都運行扣唱。測試可以是同步的，即在發(fā)送變更以供評審之前和/或在提交變更到源碼倉庫前（適用于快速運行的測試）；測試也可以是異步的噪沙，結(jié)果將通過電子郵件發(fā)送給代碼評審討論主題炼彪。（評審主題是進(jìn)行代碼評審的電子郵件主題，主題內(nèi)的所有信息都會展示在Web端的代碼評審工具中正歼。）

2.3. 代碼評審

??谷歌建立起了優(yōu)秀的Web端代碼評審工具辐马，集成有電子郵件，作者可以請求評審局义，評審員可以并排查看代碼差異（有漂亮的顏色編碼來體現(xiàn)視覺差異）并對其進(jìn)行評論喜爷。當(dāng)變更的作者啟動一次代碼評審時，評審員會收到電子郵件通知萄唇，電子郵件中包含一條對應(yīng)Web評審工具中這次評審頁面的鏈接檩帐。當(dāng)評審員添加代碼評論時，電子郵件也會發(fā)給作者另萤。此外轿塔，自動化工具可以發(fā)送通知，例如自動化測試的結(jié)果或者靜態(tài)分析工具的發(fā)現(xiàn)仲墨。

??所有對主源碼倉庫的變更“必須”被至少一名工程師評審脓鹃。此外狂男，如果不是某個文件所有者的工程師提交了關(guān)于這個文件的更改啤月，那么必須由至少一名文件的所有者評審并且批準(zhǔn)變更财异。

??在特殊情況下，子樹的所有者可以在評審前對子樹進(jìn)行緊急提交變更癌蚁，但他仍然必須指定評審員幻梯。直到評審?fù)ㄟ^前，變更的作者和評審員肯定會被指責(zé)做這種緊急提交努释。在這種情況下碘梢，解決評審意見所需的任何修改必須在新的變更中提交，因為原始的變更已經(jīng)被提交了伐蒂。

??谷歌有工具通過查看被更改的代碼的所有權(quán)和作者煞躬、最近評審員的歷史以及每個潛在評審員的待審代碼審閱次數(shù)，自動為給定的更改建議評審員逸邦。一次變更影響的每個子樹的至少一個所有者必須審查并批準(zhǔn)變更恩沛。但除此以外，作者可以自由選擇他們認(rèn)為合適的評審員缕减。

代碼評審的一個潛在問題是雷客，如果評審員回復(fù)太慢或者極度不愿意贊成變更，這可能潛在地拖慢開發(fā)桥狡。事實上讓代碼的編寫者選擇他們的評審員有助于避免這樣的問題搅裙，允許工程師避開可能過度占用他們的代碼的評審員皱卓，或允許工程師向較不全面的評審員發(fā)送簡單變更的審閱請求，向更有經(jīng)驗的評審員或者多個評審員發(fā)送更加復(fù)雜的變更的審閱請求部逮。
?
??每個項目的代碼評審的討論會自動復(fù)制到項目維護(hù)者指定的郵件列表中娜汁。任何人都可以在提交變更之前和之后自由評論任何變更，不管他們是否被指定為這個變更的評審員甥啄。如果發(fā)現(xiàn)了一個缺陷，追蹤引入它的變更并對原始代碼評審線程進(jìn)行注釋來指出錯誤是很常見的炬搭，以便原始作者和評審員們能夠意識到這個錯誤蜈漓。

??工程師也可以向幾個評審員發(fā)送代碼評審，然后一旦其中一位評審員批準(zhǔn)（當(dāng)然前提是作者或者第一個響應(yīng)的評審者是所有者）宫盔，在其他評審員評論前融虽，立即提交更改，并在后續(xù)的更改中處理隨后的任何評審注釋灼芭。這可以減少評審的周轉(zhuǎn)時間有额。

??倉庫除了主要部分之外，還有一個“實驗”部分彼绷，在這個部分正常的代碼評審請求不被強制執(zhí)行巍佑。然而，在產(chǎn)品中運行的代碼必須存儲在倉庫的主要部分寄悯，并且強烈鼓勵工程師在倉庫的主要部分編寫開發(fā)代碼萤衰，而不是在實驗區(qū)開發(fā)然后再移動到主要部分。因為相比在代碼開發(fā)之后猜旬，代碼評審在代碼編寫中完成是最有效的脆栋。在實踐中工程師甚至經(jīng)常對實驗中的代碼請求代碼審查。

??工程師們被鼓勵保持較小的單個變更洒擦，并最好把大的變更分解成一系列更小的變更椿争，以便一個評審員能夠一次性更簡單地審閱。這也使編寫者更容易對每個評審中提出的主要更改中做出反應(yīng)熟嫩；非常大的變更經(jīng)常太死板并且反對評審員建議的更改秦踪。一種被鼓勵的保持變更較小的方法¹ 是使用代碼檢查工具，用這次變更的大小標(biāo)記每次代碼評審掸茅。對30-99行代碼的添加/刪除/移除的更改被標(biāo)記為“中等大小”洋侨，對超過300行代碼的變更被標(biāo)記為越來越貶低的標(biāo)簽，例如“大”（300-999）倦蚪、“極其巨大”（1000-1999）等希坚。（然而，以一種典型的谷歌式的方式陵且，在每年的幾天內(nèi)裁僧，如在每年的“像海盜一樣談話的日子”里个束，用有趣的替代說法來代替這些熟悉的描述，以此來保持樂趣聊疲。:）

¹ 這在近幾年有所改變茬底。最新版本的代碼檢查工具不再對大型的變更標(biāo)記使用貶義標(biāo)簽，但是它們?nèi)匀槐挥么笮?biāo)記获洲，例如“S”阱表、“M”、“L”贡珊、“XL”最爬。

2.4. 測試

??單元測試在谷歌得到了強烈支持和廣泛實行。所有產(chǎn)品中使用的代碼都被預(yù)期擁有單元測試门岔，并且如果源文件在沒有對應(yīng)的測試時被添加爱致，代碼檢查工具會突出顯示。代碼評審員通常要求任何增加新功能的更改都應(yīng)該增加新的測試來覆蓋新功能寒随。模擬框架（它允許構(gòu)建輕量級單元測試糠悯，甚至對于依賴重量級庫的代碼也是如此）相當(dāng)流行。

??集成測試和回歸測試也被廣泛應(yīng)用妻往。

??正如上面在“提交前檢查”中討論的互艾，測試可以作為代碼審查和提交過程的一部分自動執(zhí)行。

??谷歌還擁有測量測試覆蓋率的自動化工具讯泣。測量結(jié)果也被整合為源代碼瀏覽器中的可選層忘朝。

??部署前的負(fù)載測試在谷歌也是必不可少的。團(tuán)隊預(yù)計會生成一個顯示關(guān)鍵度量的表格或圖表判帮，特別是延遲和錯誤率隨著輸入請求的速率如何變化局嘁。

2.5. 缺陷追蹤

??谷歌使用一個名為Buganizer的缺陷跟蹤系統(tǒng)追蹤問題：缺陷、特性請求晦墙、客戶問題和工序流程（比如發(fā)布或清理工作）悦昵。缺陷被分類為分級組件，每個組件可以具有默認(rèn)的受托人和給次級接收者的默認(rèn)郵件列表晌畅。當(dāng)發(fā)送源更改以供評審時但指，工程師會被提示將變更與特定的發(fā)行編號相關(guān)聯(lián)。

??谷歌的團(tuán)隊（盡管不是所有）經(jīng)常按時掃描他們組件中的未決問題抗楔，確定它們的優(yōu)先級棋凳，并在適當(dāng)?shù)臅r候?qū)⑺鼈兎峙浣o特定的工程師。一些團(tuán)隊有一個人專門負(fù)責(zé)缺陷的分級连躏，其他的團(tuán)隊在定期的團(tuán)隊會議上進(jìn)行缺陷的分級剩岳。谷歌的許多團(tuán)隊利用缺陷上的標(biāo)簽來指示是否已經(jīng)對缺陷進(jìn)行了篩選，以及每個缺陷預(yù)定在哪個版本修復(fù)入热。

2.6. 編程語言

??在谷歌我們強烈鼓勵軟件工程師使用谷歌官方批準(zhǔn)的五種編程語言之一來編寫程序：C++拍棕，Java晓铆，Python，Go或JavaScript绰播。最小化被使用的不同編程語言的數(shù)量可以減少代碼重用和程序員協(xié)作的障礙骄噪。

??谷歌還有針對每種語言的谷歌風(fēng)格指南，以確保那種語言的代碼在整個公司都以相似的風(fēng)格蠢箩、布局链蕊、命名規(guī)約等編寫。此外谬泌，還有一個全公司的可讀性培訓(xùn)過程滔韵，在這個過程中，關(guān)心代碼可讀性的經(jīng)驗豐富的工程師通過回顧重大變化或者一系列變化來訓(xùn)練其他工程師如何用特定語言編寫可讀的呵萨、慣用的代碼奏属，直到評審員滿意地認(rèn)為作者知道如何使用那種語言編寫可讀的代碼跨跨。每一項在特定語言中添加不平凡的新代碼的更改都必須得到用該語言通過了“可讀性”培訓(xùn)過程的人的批準(zhǔn)潮峦。

??除了這五種語言之外，還有許多專門的領(lǐng)域特定語言用于特定的目的（例如勇婴，用于指定構(gòu)建目標(biāo)及其依賴項的構(gòu)建語言）忱嘹。

??這些不同編程語言之間的互操作主要使用Protocol Buffers來完成。Protocol Buffers是一種以高效但可擴(kuò)展的方式對結(jié)構(gòu)化數(shù)據(jù)進(jìn)行編碼的方法耕渴。它包括用于指定結(jié)構(gòu)化數(shù)據(jù)的特定于域的語言拘悦，以及包含這樣描述的編譯器，并在C++橱脸、Java础米、Python中生成代碼，用于構(gòu)建添诉、訪問屁桑、序列化和反序列化這些對象。谷歌的Protocol Buffers版本與谷歌的RPC庫集成栏赴，支持簡單的跨語言RPC蘑斧，請求和響應(yīng)的序列化和反序列化由RPC框架自動處理。

??即使擁有龐大的代碼庫和語言多樣性须眷，過程的通用性仍是使開發(fā)變得容易的關(guān)鍵：只有一組命令來執(zhí)行所有常見的軟件工程任務(wù)（比如檢查竖瘾、編輯、構(gòu)建花颗、測試捕传、評審、提交扩劝、文件缺陷報告等）乐横，并且相同的命令可以被無論什么項目或語言使用求橄。開發(fā)人員不需要因為他們正在編輯的代碼碰巧是不同項目的一部分或者用不同語言編寫而學(xué)習(xí)新的開發(fā)過程。

2.7. 調(diào)試和分析工具

??谷歌服務(wù)器與提供多個調(diào)試運行服務(wù)器的工具的庫鏈接葡公。萬一服務(wù)器崩潰罐农，信號處理器將自動將堆棧跟蹤轉(zhuǎn)儲到日志文件，并保存核心文件催什。如果崩潰是由于堆內(nèi)存耗盡造成的涵亏，服務(wù)器將轉(zhuǎn)儲活動堆對象的采樣子集的分配站點的堆棧跟蹤。還有用于調(diào)試的Web接口蒲凶，允許檢查傳入和傳出的RPC（包括定時气筋、錯誤率、速率限制等）旋圆、更改命令行標(biāo)志值（例如增加特定模塊的日志詳細(xì)性）宠默、資源消耗、簡要介紹等灵巧。這些工具極大地提高了調(diào)試的整體易用性搀矫，達(dá)到了很少啟動gdb等傳統(tǒng)調(diào)試器的階段。

2.8. 發(fā)布工程

??少數(shù)團(tuán)隊有專門的發(fā)布工程師刻肄，但對于谷歌的大多數(shù)團(tuán)隊來說瓤球，發(fā)布工程工作是由普通的軟件工程師完成的。

??對于大多數(shù)軟件來說敏弃，發(fā)布是經(jīng)常進(jìn)行的卦羡。每周或每兩周發(fā)布是常見的目標(biāo)，有些團(tuán)隊甚至每天發(fā)布麦到。通過自動化大多數(shù)普通的發(fā)布工程任務(wù)使其成為可能绿饵。頻繁發(fā)布有助于使工程師保持積極（為某個要到未來幾個月甚至幾年才會發(fā)布的東西感到激動是更難的事情），并且通過允許更多的迭代來提高總體速度瓶颠，從而內(nèi)獲得更多的機(jī)會來反饋和更多的機(jī)會來回應(yīng)反饋拟赊。

??一次發(fā)布通常從一個新的工作區(qū)開始，通過同步到最新的“綠色”構(gòu)建的更改編號（所有自動測試都通過的最后一次更改）步清，制作發(fā)布分支要门。發(fā)布工程師可以選擇其他更改為“挑選”，即從主分支合并到發(fā)布分支廓啊。然后軟件將從頭開始重建欢搜，并運行測試。如果任何測試失敗谴轮，則會進(jìn)行額外的更改以修復(fù)故障炒瘟，并將這些額外的更改挑選到發(fā)布分支上，之后將重建軟件并重新運行測試第步。當(dāng)測試全部通過時疮装，內(nèi)置的可執(zhí)行文件和數(shù)據(jù)文件被打包缘琅。所有這些步驟都是自動的，所以工程師只需要運行一些簡單的命令廓推，甚至只是選擇一個菜單驅(qū)動的用戶界面的一些條目刷袍，并選擇其中的變化（如果有的話）來挑選。

??一旦候選構(gòu)建被打包樊展，它通常被加載到“staging”服務(wù)器上呻纹，以便由一小組用戶（有時只是開發(fā)團(tuán)隊）進(jìn)行進(jìn)一步的集成測試。

??一種有用的技術(shù)不僅將來自生產(chǎn)流量的請求的副本（的一部分）發(fā)送到臨時服務(wù)器专缠，而且將這些相同的請求發(fā)送到當(dāng)前的生產(chǎn)服務(wù)器以進(jìn)行實際處理雷酪。臨時服務(wù)器的響應(yīng)被丟棄，來自現(xiàn)場生產(chǎn)服務(wù)器的響應(yīng)被發(fā)送回用戶涝婉。這有助于確保在將服務(wù)器投入生產(chǎn)之前能夠檢測到可能導(dǎo)致嚴(yán)重問題（例如服務(wù)器崩潰）的任何問題哥力。

??下一步通常是向一個或多個正在處理一部分實時生產(chǎn)流量的“canary”服務(wù)器推送。與“staging”服務(wù)器不同墩弯，這些服務(wù)器對真實用戶進(jìn)行處理和響應(yīng)吩跋。

??最后，發(fā)布版本可以被推送到所有數(shù)據(jù)中心的所有服務(wù)器最住。對于非常高流量钞澳、高可靠性的服務(wù)怠惶，這是通過幾天內(nèi)的逐步推出來完成的涨缚，以幫助減少由于新引入的未被前面任何步驟捕獲的錯誤而導(dǎo)致的任何中斷的影響。

??有關(guān)谷歌發(fā)布工程的更多信息策治，請參閱SRE圖書第8章[7]脓魏。也見[15]。

2.9. 啟動批準(zhǔn)

??任何用戶可見的更改或重大的設(shè)計更改的啟動都需要執(zhí)行更改的核心工程團(tuán)隊之外的許多人的批準(zhǔn)通惫。特別地茂翔，需要批準(zhǔn)（通常要經(jīng)過詳細(xì)審查）以確保代碼符合法律要求、隱私要求履腋、安全要求珊燎、可靠性要求（例如，具有適當(dāng)?shù)淖詣颖O(jiān)控以檢測服務(wù)器中斷并自動通知適當(dāng)?shù)墓こ處煟┳窈I(yè)務(wù)需求等悔政。

??發(fā)布過程還被設(shè)計成確保每當(dāng)重要的新產(chǎn)品或功能發(fā)布時，公司內(nèi)部合適的人員都會得到通知延旧。

??谷歌有一個內(nèi)部啟動批準(zhǔn)工具谋国，用于跟蹤所需的審查和批準(zhǔn)，并確保符合每個產(chǎn)品定義的啟動過程迁沫。該工具易于定制捌蚊，因此不同的產(chǎn)品或產(chǎn)品區(qū)域可以擁有不同的所需審查和批準(zhǔn)集缅糟。

??有關(guān)啟動過程的更多信息溺拱，請參閱SRE圖書第27章[7]

2.10. 事后剖析

??每當(dāng)我們的生產(chǎn)系統(tǒng)發(fā)生重大中斷或類似事故時，相關(guān)人員就需要編寫事后剖析文檔泥从。該文檔描述了該事件句占，包括標(biāo)題、摘要躯嫉、影響纱烘、時間線、根本原因祈餐、什么生效/什么沒有生效以及行動條目擂啥。關(guān)注的是問題以及如何在未來避免它們，而不是針對人員或分配責(zé)任帆阳。影響部分嘗試根據(jù)中斷持續(xù)時間哺壶，丟失查詢數(shù)（或RPC失敗等）和收入來量化事件的影響。時間線部分給出了導(dǎo)致中斷的事件的時間線以及診斷和糾正中斷的步驟蜒谤。什么生效/什么沒有生效部分描述了所吸取的教訓(xùn)——哪些做法有助于快速檢測和解決問題山宾，出現(xiàn)了什么問題，以及可以采取哪些具體行動（最好歸檔為分配給特定人員的缺陷）來降低未來類似問題的可能性和/或嚴(yán)重性资锰。
??有關(guān)谷歌交付后驗收文化的更多信息濒募，請參閱SRE圖書第15章[7]。

2.11. 頻繁重寫

??谷歌的大部分軟件每幾年就會重寫一次遗座。

??這看起來代價高昂馋记。事實上，它確實消耗了谷歌資源的很大一部分。然而籽慢，它還具有一些關(guān)鍵優(yōu)勢弃秆，這些優(yōu)勢對于Google的敏捷性和長期成功至關(guān)重要氢卡。在幾年的時間里峡捡，隨著軟件環(huán)境和周圍的其他技術(shù)的變化阁吝，以及隨著技術(shù)或市場的變化影響用戶需求坷虑、愿望和期望，產(chǎn)品的需求發(fā)生顯著變化是平常的。幾年前的軟件是圍繞著一組較舊的需求而設(shè)計的惩妇，通常不是以對當(dāng)前需求最理想的方式設(shè)計的。此外豁护，它通常積累了大量的復(fù)雜性楚里。重寫代碼減少了處理不再那么重要的需求的所有不必要的累積復(fù)雜性班缎。此外达址，重寫代碼是將知識和所有權(quán)感轉(zhuǎn)移給更新的團(tuán)隊成員的一種方式。這種歸屬感對生產(chǎn)率至關(guān)重要：工程師自然會投入更多的精力開發(fā)特性和修復(fù)他們認(rèn)為屬于他們的代碼中的問題满葛。頻繁的重寫也鼓勵工程師在不同項目之間的流動嘀韧，這有助于鼓勵思想的交叉?zhèn)魇凇ｎl繁重寫也有助于確保代碼是使用現(xiàn)代技術(shù)和方法編寫的蹂随。

3.項目管理

3.1. 20%時間

??工程師被允許把最多20%的時間花在自己選擇的任何項目上岳锁，而不需要經(jīng)理或其他任何人的批準(zhǔn)激率。這種對工程師的信任是非常有價值的乒躺，有以下幾個原因。首先讳推，它允許任何有好主意的人银觅，即使別人不會立即認(rèn)識到這個主意是有價值的究驴，他們也有足夠的時間來開發(fā)一個原型、演示版或報告以展示他們的想法的價值熙侍。其次核行，它提供了對可能隱藏的活動的可視化管理减余。在其他沒有允許20%時間的官方政策的公司里如筛，工程師有時會在不通知管理層的情況下從事“臭鼬工程”項目晤柄。如果工程師能夠?qū)@些項目持開放態(tài)度芥颈，在他們的常規(guī)狀態(tài)更新中描述他們在這些項目上的工作，那就更好了盾计，即使他們的管理層可能不同意項目的價值。有一個公司范圍的官方政策和支持它的文化使這成為可能岩四。第三刚夺，通過允許工程師們花一小部分時間在更有趣的事情上侠姑，使得工程師們對他們所做的事保持積極和興奮，并防止他們精疲力盡安吁，如果他們覺得被強迫花100%的時間來處理更繁瑣的任務(wù)鬼店，這種精疲力盡的情況很容易發(fā)生滥玷。忙碌的、有進(jìn)取心的工程師和精疲力盡的工程師之間的生產(chǎn)率差別遠(yuǎn)遠(yuǎn)超過20%。第四杠袱，這種政策鼓勵創(chuàng)新文化∝睬荩看到其他工程師開展有趣的實驗性20％項目霞掺，會鼓勵每個人都這樣做。

3.2. 目標(biāo)和主要成果（OKRS）

??谷歌的個人和團(tuán)隊需要明確記錄他們的目標(biāo)讹躯，并評估這些目標(biāo)的進(jìn)展情況菩彬。團(tuán)隊制定了季度目標(biāo)和年度目標(biāo)，并以可衡量的關(guān)鍵成果顯示這些目標(biāo)的進(jìn)展情況潮梯。這是在公司的每一個層級完成的骗灶，一直到為整個公司定義目標(biāo)。個人和小團(tuán)隊的目標(biāo)應(yīng)該與他們所在的更大團(tuán)隊的更高級別目標(biāo)以及公司總體目標(biāo)相一致栽连。在每個季度結(jié)束時脐湾，記錄可衡量的關(guān)鍵結(jié)果的進(jìn)展情況机杜，并給每個目標(biāo)一個分?jǐn)?shù) ，從0.0（無進(jìn)展）到1.0（100%完成）。OKRs和OKR得分在谷歌中通常都是可見的（偶爾也會有一些特別敏感的信息赞辩，比如高度機(jī)密的項目），但它們并沒有直接用于個人的績效評估。

??OKRs應(yīng)該要設(shè)置得高：理想的總體平均得分是65%娘荡，這意味著鼓勵團(tuán)隊將目標(biāo)設(shè)定為比實際完成的任務(wù)多50%左右换薄。如果一個團(tuán)隊得分明顯高于這個水平驹碍，他們就會被鼓勵為下一季度設(shè)置更有野心的OKRs（反之，如果得分明顯低于這個水平延刘，他們就會被鼓勵在下一季度設(shè)置更保守的OKRs）审编。

??OKRs提供了一個關(guān)鍵機(jī)制，用于溝通公司各個部門正在開展的工作，并通過社群激勵措施鼓勵員工提供良好的績效......工程師們知道他們的團(tuán)隊將會召開OKRs會議，并且盡管OKRs對績效評估或薪酬沒有直接影響虏等，但他們有一種自然的動力去爭取好成績逛揩。 確定客觀和可衡量的關(guān)鍵結(jié)果有助于確保這種表現(xiàn)良好的人力驅(qū)動能夠引導(dǎo)到對實現(xiàn)共同目標(biāo)的進(jìn)展產(chǎn)生實際具體可衡量影響的事物上。

3.3. 項目批準(zhǔn)

??雖然有一個定義良好的啟動審批流程憔四，但谷歌沒有一個定義良好的項目審批或取消流程。盡管在谷歌工作了10多年裕循，現(xiàn)在我自己也成為了一名經(jīng)理剥哑，但我仍然不完全明白這些決定是如何做出的座哩。在一定程度上缠诅，這是因為在整個公司重慢，解決這個

??問題的方法并不統(tǒng)一。每個級別的經(jīng)理都要對他們的團(tuán)隊所從事的項目負(fù)責(zé)浆竭，并在他們認(rèn)為合適的時候行使他們的判斷力。在某些情況下惨寿，這意味著這些決策是以一種自下而上的方式做出的，工程師可以在他們的團(tuán)隊范圍內(nèi)自由地選擇要從事的項目删窒。在其他情況下裂垦，這些決策是以一種自上而下的方式做出的，主管或經(jīng)理決定哪些項目將繼續(xù)進(jìn)行肌索，哪些項目將獲得額外資源蕉拢，哪些項目將被取消。

3.4. 公司重組

??有時會做出取消一個大型項目的執(zhí)行決定诚亚，然后許多從事該項目的工程師可能不得不在新的團(tuán)隊中尋找新的項目晕换。類似地，也有偶爾的“重組”工作將跨多個地點的項目合并成更少的地點站宗，某些地點的工程師需要改變團(tuán)隊和/或項目來實現(xiàn)這一點闸准。在這種情況下，工程師通成颐穑可以自由地從其地點的可用職位中選擇新的團(tuán)隊和角色夷家，或者在碎片整理的情況下，他們也可以通過變動職位來選擇留在同一團(tuán)隊和項目中敏释。

??此外库快，其他類型的公司重組，如合并或拆分團(tuán)隊以及報告鏈的變化钥顽，似乎是相當(dāng)頻繁的事情义屏，盡管我不知道谷歌在這方面與其他大公司相比如何。在大型的、技術(shù)驅(qū)動的組織中闽铐，當(dāng)技術(shù)和需求發(fā)生變化時膀曾，為了避免組織的低效，可能需要頻繁的重組阳啥。

4.人事管理

4.1. 角色

??正如我們將在下面更詳細(xì)地解釋的那樣添谊，谷歌將工程和管理職業(yè)發(fā)展階梯分開，將技術(shù)主管角色從管理中分離出來察迟，將研究嵌入到工程中斩狱，并為工程師提供產(chǎn)品經(jīng)理、項目經(jīng)理和現(xiàn)場可靠性工程師（SREs）的支持扎瓶。似乎至少有一些做法對維持谷歌的創(chuàng)新文化很重要所踊。

??谷歌在工程中有少量不同的角色。在每個角色中概荷，都可能有職業(yè)發(fā)展秕岛，有一系列的級別，以及晉升（與薪酬相關(guān)的改進(jìn)误证，如薪水）的可能性继薛，以表彰下一級別的表現(xiàn)。

??主要角色如下：

• 工程經(jīng)理

  這是列表中唯一的人員管理角色愈捅。軟件工程師等其他角色的個人可以管理人員遏考，但工程經(jīng)理總是管理人員。工程經(jīng)理通常是以前的軟件工程師蓝谨，并且總是擁有相當(dāng)多的技術(shù)專長和人際技巧灌具。

  技術(shù)領(lǐng)導(dǎo)和人員管理是有區(qū)別的。工程經(jīng)理不一定領(lǐng)導(dǎo)一個項目譬巫；項目由技術(shù)主管領(lǐng)導(dǎo)咖楣，他可能是工程經(jīng)理，但經(jīng)常是軟件工程師芦昔。項目的技術(shù)主管對該項目的技術(shù)決策有最終決定權(quán)诱贿。

  經(jīng)理們負(fù)責(zé)選擇技術(shù)主管，以及對他們團(tuán)隊的表現(xiàn)負(fù)責(zé)烟零。他們對職業(yè)發(fā)展進(jìn)行指導(dǎo)和協(xié)助瘪松，進(jìn)行績效評估（使用來自同行反饋的意見，見下文）锨阿，并負(fù)責(zé)薪酬的某些方面宵睦。他們還負(fù)責(zé)招聘流程的某些部分。

  工程經(jīng)理通常直接管理3至30人墅诡，但最常見的是8至12人壳嚎。

• 軟件工程師（SWE）

  大多數(shù)從事軟件開發(fā)工作的人都有這個角色桐智。谷歌招聘軟件工程師的門檻很高；通過雇傭非常優(yōu)秀的軟件工程師烟馅，能避免或最小化許多困擾組織的軟件問題说庭。

  Google在工程和管理方面有不同的職業(yè)發(fā)展順序。 雖然軟件工程師可以管理人員郑趁，或轉(zhuǎn)換到工程經(jīng)理的角色刊驴，但是管理人員并不是晉升的必要條件，即使是在最高級別寡润。 在更高層次上捆憎，展示領(lǐng)導(dǎo)力是必要的，但這可以有多種形式梭纹。 例如躲惰，創(chuàng)建具有巨大影響力或被許多其他工程師使用的優(yōu)秀軟件就足夠了。 這很重要变抽，因為這意味著那些擁有出色技術(shù)技能但缺乏管理人員的愿望或技能的人仍然擁有良好的職業(yè)發(fā)展道路础拨，而不需要他們走上管理的道路。 這避免了一些組織所面臨的問題绍载，即人們最終因為職業(yè)發(fā)展的原因而進(jìn)入管理崗位诡宗，而忽視了團(tuán)隊中人員的人事管理。

• 研究科學(xué)家

  這個角色的招聘標(biāo)準(zhǔn)是非常嚴(yán)格的逛钻，并且門檻非常高僚焦，要求展示出卓越的研究能力，這可以通過出色的出版記錄和編寫代碼的能力得到證明曙痘。學(xué)術(shù)界許多能夠獲得軟件工程師資格的非常有才能的人不具備在谷歌擔(dān)任研究科學(xué)家職位的資格；大多數(shù)擁有博士學(xué)位的人都是軟件工程師立肘，而不是研究科學(xué)家边坤。研究科學(xué)家對他們包括出版物在內(nèi)的研究貢獻(xiàn)進(jìn)行了評估，但除以上所訴和不同的頭銜外谅年，軟件工程師和研究科學(xué)家在谷歌的角色之間并沒有太大的區(qū)別茧痒。兩者都可以做原創(chuàng)研究和發(fā)表論文，既可以開發(fā)新產(chǎn)品理念和新技術(shù)融蹂，也可以編寫代碼和開發(fā)產(chǎn)品旺订。 谷歌的研究科學(xué)家通常與軟件工程師一起在相同的團(tuán)隊中工作，并從事相同的產(chǎn)品或相同的研究超燃。這種將研究嵌入工程中的做法有助于將新的研究輕松地結(jié)合到到運輸產(chǎn)品中区拳。

• 網(wǎng)站可靠性工程師（SRE）

  操作系統(tǒng)的維護(hù)由軟件工程團(tuán)隊完成，而不是傳統(tǒng)的系統(tǒng)管理員意乓，但SRE的招聘要求與軟件工師職位的要求略有不同（如果有其他專業(yè)知識技能樱调，如網(wǎng)絡(luò)或unix系統(tǒng)作為彌補，軟件工程技能要求可能略低）。SRE角色的性質(zhì)和目的在SRE書中解釋的非常詳細(xì)[7]笆凌，因此我們不在此進(jìn)一步討論圣猎。

• 產(chǎn)品經(jīng)理

  產(chǎn)品經(jīng)理負(fù)責(zé)產(chǎn)品的管理；作為產(chǎn)品用戶的倡導(dǎo)者乞而，他們協(xié)調(diào)軟件工程師的工作送悔，向用戶宣傳重要的特性，與其他團(tuán)隊協(xié)調(diào)爪模，跟蹤bug和時間表欠啤，確保生產(chǎn)高質(zhì)量產(chǎn)品所需的一切。產(chǎn)品經(jīng)理通常不會自己編寫代碼呻右，而是與軟件工程師合作以確保編寫正確的代碼跪妥。

• 項目集經(jīng)理/技術(shù)項目經(jīng)理

  項目集經(jīng)理的角色和產(chǎn)品經(jīng)理大致相似，但他們管理的不是產(chǎn)品声滥，而是項目眉撵、過程或操作（例如數(shù)據(jù)收集）。技術(shù)項目經(jīng)理是類似的落塑，但也需要與他們的工作相關(guān)的專門技術(shù)知識纽疟，例如用于處理語音的語言學(xué)。

  軟件工程師與產(chǎn)品經(jīng)理和項目集經(jīng)理的比例因組織而異憾赁，但通常很高污朽，例如在4：1到30：1的范圍內(nèi)。

4.2 設(shè)施

??谷歌以其有趣的設(shè)施而聞名龙考，其中包括滑梯蟆肆，球坑和游戲室。 這有助于吸引和留住優(yōu)秀人才晦款。谷歌很棒的咖啡館對員工免費提供炎功，辦公室也提供這個功能（即免費咖啡）從而巧妙地鼓勵員工留在辦公室；饑餓絕不是離開的理由缓溅。隨處可見得“微型廚房”也有相同的作用蛇损，員工可以在那獲取零食和飲料，它們也充當(dāng)了非正式想法交流的一個重要來源坛怪，因為很多對話都是從那里開始的淤齐。健身房、運動和現(xiàn)場按摩有助于員工保持舒適袜匿、健康和快樂更啄，從而提高生工作效率和記憶力。

??谷歌的座位是開放式的沉帮，通常相當(dāng)密集锈死。雖然存在爭議[20]贫堰，有時以犧牲個人注意力為代價，但它鼓勵交流而且經(jīng)濟(jì)待牵。

??員工被分配了一個單獨的座位其屏，但是會經(jīng)常換座（例如，每6-12個月缨该，通常是組織擴(kuò)展的結(jié)果）偎行，由經(jīng)理選擇座位使得促進(jìn)和鼓勵相鄰或接近相鄰的個人之間的交流更加容易。

??谷歌配備了最先進(jìn)視頻會議設(shè)施的會議室贰拿，只需輕輕一按即可連接到另一方進(jìn)行預(yù)先安排的議事日程邀請蛤袒。

4.3. 培訓(xùn)

??谷歌通過多種方式鼓勵員工接受教育：

• 新員工（“Nooglers”）有一個強制性的初始培訓(xùn)課程。
• 技術(shù)人員（SWEs和研究科學(xué)家）從做“Codelabs”開始：短期的個人技術(shù)在線培訓(xùn)課程膨更，以及編碼練習(xí)妙真。
• 谷歌提供員工各種網(wǎng)絡(luò)和面對面的培訓(xùn)課程。
• 谷歌也為在外部機(jī)構(gòu)學(xué)習(xí)提供支持荚守。

??此外珍德，每個Noogler通常都被指定一個官方的“導(dǎo)師”和一個單獨的“伙伴”來幫助他們跟上進(jìn)度。非正式的指導(dǎo)還通過與經(jīng)理的定期會議矗漾、團(tuán)隊會議锈候、代碼評審、設(shè)計評審和非正式過程來進(jìn)行敞贡。

4.4. 調(diào)動

??鼓勵公司不同部門之間的人員調(diào)動泵琳，以幫助在整個組織內(nèi)傳播知識和技術(shù)，并改善跨組織的溝通誊役。在一個職位上工作了12個月的員工可以在項目和/或辦公室之間進(jìn)行調(diào)動获列。軟件工程師也被鼓勵在組織的其他部分做臨時任務(wù)，例如 在SRE（現(xiàn)場可靠性工程）中進(jìn)行為期六個月的“輪換”（臨時任務(wù)）蛔垢。

4.5. 績效考核和獎勵

??谷歌非常鼓勵反饋蛛倦。工程師可以通過“同行獎金”和“榮譽”給予彼此明確的積極反饋。 任何員工都可以提名任何其他員工獲得“同行獎金” ——現(xiàn)金獎勵100美元——每年最多兩次啦桌，獎勵超出正常的任務(wù)范圍的工作，只需填寫網(wǎng)絡(luò)表格來描述理由及皂。當(dāng)獲得同行獎勵時甫男，通常也會通知團(tuán)隊成員。員工也可以給予“榮譽”验烧，即正式的表揚聲明板驳，為良好的工作提供明確的社群認(rèn)可，但沒有資金獎勵; 對于“榮譽”而言碍拆，并不要求工作超出正常的任務(wù)范圍若治，也不限制他們可以獲得的次數(shù)慨蓝。

??經(jīng)理還可以發(fā)放獎金，包括項目完成時的獎金端幼。和許多公司一樣礼烈，谷歌的員工會根據(jù)自己的表現(xiàn)獲得年度績效獎金和股權(quán)獎勵。

??谷歌有一個非常細(xì)致的晉升過程婆跑，包括自我提名或經(jīng)理提名此熬，自我審查，同行審查滑进，經(jīng)理評估犀忱；隨后，晉升委員會根據(jù)這些意見做出實際決定扶关，其結(jié)果可由晉升審查委員會進(jìn)一步審查阴汇。確保合適的人員獲得晉升對于維持對員工的正確激勵至關(guān)重要。

??另一方面节槐，績效不佳則由經(jīng)理反饋處理搀庶，必要時還會采取績效改進(jìn)計劃，其中包括制定非常明確的具體績效目標(biāo)和評估實現(xiàn)這些目標(biāo)的進(jìn)展疯淫。如果失敗地来，員工可能會因表現(xiàn)不佳而被解約，但實際上這在谷歌極其罕見熙掺。

??通過反饋調(diào)查評估經(jīng)理的績效; 每位員工被要求每年填寫兩次關(guān)于其經(jīng)理績效的匿名調(diào)查未斑，然后把調(diào)查結(jié)果匯總給經(jīng)理。這種向上反饋對于維護(hù)和提高整個組織的管理質(zhì)量是非常重要的币绩。

5.結(jié)論

??我們簡要介紹了谷歌過去的大多數(shù)關(guān)鍵軟件工程實踐蜡秽。當(dāng)然，谷歌現(xiàn)在是一個龐大而多樣化的組織缆镣，組織的某些部分有不同的做法芽突。但是谷歌的大多數(shù)團(tuán)隊通常會遵循此處描述的做法。

??由于涉及許多不同的軟件工程實踐董瞻，以及與我們的軟件工程實踐無關(guān)的谷歌成功的其他許多原因，因此很難提供任何定量或客觀證據(jù)來將個別實踐與改進(jìn)的結(jié)果聯(lián)系起來挟秤。 然而抄伍，這些實踐在谷歌經(jīng)受了時間的考驗艘刚，受到數(shù)千名優(yōu)秀軟件工程師的集體主觀判斷。

??對于其他組織中那些主張使用本文中描述的特定實踐的人來說攀甚，也許會說“這對谷歌來說已經(jīng)足夠好了”。

致謝

??特別感謝Alan Donovan的非常詳細(xì)和建設(shè)性的反饋秋度，并感謝Y aroslav Volovich炸庞，UrsH?lzle，Brian Strope燕雁，Alexander Gutkin拐格，Alex Gruenstein和Hameed Husaini對本文早期草稿的非常有益的評論刑赶。

參考文獻(xiàn)

[1] Build in the Cloud: Accessing Source Code , Nathan York,
http://google-engtools.blogspot.com/2011/06/build-in-cloud-accessing-source-code.html
[2] Build in the Cloud: How the Build System works , Christian Kemper,
http://google-engtools.blogspot.com/2011/08/build-in-cloud-how-build-system-works.htm
[3] Build in the Cloud: Distributing Build Steps, Nathan York
http://google-engtools.blogspot.com/2011/09/build-in-cloud-distributing-build-steps.html
[4] Build in the Cloud: Distributing Build Outputs, Milos Besta, Yevgeniy Miretskiy 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, June 2011.
http://google-engtools.blogspot.com/2011/06/testing-at-speed-and-scale-of-google.html
[6] Building Software at Google Scale Tech Talk, Michael Barnathan, Greg Estren, Pepper
Lebeck-Jone, Google tech talk.
http://www.youtube.com/watch?v=2qv3fcXW1mg
[7] Site Reliability Engineering , Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy,
O'Reilly Media, April 2016, ISBN 978-1-4919-2909-4.
https://landing.google.com/sre/book.html
[8] How Google Works, Eric Schmidt, Jonathan Rosenberg.
http://www.howgoogleworks.net
[9] What would Google Do?: Reverse-Engineering the Fastest Growing Company in the History
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] The Search: How Google and Its Rivals Rewrote the Rules of Business and Transformed
Our Culture , John Battelle, 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] Searching for Build Debt: Experiences Managing Technical Debt at Google, J. David
Morgenthaler, Misha Gridnev, 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, and J. 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 (ICSE ’12) , IEEE, 2012, pp.
1281–1284.
http://www.hyrumwright.org/papers/icse2012.pdf
[16] Large-Scale Automated Refactoring Using ClangMR , H. K. Wright, D. Jasper, M. Klimek, C.
Carruth, Z. Wan, in Proceedings of the 29th International Conference on Software Maintenance
(ICSM ’13) , IEEE, 2013, pp. 548–551.
[17] Why Google Stores Billions of Lines of Code in a Single Repository , Rachel Potvin,
presentation.
https://www.youtube.com/watch?v=W71BTkUbdqE
[18] The Motivation for a Monolithic Codebase , Rachel Potvin, Josh Levenberg, to be published
in Communications of the ACM, July 2016.
[19] Scaling Mercurial at Facebook, Durham Goode, Siddharth P. Agarwa, Facebook blog post,
January 7th, 2014.
https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook/
[20] Why We (Still) Believe In Private Offices , David Fullerton, Stack Overflow blog 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-03-24%20Continuous%20Integration%20at%20Google%20Scale.pdf

翻譯：安昕瑜 蔡新宇 孔慶振