3 項(xiàng)目管理

3.1 20%時(shí)間

Google允許員工花費(fèi)20%的時(shí)間去做他們選擇的任何項(xiàng)目，而無(wú)需經(jīng)過(guò)他們主管或其他人的允許。這對(duì)獲得工程師的信任極其重要，有如下幾點(diǎn)原因。第一，它允許任何有好想法的人，即使他的想法在其他人看來(lái)目前并不是有價(jià)值，可以有足夠的時(shí)間去開(kāi)發(fā)一個(gè)原型、示例或者演示去展示他們想法的價(jià)值。第二，他提供了管理上的透明性，否則員工會(huì)隱藏這類活動(dòng)，在其他沒(méi)有正式政策允許20%時(shí)間的公司，員工有時(shí)會(huì)從事“地下工作“項(xiàng)目而不會(huì)讓主管知道。如果工程師對(duì)這些項(xiàng)目持開(kāi)放態(tài)度，這樣會(huì)好很多，即使他們的主管并不認(rèn)同該項(xiàng)目的價(jià)值，也可在日常狀態(tài)更新時(shí)描述他們?cè)谶@些項(xiàng)目上做的工作。在全公司范圍內(nèi)有正式的這樣一個(gè)政策和文化，使得這成為可能。第三，允許工程師在更加有趣的工作上花費(fèi)一小部分時(shí)間，可以使工程師保持主動(dòng)和興奮，避免他們變的疲憊不堪，特別是員工感覺(jué)被迫花費(fèi)100%的時(shí)間在繁瑣的工作任務(wù)上的疲憊。擁有高效生產(chǎn)力、熱愛(ài)工作、充滿動(dòng)力的工程師和疲憊不堪的工程師之間的差距遠(yuǎn)遠(yuǎn)大于20%。第四，它鼓勵(lì)創(chuàng)新文化，看到其他工程師在20%時(shí)間做好玩的實(shí)驗(yàn)項(xiàng)目會(huì)鼓勵(lì)每個(gè)人都這么去做。

3.2 目標(biāo)和關(guān)鍵結(jié)果(OKRs)

Google要求個(gè)人和團(tuán)隊(duì)都要明確文檔化他們的目標(biāo)和評(píng)估達(dá)成這些目標(biāo)的進(jìn)度。團(tuán)隊(duì)設(shè)定季度和年度目標(biāo)，并給出可量化的關(guān)鍵結(jié)果以顯示目標(biāo)進(jìn)度。這在全公司各個(gè)層面上展開(kāi)，直至整個(gè)公司的目標(biāo)。個(gè)人和小團(tuán)隊(duì)的目標(biāo)要和他們所屬大團(tuán)隊(duì)或整個(gè)公司的更高層次的目標(biāo)一致。在每個(gè)季度末，會(huì)記錄每個(gè)可量化關(guān)鍵結(jié)果的進(jìn)度，每個(gè)目標(biāo)都會(huì)給出一個(gè)0.0（零進(jìn)度）到1.0（100%完成）的打分。OKR和OKR的打分通常是全公司可見(jiàn)的（特別敏感如高度機(jī)密的項(xiàng)目是少數(shù)例外），但是打分并不是用于員工的個(gè)人績(jī)效評(píng)定。
OKR應(yīng)該設(shè)定較高的目標(biāo)，理想的目標(biāo)是總體平均完成度在65%，這意味著鼓勵(lì)團(tuán)隊(duì)設(shè)定比他們可能完成工作量多大概50%的目標(biāo)。如果一個(gè)團(tuán)隊(duì)的得分比0.65高很多，鼓勵(lì)他們?cè)诮酉聛?lái)的一個(gè)季度中設(shè)立更高的OKRs（相反的，如果得分比0.65低很多，則鼓勵(lì)他們?cè)谙聜€(gè)季度設(shè)立相對(duì)保守的OKRs）。
OKRs提供了溝通公司各個(gè)部分工作的關(guān)鍵機(jī)制，并通過(guò)溝通激勵(lì)、鼓勵(lì)員工創(chuàng)造好的績(jī)效。即使OKRs并不影響績(jī)效評(píng)估或報(bào)酬，當(dāng)工程師知道自己的團(tuán)隊(duì)有OKR打分的會(huì)議，也會(huì)自然驅(qū)動(dòng)他把該分提高。定義關(guān)鍵結(jié)果的目標(biāo)和可量化性有助于確保員工做真正對(duì)目標(biāo)有可量化影響的工作。

3.3 項(xiàng)目批準(zhǔn)

雖然Google有完善的發(fā)行批準(zhǔn)過(guò)程，但是卻沒(méi)有一個(gè)完善的項(xiàng)目立項(xiàng)或取消的過(guò)程。盡管我已經(jīng)在Google工作了十年，目前也成為了一名管理者，但是我仍然不完全理解項(xiàng)目決策是根據(jù)什么做決定。部分原因是全公司也沒(méi)有一個(gè)統(tǒng)一的規(guī)范。各個(gè)職級(jí)的管理者對(duì)他們團(tuán)隊(duì)要做的項(xiàng)目負(fù)責(zé)，并根據(jù)他們的判斷進(jìn)行他們認(rèn)為合適的項(xiàng)目。在一些情況下，這意味著許多決定都是自底向上建立的，因?yàn)楣こ處煴怀浞纸o予了在他們的團(tuán)隊(duì)內(nèi)自由選擇項(xiàng)目的自由。在另一些情況下，決定是自頂向下建立的，由管理層或者管理者決策進(jìn)行哪些項(xiàng)目，給哪些額外的資源，哪些項(xiàng)目要被取消。

3.4 組織重組

有時(shí)當(dāng)管理層決定要取消一個(gè)大的項(xiàng)目時(shí)，這時(shí)在該項(xiàng)目工作的許多工程師要在新的團(tuán)隊(duì)尋找新的項(xiàng)目。同樣，有時(shí)要進(jìn)行資源“整合”，即將分散多個(gè)地區(qū)的的項(xiàng)目整合在幾個(gè)少數(shù)地區(qū)，這時(shí)為促成整合，其他地區(qū)的工程師也要改變團(tuán)隊(duì)和項(xiàng)目。在這種的情況下，通常讓工程師在他們地區(qū)可選范圍內(nèi)自由選擇團(tuán)隊(duì)和角色，或者在“整合”的情況下，他們也可以選擇更換辦公地點(diǎn)從而繼續(xù)留在原來(lái)的團(tuán)隊(duì)。
除此之外，其他形式的公司重組，例如合并或分解團(tuán)隊(duì)，改變匯報(bào)線等，在Google都很常見(jiàn)，盡管我不知道Google和其他的大公司相比算不算多。在一個(gè)技術(shù)驅(qū)動(dòng)的大公司，一定程度上的頻繁重組是必要的，可以避免因技術(shù)和需求改變時(shí)導(dǎo)致的組織低效。

3.5 年度的Hack 周

另一種在google被激勵(lì)的文化是“黑客馬拉松”活動(dòng)。在許多的google的辦公室中，軟件工程師每周花時(shí)間以這種例行的黑客活動(dòng)來(lái)工作于創(chuàng)新型的項(xiàng)目上。在啟動(dòng)會(huì)后，人們各抒己見(jiàn)，形成小的團(tuán)隊(duì)，在新的想法的基礎(chǔ)上構(gòu)建一個(gè)demo或原型，在周末結(jié)束時(shí)展示他們的demo給觀眾和評(píng)委，評(píng)委給出小小的獎(jiǎng)勵(lì)給最佳的項(xiàng)目。 最大的獎(jiǎng)勵(lì)，其實(shí)是認(rèn)可度、認(rèn)同感-一種可以從成功的黑客馬拉松項(xiàng)目孵化成真正的真實(shí)項(xiàng)目的希望。
盡管所有的工程師被允許或被引導(dǎo)可以參加這樣的“黑客馬拉松”活動(dòng)，但許多工程師發(fā)現(xiàn)把他們?nèi)諒?fù)一日的工作從中剝離出來(lái)還是有困難的，所以參與率通常是相當(dāng)?shù)牡?#xff08;在5%-20%），盡管許多人有意愿參加了啟動(dòng)會(huì)或最終的展示會(huì)并且也被好的靈感所激勵(lì)。

4 人員管理

4.1 角色

如下文所述，Google區(qū)分了工程師和管理者的職業(yè)發(fā)展階梯，將技術(shù)主管從管理者中區(qū)分開(kāi)來(lái)，將研究并入工程師，并通過(guò)產(chǎn)品經(jīng)理、項(xiàng)目經(jīng)理和網(wǎng)站可靠性工程師（site reliability engineers, SREs)支持工程師的工作。目前看來(lái)，至少其中的一些實(shí)踐對(duì)于維持Google已經(jīng)發(fā)展的創(chuàng)新文化至關(guān)重要。
Google工程師僅有少數(shù)的角色。在每個(gè)角色內(nèi)，都有職業(yè)進(jìn)一步發(fā)展的機(jī)會(huì)，其通過(guò)一系列的等級(jí)和晉升機(jī)會(huì)（有相應(yīng)的報(bào)酬如薪金等的提高）以認(rèn)可下一級(jí)別的表現(xiàn)。
主要的角色有：
工程師主管
這是這個(gè)列表中唯一的管理者角色。其他的角色的個(gè)人如軟件工程師可能也管理人，但是工程師主管一定管理人。工程師主管通常在早期也是軟件工程師，并是全面的技術(shù)專家，有卓越的個(gè)人技能。
技術(shù)主管和管理者有一個(gè)主要區(qū)別。
工程師主管并不一定要領(lǐng)導(dǎo)項(xiàng)目。項(xiàng)目通過(guò)技術(shù)主管領(lǐng)導(dǎo)，其可以是一名工程師主管，但更常見(jiàn)的是軟件工程師。項(xiàng)目的技術(shù)主管有該項(xiàng)目的技術(shù)決策的發(fā)言權(quán)。

工程師主管的責(zé)任是選擇技術(shù)主管，并負(fù)責(zé)他們團(tuán)隊(duì)的績(jī)效。他們指導(dǎo)和協(xié)助職業(yè)發(fā)展，進(jìn)行績(jī)效評(píng)估（使用同事反饋），并在一定層面上負(fù)責(zé)薪酬，也在負(fù)責(zé)招聘中的一部分。
工程師主管一般直接管理任意地點(diǎn)的3到30個(gè)人，但8～12個(gè)更為常見(jiàn)。
軟件工程師（Software Engineer , SWE)
從事軟件工程開(kāi)發(fā)工作的大多數(shù)人都是這個(gè)角色。Google招聘軟件工程師的門檻非常高。僅招聘最一流的軟件工程師，可以使許多在其他公司如瘟疫般的軟件問(wèn)題，在Google都盡可能的避免或者縮小。
Google區(qū)分工程師和管理者的職業(yè)發(fā)展序列。盡管一個(gè)工程師可以從事管理工作或者轉(zhuǎn)崗到一個(gè)工程師主管職位，但是對(duì)于晉升來(lái)講，管理才能不是必須的，即使是在非常高的級(jí)別。高級(jí)別的工程師職位需要有一定的領(lǐng)導(dǎo)能力，但它可以有多種形式，例如創(chuàng)造了產(chǎn)生了巨大的影響或者被很多其他工程師使用的軟件，對(duì)晉升來(lái)講就足夠了。這非常重要，因?yàn)樗馕吨?#xff0c;對(duì)于擁有卓越技術(shù)能力但缺乏管理欲望和技巧的人仍然可以有很好的職業(yè)發(fā)展，并不一定要求這類人走管理者的發(fā)展道路。這避免了在其他組織中身處于管理職位，卻忽視團(tuán)隊(duì)管理，從而失去上升空間的工程師的痛楚。
研究科學(xué)家
該角色的招聘標(biāo)準(zhǔn)非常嚴(yán)格，招聘的門檻極其的高，要求已有一系列的發(fā)表文章記錄以證明其出色的研究能力，并要求寫代碼的能力。許多在學(xué)術(shù)屆非常有才華的人，他們或許有能力符合Google軟件工程師的角色，但不一定符合研究科學(xué)家的角色。在Google，大多數(shù)博士都是軟件工程師而非研究科學(xué)家。研究科學(xué)家通過(guò)其研究貢獻(xiàn)包括文章發(fā)表等評(píng)定，但除了頭銜之外，Google的軟件工程師和研究科學(xué)家并無(wú)太大的區(qū)別。他們都可以做原始的研究并發(fā)表論文，都可以貢獻(xiàn)新的產(chǎn)品想法和新的技術(shù)，都可以寫代碼開(kāi)發(fā)產(chǎn)品。在Google，研究科學(xué)家和軟件工程師在一起工作，即在相同的團(tuán)隊(duì)做相同的產(chǎn)品或者研究。將研究科學(xué)家嵌入到工程師中對(duì)在將發(fā)布的產(chǎn)品中融入新研究成果影響巨大。
網(wǎng)站可靠性工程師 (SRE)
系統(tǒng)的運(yùn)維由軟件工程師團(tuán)隊(duì)負(fù)責(zé)，而非傳統(tǒng)的系統(tǒng)管理員。但SRE的招聘需求和其他軟件工程師職位略有不同（如果有非常專業(yè)的其他技術(shù)如網(wǎng)絡(luò)或unix系統(tǒng)管理等彌補(bǔ)，軟件工程師相關(guān)的技巧可以稍微降低一些）。SRE角色的性質(zhì)和角色在SRE的書(shū)[7]中已經(jīng)很好很仔細(xì)的解釋了，這里我們就不繼續(xù)討論了。
產(chǎn)品經(jīng)理
產(chǎn)品經(jīng)理負(fù)責(zé)產(chǎn)品的管理。作為產(chǎn)品用戶的代理人，他協(xié)調(diào)工程師的工作，宣傳對(duì)用戶重要的新產(chǎn)品特性，協(xié)調(diào)與其他團(tuán)隊(duì)的溝通，跟蹤bug和協(xié)調(diào)時(shí)間，并確保一個(gè)高質(zhì)量的產(chǎn)品所需的所有資源一切就緒。產(chǎn)品經(jīng)理通常并不親自寫代碼，但是會(huì)和軟件工程師一起工作以確保寫出適合產(chǎn)品的代碼。
項(xiàng)目經(jīng)理/技術(shù)項(xiàng)目經(jīng)理
項(xiàng)目經(jīng)理和產(chǎn)品經(jīng)理的角色大致相同，但并不管理一個(gè)產(chǎn)品，而是管理項(xiàng)目、流程和操作（例如數(shù)據(jù)采集）。技術(shù)項(xiàng)目經(jīng)理也類似，但是需要和他們工作相關(guān)的特定的技術(shù)專長(zhǎng)，例如處理語(yǔ)音數(shù)據(jù)的語(yǔ)言學(xué)知識(shí)。

軟件工程師與產(chǎn)品經(jīng)理和項(xiàng)目經(jīng)理的比例在公司不同團(tuán)隊(duì)中各有不同，但一般來(lái)講，該比例是比較高的，一般在4:1到30:1之間。

4.2 設(shè)施

Google因其有趣的設(shè)施而出名，如滑滑梯，球球堆和游戲室，它有助于吸引和保留人才。Google一流的咖啡免費(fèi)向員工開(kāi)放，這也有相似的功能，并且巧妙的鼓勵(lì)員工留在辦公室，饑餓從來(lái)不是離開(kāi)的理由。員工們更常去的地方“微廚房“，可以拿零食和飲料，也有同樣的功能，并且這里還成為一個(gè)重要的非正式的交換想法的地點(diǎn)，許多聊天都始于這個(gè)地方。健身房、運(yùn)動(dòng)、和便利的按摩椅幫助員工保持健康快樂(lè)，也提高了生產(chǎn)力和保留率。
Google的工位是開(kāi)放空間的，并且通常是密集的。盡管有爭(zhēng)議，但這鼓勵(lì)了溝通（盡管有時(shí)以分散個(gè)人的注意力為代價(jià)），也很經(jīng)濟(jì)。
員工會(huì)分配了一個(gè)獨(dú)立的工位，但是工位重新分配相當(dāng)頻繁（如6～12月，通常是組織擴(kuò)張的結(jié)果），主管會(huì)重新安排座位以便利和促進(jìn)溝通，這通常對(duì)工位臨近的或相對(duì)比較近的人是比較容易的。
Google的設(shè)施中均有擁有一流的視頻會(huì)議設(shè)備的會(huì)議室，和其他組織的開(kāi)會(huì)僅需點(diǎn)擊接入屏幕上的一個(gè)預(yù)先組織好的會(huì)議邀請(qǐng)即可。

4.3 培訓(xùn)

Google通過(guò)多種方式鼓勵(lì)員工教育。
Google新員工（“Nooglers”)有強(qiáng)制的入職培訓(xùn)。
技術(shù)類員工（SWE和研究科學(xué)家）從完成“Codelabs”訓(xùn)練開(kāi)始：短時(shí)間的關(guān)于個(gè)人技術(shù)的編碼在線培訓(xùn)課程。
Google提供一系列的在線和線下培訓(xùn)課程。
Google也提供在外部機(jī)構(gòu)學(xué)習(xí)的支持。
除此之外，通常都會(huì)為每個(gè)"Noogler"分配一個(gè)正式的導(dǎo)師(Mentor) 和獨(dú)立的伙伴(Buddy)以幫助他們更快的適應(yīng)。非正式的指導(dǎo)也發(fā)生在和主管的例會(huì)、團(tuán)隊(duì)會(huì)議、代碼審查、設(shè)計(jì)審查和其他非正式的工作流程中。

4.4 轉(zhuǎn)崗

鼓勵(lì)在公司不同的部分之間轉(zhuǎn)崗，這有助于知識(shí)和技術(shù)整個(gè)公司傳播，提高跨組織溝通。在同一個(gè)崗位工作滿12個(gè)月后就可以在不同項(xiàng)目和辦公室間轉(zhuǎn)崗。鼓勵(lì)軟件工程師做其他組織內(nèi)的臨時(shí)性工作，例如SRE (Site Reliability Engineering，書(shū)名).中的六個(gè)月的“輪崗”(臨時(shí)工作）。

4.5 績(jī)效評(píng)定和獎(jiǎng)勵(lì)

Google非常鼓勵(lì)反饋。工程師可以通過(guò)“同事獎(jiǎng)金”(peer bonuses）和“勛章”（kudos）給其他人直接的積極評(píng)價(jià)。所有的員工都可以提名其他人獲取”同事獎(jiǎng)金“——100美金的現(xiàn)金獎(jiǎng)勵(lì)，每年最多兩次，以獎(jiǎng)勵(lì)其超額完成任務(wù)，僅需要通過(guò)網(wǎng)頁(yè)填寫并描述原因即可。通常當(dāng)獲得“同事獎(jiǎng)金”時(shí)，組內(nèi)同事們也會(huì)收到通知。員工也可以給其他人“勛章”，即正式聲明表?yè)P(yáng)，以期對(duì)他們出色工作的社會(huì)認(rèn)可，但是沒(méi)有經(jīng)濟(jì)上的回報(bào)?！皠渍隆睕](méi)有超額完成工作的限制，也沒(méi)授予次數(shù)的限制。

管理者也可以獎(jiǎng)勵(lì)獎(jiǎng)金，包括立即獎(jiǎng)金（例如完成了一個(gè)項(xiàng)目后）。和多數(shù)其他公司一樣，Google員工每年有績(jī)效獎(jiǎng)金，根據(jù)他們的績(jī)效公平的獎(jiǎng)勵(lì)。
Google有非常仔細(xì)、詳盡的晉升流程，晉升需要主管推薦或自我推薦、自我評(píng)價(jià)、同事評(píng)價(jià)、主管評(píng)估，最終由晉升委員會(huì)根據(jù)以上信息決策結(jié)果，結(jié)果可以由晉升上訴委員會(huì)進(jìn)一步審核。確保優(yōu)秀的員工獲得晉升對(duì)保持正確激勵(lì)機(jī)制至關(guān)重要。
另一方面，差的績(jī)效，根據(jù)主管的反饋處理，必要時(shí)制定績(jī)效提升計(jì)劃，績(jī)效提升計(jì)劃中設(shè)置了非常明確具體的績(jī)效目標(biāo)和如何評(píng)估達(dá)到該目標(biāo)的進(jìn)度。如果提升計(jì)劃失敗了，因?yàn)榭?jī)效差可能會(huì)被終止合同，但實(shí)際上，這樣的情況在Google非常罕見(jiàn)。
主管的績(jī)效通過(guò)反饋調(diào)查評(píng)定。要求每個(gè)員工一年填寫兩次對(duì)他們主管的績(jī)效的調(diào)查，結(jié)果會(huì)匿名收集并提供給主管。這種形式的向上反饋對(duì)提升整個(gè)公司的管理質(zhì)量非常重要。

5 總結(jié)

我們已經(jīng)簡(jiǎn)要地描述了Google的大多數(shù)核心軟件工程實(shí)踐經(jīng)驗(yàn)。當(dāng)然，Google現(xiàn)在已經(jīng)是一個(gè)體量巨大并且多樣化的公司，公司的一些部門可能有不同的實(shí)踐經(jīng)驗(yàn)。但是這里描述的是大多數(shù)團(tuán)隊(duì)目前遵循的實(shí)踐經(jīng)驗(yàn)。

有著大量軟件工程的實(shí)踐經(jīng)驗(yàn)，以及眾多與軟件工程實(shí)踐無(wú)關(guān)Google的制勝之道，想要客觀地定量地證明個(gè)人的實(shí)踐和提升結(jié)果之間關(guān)系非常困難。盡管如此，這些實(shí)踐經(jīng)驗(yàn)在Google都經(jīng)受住了時(shí)間的考驗(yàn)，經(jīng)受了成千上萬(wàn)的優(yōu)秀軟件工程師的集體主觀判斷。
對(duì)于其他的公司，假如他們所倡導(dǎo)的軟件工程實(shí)踐也在本文中有所描述，或許，這有助于說(shuō)明“這在Google已經(jīng)實(shí)踐證明足夠好了”。

致謝
特別感謝Alan Donovan的極其詳細(xì)和建設(shè)性的反饋，感謝Yaroslav Volovich、UrsHo?lzle、Brian Strope、Alexander Gutkin、Alex Gruenstein、Hameed Husaini在本文初稿時(shí)給出非常有用的評(píng)論意見(jià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&re dir_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%20Integr ation%20at%20Google%20Scale.pdf

總結(jié)

以上是生活随笔為你收集整理的Google软件工程（续）的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。