你將學(xué)習(xí)到軟件組織在設(shè)計(jì)、架構(gòu)、編寫(xiě)和維護(hù)代碼時(shí)應(yīng)牢記的三個(gè)基本原則：時(shí)間如何影響軟件的可持續(xù)性，以及如何使代碼隨著時(shí)間的推移而具有韌性。模如何影響工程組織內(nèi)軟件實(shí)踐的可行性。在評(píng)估設(shè)計(jì)和開(kāi)發(fā)決策時(shí)，一位典型的工程師需要做出哪些權(quán)衡。
這本書(shū)解釋了谷歌做軟件工程的方式，講述了需要考慮的各種權(quán)衡。
如今，軟件工程師不僅需要知道如何有效地編程，還需要知道如何發(fā)展適當(dāng)?shù)墓こ虒?shí)踐，以使代碼庫(kù)可持續(xù)且健康。這本書(shū)強(qiáng)調(diào)了編程和軟件工程之間的區(qū)別。
軟件工程師如何管理一個(gè)活躍的代碼庫(kù)，這個(gè)代碼庫(kù)在其生命周期里不斷響應(yīng)變化的需求，不斷地發(fā)展？軟件工程師Titus Winters和Hyrum Wright，攜手技術(shù)作家Tom Manshreck，基于他們?cè)诠雀璧慕?jīng)驗(yàn)，坦率而有見(jiàn)地的為大家介紹了的從業(yè)者是如何構(gòu)建和維護(hù)軟件的。
這本書(shū)解釋了谷歌做軟件工程的方式，這種方式讓我有很高的生產(chǎn)力，并且很快樂(lè)，同時(shí)本書(shū)也直言不諱的講述了需要考慮的各種權(quán)衡。
Eric Haugh
谷歌軟件工程師
前言
本書(shū)的書(shū)名是Google 軟件工程。軟件工程到底是什么意思？軟件工程與編程或計(jì)算機(jī)科學(xué)有什么區(qū)別？為什么谷歌會(huì)把自己對(duì)軟件工程獨(dú)特的觀點(diǎn)編寫(xiě)成一本書(shū)，在50 年軟件工程的歷史中留下這一筆？
術(shù)語(yǔ)編程和軟件工程在我們的行業(yè)中已經(jīng)交替使用了相當(dāng)長(zhǎng)的一段時(shí)間，盡管它們都有不同的重點(diǎn)和含義。大學(xué)生們傾向于學(xué)習(xí)計(jì)算機(jī)科學(xué)，并獲得以程序員的身份編寫(xiě)代碼的工作。
然而，軟件工程聽(tīng)起來(lái)更為嚴(yán)肅，似乎它意味著應(yīng)用一些理論知識(shí)來(lái)構(gòu)建真實(shí)而精確的東西。機(jī)械工程師、土木工程師、航空工程師和其他工程領(lǐng)域的工程師都從事工程實(shí)踐。他們都在現(xiàn)實(shí)世界中工作，運(yùn)用自己的理論知識(shí)創(chuàng)造出真實(shí)的東西。軟件工程師也創(chuàng)造真實(shí)的東西，盡管它相比其他工程師創(chuàng)造的東西來(lái)說(shuō)并沒(méi)那么實(shí)實(shí)在在。
與那些更成熟的工程專(zhuān)業(yè)不同，當(dāng)前的軟件工程理論或?qū)嵺`并沒(méi)有那么嚴(yán)格。航空工程師必須遵循嚴(yán)格的指導(dǎo)方針和實(shí)踐，因?yàn)樗麄冇?jì)算中的錯(cuò)誤會(huì)造成真實(shí)的損害�？傮w而言，編程在傳統(tǒng)上沒(méi)有遵循這樣嚴(yán)格的實(shí)踐。但是，隨著軟件越來(lái)越融入我們的生活，我們必須采用和依賴(lài)更嚴(yán)格的工程方法。我們希望本書(shū)能幫助其他人看到一條通向更可靠的軟件實(shí)踐的道路。
編程的時(shí)間性
我們認(rèn)為軟件工程不僅包括編寫(xiě)代碼的行為，還包括組織在一段時(shí)間內(nèi)用來(lái)構(gòu)建和維護(hù)代碼的所有工具和流程。一個(gè)軟件組織可以引入哪些實(shí)踐來(lái)限度地保持其代碼的長(zhǎng)期價(jià)值？工程師如何使代碼庫(kù)更具可持續(xù)性以及軟件工程學(xué)科本身更為嚴(yán)格？對(duì)于這些問(wèn)題，我們沒(méi)有基本的答案，但我們希望谷歌過(guò)去20 年的經(jīng)驗(yàn)?zāi)軌驗(yàn)槲覀冋业竭@些答案指明可能的道路。
我們?cè)谶@本書(shū)中分享的一個(gè)關(guān)鍵見(jiàn)解是，軟件工程可以被認(rèn)為是隨著時(shí)間而不斷集成的編程。我們可以為我們的代碼引入哪些實(shí)踐，使其在整個(gè)生命周期內(nèi)，從概念到上市、到維護(hù)、再到棄用，具有可持續(xù)性（能夠?qū)Ρ匾淖兏龀龇磻?yīng)）？這本書(shū)強(qiáng)調(diào)了我們認(rèn)為的軟件組織在設(shè)計(jì)、架構(gòu)和編寫(xiě)代碼時(shí)應(yīng)該牢記的三個(gè)基本原則：
時(shí)間與變化
代碼在其生命周期內(nèi)需要如何適應(yīng)。
規(guī)模與增長(zhǎng)
組織在發(fā)展過(guò)程中要如何適應(yīng)。
權(quán)衡與成本
組織如何從時(shí)間、變化、規(guī)模和增長(zhǎng)中所學(xué)到的經(jīng)驗(yàn)來(lái)做出決策。
貫穿所有章節(jié)，我們?cè)噲D圍繞這些主題，并指出這些原則是如何影響工程實(shí)踐的，并讓它們可持續(xù)的發(fā)展（完整討論見(jiàn)第1 章）。
谷歌的視角
鑒于我們的規(guī)模和歷史，谷歌對(duì)可持續(xù)軟件生態(tài)系統(tǒng)的增長(zhǎng)和演變有著獨(dú)特的視角。我們希望我們所吸取的經(jīng)驗(yàn)教訓(xùn)能對(duì)貴組織的發(fā)展和擁抱更多可持續(xù)性實(shí)踐有所幫助。
我們將本書(shū)的主題分為谷歌軟件工程領(lǐng)域的三個(gè)主要方面：
文化。
流程。
工具。
谷歌的文化是獨(dú)特的，但我們?cè)诎l(fā)展我們的工程文化中所吸取的教訓(xùn)是廣泛適用的。我們關(guān)于文化的章節(jié)（第二部分）強(qiáng)調(diào)了軟件開(kāi)發(fā)企業(yè)的集體性，軟件開(kāi)發(fā)是一種團(tuán)隊(duì)工作，恰當(dāng)?shù)奈幕瓌t對(duì)于一個(gè)組織的成長(zhǎng)和持續(xù)健康至關(guān)重要。
我們的流程章節(jié)（第三部分）中概述的技術(shù)對(duì)大多數(shù)軟件工程師來(lái)說(shuō)都很熟悉，但是谷歌龐大規(guī)模和多年積累的大型代碼庫(kù)為開(kāi)發(fā)實(shí)踐提供了一個(gè)更完整的壓力測(cè)試。在這些章節(jié)中，著重講述了我們發(fā)現(xiàn)隨著時(shí)間的推移以及規(guī)模的增長(zhǎng)而起作用的東西，并且也還有我們?nèi)匀粵](méi)有得到滿意答案的領(lǐng)域。
后，我們的工具章節(jié)（第四部分）說(shuō)明了我們?nèi)绾卫脤?duì)工具基礎(chǔ)設(shè)施的投資，來(lái)為日益增長(zhǎng)和老化的代碼庫(kù)帶來(lái)收益。在某些情況下，這些工具是谷歌特有的，盡管我們指出了開(kāi)源或第三方的替代方案（如果適用的話）。我們期望這些基本見(jiàn)解適用于大多數(shù)工程組織。
本書(shū)中概述的文化、流程和工具描述了典型的軟件工程師希望在工作中學(xué)到的經(jīng)驗(yàn)教訓(xùn)。當(dāng)然并不是只有谷歌才能提供好的建議，我們?cè)谶@里介紹的經(jīng)驗(yàn)不是要指示你的組織應(yīng)該做什么。本書(shū)是我們的觀點(diǎn)，我們希望你會(huì)發(fā)現(xiàn)它是有用的，不管直接采用這些經(jīng)驗(yàn)，還是在考慮自己的實(shí)踐時(shí)將它們作為出發(fā)點(diǎn)，專(zhuān)門(mén)針對(duì)自己的問(wèn)題領(lǐng)域進(jìn)行優(yōu)化。
這本書(shū)也不打算說(shuō)教。谷歌本身仍然沒(méi)有完美地應(yīng)用書(shū)中的許多概念。我們從失敗中吸取的教訓(xùn)是：我們?nèi)匀粫?huì)犯錯(cuò)誤，執(zhí)行不完美的解決方案，并且需要不斷改進(jìn)。然而，谷歌工程組織的龐大規(guī)模使得每個(gè)問(wèn)題都有多種解決方案。我們希望本書(shū)包含了其中的精華。
本書(shū)不包含的內(nèi)容
本書(shū)并不涵蓋軟件設(shè)計(jì)，這是一門(mén)需要獨(dú)立出書(shū)（并且已經(jīng)有很多內(nèi)容）的學(xué)科。盡管本書(shū)中有一些代碼用于說(shuō)明，但這些原則與編程語(yǔ)言無(wú)關(guān)，在這些章節(jié)中幾乎沒(méi)有實(shí)際的編程建議。因此，本文沒(méi)有涉及軟件開(kāi)發(fā)中的許多重要問(wèn)題：項(xiàng)目管理、API 設(shè)計(jì)、安全強(qiáng)化、國(guó)際化、用戶界面框架或其他特定編程語(yǔ)言的關(guān)注點(diǎn)。它們?cè)谶@本書(shū)中被遺漏并不意味著它們不重要。相反，我們選擇不在這里講述它們，是因?yàn)槲覀儫o(wú)法提供它們應(yīng)得的待遇。我們?cè)噲D使本書(shū)中的討論更多的是聚焦于工程，而不是編程。
臨別贈(zèng)言
這本書(shū)代表了所有貢獻(xiàn)者付出的努力和汗水，我們希望你能收到它：把它當(dāng)做一個(gè)了解大型軟件工程組織如何構(gòu)建其產(chǎn)品的窗口。我們也希望，這是眾多的聲音之一，有助于推動(dòng)我們的行業(yè)采取更具前瞻性的思維和可持續(xù)的實(shí)踐。重要的是，我們希望你喜歡這本書(shū)，并能從這本書(shū)中獲得你關(guān)心的觀點(diǎn)。
Tom Manshreck
內(nèi)容約定
本書(shū)采用以下排版約定：
斜體（Italic）
表示新術(shù)語(yǔ)、URL、電子郵件地址、文件名和擴(kuò)展名。
等寬字體（Constant width）
用于程序示例，以及段落中引用程序元素，如變量或函數(shù)名、數(shù)據(jù)庫(kù)、數(shù)據(jù)類(lèi)型、環(huán)境變量、語(yǔ)句和關(guān)鍵字。
等寬黑體（Constant width bold）
顯示用戶應(yīng)鍵入的命令或其他文本。
等寬斜體（Constant width italic）
顯示應(yīng)替換為用戶提供的或由上下文確定的值的文本。
OReilly 在線學(xué)習(xí)平臺(tái)（OReilly Online Learning）
近40 年來(lái)，OReilly Media 致力于提供技術(shù)和商業(yè)培訓(xùn)、知識(shí)和卓越見(jiàn)解，來(lái)幫助眾多公司取得成功。
我們有一群獨(dú)家專(zhuān)家和創(chuàng)新者，他們通過(guò)圖書(shū)、文章、會(huì)議和在線學(xué)習(xí)平臺(tái)分享知識(shí)和技術(shù)。OReilly 的在線學(xué)習(xí)平臺(tái)提供按需訪問(wèn)的直播培訓(xùn)課程、詳細(xì)的學(xué)習(xí)路徑、交互式編程環(huán)境，以及由OReilly 和其他200 多家出版社出版的書(shū)籍和視頻。
詳情請(qǐng)?jiān)L問(wèn)http://oreilly.com。
聯(lián)系我們
任何有關(guān)本書(shū)的意見(jiàn)或疑問(wèn)，請(qǐng)按照以下地址聯(lián)系出版社。
美國(guó)：
OReilly Media, Inc.
1005 Gravenstein Highway North
Sebastopol, CA 95472
中國(guó)：
北京市西城區(qū)西直門(mén)南大街2 號(hào)成銘大廈C 座807 室（100035）
奧萊利技術(shù)咨詢(xún)（北京）有限公司
我們有本書(shū)的專(zhuān)屬網(wǎng)頁(yè)，你可以在那兒找到本書(shū)的勘誤、示例和其他信息。網(wǎng)頁(yè)地址：https://oreil.ly/software-engineering-at-google。
如果你對(duì)本書(shū)有一些評(píng)論或技術(shù)上的建議，請(qǐng)發(fā)送電子郵件到 bookquestions@oreilly.com。
有關(guān)其他圖書(shū)、講座、會(huì)議、新聞的信息，請(qǐng)?jiān)L問(wèn)我們的網(wǎng)站：http://www.oreilly.com。
Facebook：http://facebook.com/oreilly。
Twitter：http://twitter.com/oreillymedia。
YouTube：http://www.youtube.com/oreillymedia。
致謝
沒(méi)有無(wú)數(shù)其他人的努力是不可能有這本書(shū)的。這本書(shū)中的知識(shí)都來(lái)自我們?cè)诠雀璧穆殬I(yè)生涯中許多其他人的經(jīng)驗(yàn)。我們是使者，他們來(lái)到我們面前，在谷歌和其他地方，教導(dǎo)我們現(xiàn)在呈現(xiàn)給你們的東西。我們不能在這里一一列舉，但衷心地向你們致謝。
我們還要感謝Melody Meckfessel 在項(xiàng)目初期的支持，以及Daniel Jasper 和Danny Berlin 在項(xiàng)目完成過(guò)程中的支持。
如果沒(méi)有策劃人、作者和編輯的大量合作是不可能有這本書(shū)的。盡管作者和編輯在每一章或標(biāo)注中都得到了明確的認(rèn)可，但我們還是希望再次感謝那些對(duì)每一章做出貢獻(xiàn)的人，他們?yōu)楸緯?shū)提供了深思熟慮的意見(jiàn)、討論和評(píng)審。
Tom Manshreck：感謝我的父母讓我相信自己，和我一起在餐桌旁完成工作。
Titus Winters：感謝父親，為我指明道路。感謝母親，傾聽(tīng)我的聲音。感謝Victoria 對(duì)我的支持。感謝Raf，做我的后盾。此外，還要感謝Snyder，Ranwa，Z，Mike，Zach，Tom ( 以及Payne 一家), mec，Toby，cgd 和Melody，感謝他們的教誨、指導(dǎo)和信任。
Hyrum Wright：感謝父親和母親的鼓勵(lì)。感謝Bryan 和Bakerland 公司，給了我次嘗試軟件的機(jī)會(huì)。感謝Dewayne，與我并肩作戰(zhàn)。感謝Hannah，Jonathan，Charlotte，Spencer 和Ben，感謝他們的愛(ài)和關(guān)注。感謝Heather 一路的陪伴。
作者介紹
Titus Winters，谷歌高級(jí)軟件工程師，他是谷歌C 代碼庫(kù)的領(lǐng)導(dǎo)者：2億5000萬(wàn)行代碼，每月成千上萬(wàn)名不同的工程師在這些代碼上工作。
Tom Manshreck，在谷歌軟件工程部擔(dān)任技術(shù)作家。他是C Library Team的成員，負(fù)責(zé)開(kāi)發(fā)文檔，開(kāi)展培訓(xùn)課程以及為Abseil，谷歌的開(kāi)源C 代碼，編寫(xiě)文檔。
Hyrum Wright是谷歌的一名軟件工程師，他領(lǐng)導(dǎo)著谷歌自動(dòng)化變更工具團(tuán)隊(duì)。Hyrum對(duì)谷歌代碼庫(kù)的編輯比公司歷史上任何其他工程師都要多。
譯者介紹
陳軍，江湖稱(chēng)號(hào)軍少，深圳敏捷社區(qū)發(fā)起人，騰訊T12工程效能專(zhuān)家，現(xiàn)主要從事研發(fā)效能提升工作，多年軟件工程方法和技術(shù)實(shí)踐經(jīng)驗(yàn)。
周代兵，華為軟件工程專(zhuān)家，有多年輔導(dǎo)團(tuán)隊(duì)?wèi)?yīng)用軟件工程方法和技術(shù)提升研發(fā)能力實(shí)踐經(jīng)驗(yàn)。
邱棟，東南大學(xué)軟件工程博士，華為軟件工程技術(shù)專(zhuān)家，有多年軟件工程技術(shù)研究和實(shí)踐經(jīng)驗(yàn)，研究方向包括軟件架構(gòu)分析與評(píng)估，智能化軟件工程等。
目錄
序 1
前言 3
部分 理論
第1 章 什么是軟件工程 13
時(shí)間與變化 15
海勒姆定律18
案例：哈希排序 18
為什么目標(biāo)不是沒(méi)有變化呢 20
規(guī)模與效率 21
阻礙規(guī)�；恼� 22
促進(jìn)規(guī)�；恼� 24
案例：編譯器升級(jí) 24
左移思想 26
權(quán)衡與成本 28
案例：白板筆 29
決策投入 30
案例：分布式構(gòu)建 30
案例：時(shí)間與規(guī)模的博弈 32
數(shù)據(jù)驅(qū)動(dòng)的決策 32
軟件工程VS 編程 33
小結(jié) 34
本章要點(diǎn) 34
第二部分 文化
第2 章 如何更好地參與團(tuán)隊(duì)合作 37
隱藏代碼 37
天才神話 38
隱藏有害 40
及早檢測(cè) 41
巴士系數(shù) 41
小步快跑 42
拒絕隱藏 44
一切為了團(tuán)隊(duì) 44
社交的三大支柱 45
三大支柱的重要性 46
謙虛、尊重和信任 46
無(wú)指責(zé)的回顧文化 50
谷歌范兒（Googley） 52
小結(jié) 53
本章要點(diǎn) 53
第3 章 知識(shí)共享 55
學(xué)習(xí)的挑戰(zhàn) 55
知識(shí)共享的哲學(xué) 57
設(shè)定基調(diào)：心理安全 58
導(dǎo)師制 58
大型群體的心理安全 59
不斷充實(shí)知識(shí) 60
提問(wèn) 60
理解上下文61
擴(kuò)大提問(wèn)渠道：向社區(qū)提問(wèn) 62
群聊 62
郵件列表 63
YAQS：?jiǎn)柎鹌脚_(tái) 63
分享你的知識(shí)：你總有可以教別人的地方 64
Office Hours 64
技術(shù)講座與課程 64
文檔 65
代碼 67
組織知識(shí)發(fā)展 68
培養(yǎng)知識(shí)分享的文化 68
建立規(guī)范的信息源 70
讓信息流動(dòng)73
可讀性：通過(guò)代碼評(píng)審規(guī)范化指導(dǎo) 74
什么是可讀性流程 74
為什么需要可讀性流程 75
小結(jié) 78
本章要點(diǎn) 78
第4 章 平等工程 79
人類(lèi)的偏見(jiàn) 80
理解多樣性的必要性 82
建立多元文化能力 82
使多樣性具有可操作性 84
拒絕單一的方式 85
挑戰(zhàn)既定流程 86
價(jià)值觀與成果 87
保持好奇心，向前推進(jìn) 88
小結(jié) 88
本章要點(diǎn) 89
第5 章 團(tuán)隊(duì)領(lǐng)導(dǎo)的藝術(shù) 91
經(jīng)理和技術(shù)主管（或兩者兼任） 91
工程經(jīng)理 92
技術(shù)主管 92
技術(shù)主管經(jīng)理 92
從個(gè)人貢獻(xiàn)者到領(lǐng)導(dǎo)者 93
需要擔(dān)心的是……嗯，一切 94
仆人式領(lǐng)導(dǎo)95
工程經(jīng)理 96
經(jīng)理是一個(gè)令人厭惡的詞 96
如今的工程經(jīng)理 96
反模式 98
反模式：雇用平庸的人 98
反模式：忽視低績(jī)效員工 99
反模式：忽視人的問(wèn)題 100
反模式：做老好人 101
反模式：打破招聘門(mén)檻 102
反模式：像對(duì)待孩子一樣對(duì)待你的團(tuán)隊(duì) 102
積極的模式 103
拋棄自我意識(shí) 103
成為一名禪師 104
成為催化劑106
移除障礙 106
成為老師和導(dǎo)師 107
設(shè)定清晰的目標(biāo) 107
坦誠(chéng) 108
追蹤幸福感109
出乎意料的問(wèn)題 110
其他提示和技巧 111
對(duì)待人像植物一樣 113
內(nèi)在激勵(lì)和外在激勵(lì) 114
小結(jié) 115
本章要點(diǎn) 115
第6 章 大規(guī)模團(tuán)隊(duì)領(lǐng)導(dǎo)力 117
總是在做決策 118
飛機(jī)的故事 118
識(shí)別盲點(diǎn) 119
識(shí)別關(guān)鍵的權(quán)衡 120
決策，然后迭代 120
總是不在場(chǎng) 122
你的使命：建立一個(gè)自驅(qū)的團(tuán)隊(duì)123
劃分問(wèn)題空間 123
總是在擴(kuò)展 126
成功的循環(huán)127
重要VS 緊急 128
學(xué)會(huì)放棄 130
保護(hù)你的精力 131
小結(jié) 133
本章要點(diǎn) 133
第7 章 度量工程生產(chǎn)力 135
為什么要度量工程生產(chǎn)力 135
鑒別：它值得度量嗎 137
根據(jù)目標(biāo)和信號(hào)來(lái)選擇有意義的指標(biāo) 141
目標(biāo) 142
信號(hào) 144
指標(biāo) 145
使用數(shù)據(jù)驗(yàn)證指標(biāo) 145
采取行動(dòng)并跟蹤結(jié)果 150
小結(jié) 150
本章要點(diǎn) 150
第三部分 流程
第8 章 風(fēng)格指南與規(guī)則 155
為什么要有規(guī)則 156
創(chuàng)建規(guī)則 157
指導(dǎo)原則 157
風(fēng)格指南 165
修改規(guī)則 168
流程 169
風(fēng)格仲裁者170
例外情況 170
指南 171
應(yīng)用規(guī)則 173
錯(cuò)誤檢查工具 174
代碼格式化工具 175
小結(jié) 177
本章要點(diǎn) 177
第9 章 代碼評(píng)審 179
代碼評(píng)審流程 180
谷歌如何進(jìn)行代碼評(píng)審 181
代碼評(píng)審的好處 184
代碼正確性185
代碼理解 187
代碼一致性187
心理和文化方面的好處 188
知識(shí)共享 189
代碼評(píng)審實(shí)踐 190
禮貌而專(zhuān)業(yè)190
小的變更 191
清晰的變更描述 193
評(píng)審者數(shù)量少化 193
盡可能的自動(dòng)化 194
代碼評(píng)審類(lèi)型 194
綠地代碼評(píng)審 194
行為變更、改進(jìn)和優(yōu)化 195
缺陷修復(fù)和回滾 195
重構(gòu)和大規(guī)模變更 196
小結(jié) 197
本章要點(diǎn) 197
第10 章 文檔 199
什么是文檔 200
為什么需要文檔 200
像代碼一樣對(duì)待文檔 202
了解文檔的讀者 204
讀者的類(lèi)型205
文檔類(lèi)型 206
參考文檔 207
設(shè)計(jì)文檔 210
新手教程 210
概念文檔 212
著陸頁(yè)面 213
文檔評(píng)審 214
文檔的哲學(xué) 216
WHO，WHAT，WHEN，WHERE 和WHY 216
開(kāi)頭，中間和結(jié)尾 217
優(yōu)秀文檔的要素 217
丟棄文檔 218
什么時(shí)候需要技術(shù)文檔工程師 219
小結(jié) 219
本章要點(diǎn) 220
第11 章 測(cè)試概述 221
為什么要寫(xiě)測(cè)試 222
Google Web Server的故事 223
當(dāng)今開(kāi)發(fā)速度下的測(cè)試 224
編寫(xiě)，運(yùn)行，響應(yīng) 224
測(cè)試代碼的好處 227
設(shè)計(jì)測(cè)試套件 228
測(cè)試粒度 229
測(cè)試范圍 233
碧昂絲規(guī)則235
代碼覆蓋率236
谷歌規(guī)模下的測(cè)試 237
大型測(cè)試套件的陷阱 238
谷歌測(cè)試的歷史 239
入職培訓(xùn)課240
測(cè)試認(rèn)證 241
馬桶測(cè)試 241
如今的測(cè)試文化 242
自動(dòng)化測(cè)試的局限性 243
小結(jié) 244
本章要點(diǎn) 244
第12 章 單元測(cè)試 245
可維護(hù)性的重要性 246
防止脆弱的測(cè)試 247
努力做到不更改測(cè)試 247
通過(guò)公共API 進(jìn)行測(cè)試 248
測(cè)試狀態(tài)，而不是交互 252
編寫(xiě)清晰的測(cè)試 253
使測(cè)試完整簡(jiǎn)潔 254
測(cè)試行為，而不是方法 255
不要把邏輯放進(jìn)測(cè)試 260
編寫(xiě)清晰的失敗信息 261
測(cè)試與代碼共享：DAMP，而不是DRY 263
共享值 265
共享設(shè)置 267
共享helper 和驗(yàn)證 269
定義測(cè)試基礎(chǔ)設(shè)施 270
小結(jié) 270
本章要點(diǎn) 270
第13 章 測(cè)試替身 273
測(cè)試替身對(duì)軟件開(kāi)發(fā)的影響 274
谷歌的測(cè)試替身 274
基本概念 275
測(cè)試替身的示例 275
縫（Seams） 276
模擬（Mocking）框架 277
使用測(cè)試替身的技術(shù) 279
偽造（Faking） 279
打樁（Stubbing） 279
交互測(cè)試 280
實(shí)際實(shí)現(xiàn) 281
實(shí)際實(shí)現(xiàn)比隔離更好 281
如何決定何時(shí)使用實(shí)際實(shí)現(xiàn) 283
偽造（Faking） 285
為什么偽實(shí)現(xiàn)（Fakes）如此重要286
什么時(shí)候?qū)憘螌?shí)現(xiàn) 286
偽實(shí)現(xiàn)的保真度 287
偽實(shí)現(xiàn)應(yīng)該被測(cè)試 288
如果沒(méi)有偽實(shí)現(xiàn)怎么辦 288
打樁 289
過(guò)度使用打樁的危險(xiǎn)性 289
何時(shí)使用打樁合適 291
交互測(cè)試 292
狀態(tài)測(cè)試優(yōu)于交互測(cè)試 292
何時(shí)使用交互測(cè)試合適 293
交互測(cè)試的實(shí)踐 294
小結(jié) 296
本章要點(diǎn) 296
第14 章 較大型的測(cè)試 299
什么是較大型的測(cè)試 299
保真度 300
單元測(cè)試中的常見(jiàn)問(wèn)題 301
為什么不要有較大型的測(cè)試 303
谷歌的較大型的測(cè)試 304
較大型的測(cè)試和時(shí)間 305
谷歌規(guī)模下的較大型的測(cè)試 306
大型測(cè)試的結(jié)構(gòu) 308
被測(cè)系統(tǒng)（SUT） 309
測(cè)試數(shù)據(jù) 314
驗(yàn)證 315
較大型的測(cè)試的類(lèi)型 316
一個(gè)或多個(gè)交互二進(jìn)制文件的功能測(cè)試 316
瀏覽器和設(shè)備測(cè)試 317
性能、負(fù)載和壓力測(cè)試 317
部署配置測(cè)試 318
探索性測(cè)試318
A/B 差異回歸測(cè)試 319
用戶驗(yàn)收測(cè)試（UAT） 321
探針和金絲雀分析 321
災(zāi)難恢復(fù)與混沌工程 322
用戶評(píng)估 324
大型測(cè)試和開(kāi)發(fā)者工作流 325
編寫(xiě)大型測(cè)試 325
運(yùn)行大型測(cè)試 326
大型測(cè)試的所有權(quán) 329
小結(jié) 330
本章要點(diǎn) 330
第15 章 棄用 331
為什么棄用 332
為什么棄用很難 333
將棄用融入設(shè)計(jì) 335
棄用的類(lèi)型 336
建議性棄用336
強(qiáng)制性棄用337
棄用警告 338
棄用流程的管理 339
流程負(fù)責(zé)人340
里程碑 340
棄用的工具341
小結(jié) 342
本章要點(diǎn) 343
第四部分 工具
第16 章 版本控制與分支管理 347
什么是版本控制 348
為什么版本控制很重要 349
集中式版本控制系統(tǒng)VS 分布式版本控制系統(tǒng) 351
真實(shí)來(lái)源 354
版本控制VS 依賴(lài)管理 356
分支管理 356
分支等同于在制品 357
開(kāi)發(fā)分支 358
發(fā)布分支 359
谷歌的版本控制 360
單一版本 361
場(chǎng)景：多個(gè)可用版本 362
單一版本規(guī)則 363
（幾乎）沒(méi)有長(zhǎng)周期的分支 363
發(fā)布分支呢365
單一代碼倉(cāng)（Monorepos） 365
版本控制的未來(lái) 367
小結(jié) 369
本章要點(diǎn) 370
第17 章 代碼搜索 371
Code Search 的用戶界面 372
如何使用Code Search 373
在哪里 373
做什么 374
如何用 374
為什么 375
誰(shuí)以及何時(shí)375
為什么需要一個(gè)單獨(dú)的Web 工具 375
規(guī)模 375
無(wú)需設(shè)置即可瀏覽全局代碼 376
專(zhuān)業(yè)化 377
與其他開(kāi)發(fā)工具集成 377
開(kāi)放API 379
規(guī)模對(duì)設(shè)計(jì)的影響 379
搜索查詢(xún)延遲 380
索引延遲 381
谷歌的實(shí)現(xiàn) 382
搜索索引 382
排序 383
權(quán)衡 387
完整性：代碼庫(kù)的Head 387
完整性：所有結(jié)果VS 相關(guān)的結(jié)果 387
完整性：Head VS 分支 VS 所有歷史 VS 工作空間 388
表達(dá)性：Token VS 子串 VS 正則表達(dá)式 389
小結(jié) 390
本章要點(diǎn) 391
第18 章 構(gòu)建工具與構(gòu)建哲學(xué) 393
構(gòu)建系統(tǒng)的目的 393
沒(méi)有構(gòu)建系統(tǒng)會(huì)發(fā)生什么 395
但是我只需要一個(gè)編譯器 395
用shell 腳本來(lái)拯救 396
現(xiàn)代構(gòu)建系統(tǒng) 397
一切都是為了依賴(lài) 397
基于任務(wù)的構(gòu)建系統(tǒng) 398
基于制品的構(gòu)建系統(tǒng) 402
分布式構(gòu)建408
時(shí)間，規(guī)模，權(quán)衡 412
處理模塊和依賴(lài) 413
使用細(xì)粒度依賴(lài)與1：1：1 規(guī)則 413
小化模塊可見(jiàn)性 414
管理依賴(lài) 414
小結(jié) 419
本章要點(diǎn) 420
第19 章 Critique：谷歌的代碼評(píng)審工具 421
代碼評(píng)審工具的原則 421
代碼評(píng)審流程 423
通知 424
步：創(chuàng)建一個(gè)變更 425
差異比較 425
分析結(jié)果 426
緊密的工具集成 428
第二步：請(qǐng)求評(píng)審 429
第三步和第四步：理解和評(píng)論變更 430
評(píng)論 430
了解變更狀態(tài) 432
第五步：批準(zhǔn)變更（評(píng)價(jià)變更） 434
第六步：提交變更 435
提交后：跟蹤歷史 436
小結(jié) 437
本章要點(diǎn) 438
第20 章 靜態(tài)分析 439
有效靜態(tài)分析的特點(diǎn) 440
可擴(kuò)展性 440
易用性 440
讓靜態(tài)分析發(fā)揮作用的關(guān)鍵經(jīng)驗(yàn) 441
關(guān)注開(kāi)發(fā)者的體驗(yàn) 441
讓靜態(tài)分析成為核心開(kāi)發(fā)者工作流的一部分 442
賦予用戶貢獻(xiàn)的權(quán)力 442
Tricorder: 谷歌的靜態(tài)分析平臺(tái) 443
集成的工具444
集成反饋渠道 445
建議的修復(fù)446
按項(xiàng)目定制447
預(yù)提交 448
編譯器集成448
編輯和瀏覽代碼時(shí)的分析 449
小結(jié) 450
本章要點(diǎn) 450
第21 章 依賴(lài)管理 451
為什么依賴(lài)管理這么難 453
沖突的需求和菱形依賴(lài) 453
引入依賴(lài) 455
兼容性承諾455
引入時(shí)的注意事項(xiàng) 457
谷歌如何處理引入的依賴(lài) 459
從理論上講，依賴(lài)管理 460
沒(méi)有變化（又名靜態(tài)依賴(lài)模型） 461
語(yǔ)義化版本號(hào) 462
綁定分發(fā)模式 463
Live at Head 464
SemVer 的局限性465
SemVer 可能過(guò)度約束 466
SemVer 可能過(guò)度承諾 467
動(dòng)機(jī) 468
小版本選擇 469
那么，SemVer 有效嗎 470
資源無(wú)限的依賴(lài)管理 471
導(dǎo)出依賴(lài) 473
小結(jié) 477
本章要點(diǎn) 477
第22 章 大規(guī)模變更 479
什么是大規(guī)模變更 480
誰(shuí)來(lái)處理LSC 481
原子變更的障礙 483
技術(shù)限制 483
合并沖突 483
沒(méi)有鬧鬼的墓地 484
異構(gòu)性 484
測(cè)試 485
代碼評(píng)審 487
LSC 的基礎(chǔ)設(shè)施 489
政策與文化489
代碼庫(kù)分析490
變更管理 491
測(cè)試 491
語(yǔ)言支持 491
LSC 流程 493
授權(quán) 493
變更創(chuàng)建 494
切片與提交494
清理 498
小結(jié) 498
本章要點(diǎn) 498
第23 章 持續(xù)集成 499
CI 的概念 501
快速反饋循環(huán) 501
自動(dòng)化 503
持續(xù)測(cè)試 505
CI 的挑戰(zhàn) 511
封閉測(cè)試 512
谷歌的CI 515
CI 案例研究：Google Takeout 518
但是我無(wú)力做CI 524
小結(jié) 525
本章要點(diǎn) 525
第24 章 持續(xù)交付 527
持續(xù)交付在谷歌的習(xí)語(yǔ) 528
速度是一項(xiàng)團(tuán)隊(duì)運(yùn)動(dòng)：如何將部署分解為可管理的單元 529
隔離評(píng)估變更：特性開(kāi)關(guān) 530
力求敏捷：建立發(fā)布火車(chē) 531
沒(méi)有一個(gè)二進(jìn)制是完美的 531
趕上你的發(fā)布期限 532
質(zhì)量與聚焦用戶：只發(fā)布有用的功能 533
左移：更早地做出數(shù)據(jù)驅(qū)動(dòng)的決策 534
改變團(tuán)隊(duì)文化：建立發(fā)布規(guī)則 535
小結(jié) 536
本章要點(diǎn) 537
第25 章 計(jì)算即服務(wù) 539
馴服計(jì)算環(huán)境 540
將瑣事自動(dòng)化 540
容器化與多租戶 542
總結(jié) 545
為托管計(jì)算編寫(xiě)軟件 545
為失效設(shè)計(jì)架構(gòu) 545
批處理VS 服務(wù) 547
管理狀態(tài) 549
連接到服務(wù)550
一次性代碼551
CaaS 隨時(shí)間和規(guī)模的演化 552
抽象容器 552
一個(gè)服務(wù)統(tǒng)御余眾 555
提交的配置557
選擇計(jì)算服務(wù) 558
集中化與定制化 559
抽象層次：Serverless 561
公有云VS 私有云 565
小結(jié) 566
本章要點(diǎn) 567
后記 569
書(shū)單推薦
