Google軟件工程 - 城邦阅读花园


	你將學習到軟體組織在設計、架構、編寫和維護代碼時應牢記的三個基本原則：時間如何影響軟體的可持續性，以及如何使代碼隨著時間的推移而具有韌性。模如何影響工程組織內軟體實踐的可行性。在評估設計和開發決策時，一位元典型的工程師需要做出哪些權衡。



	購買中國簡體書籍請注意： 1. 因裝幀品質及貨運條件未臻完善，中國簡體書可能有出現磨痕、凹痕、折痕等問題，故簡體字館除封面破損、內頁脫落、缺頁等較嚴重的狀態外，其餘所有商品將正常出貨。


	目錄序 1 前言 3 第一部分理論第1 章什麼是軟體工程 13 時間與變化 15 海勒姆定律18 案例：雜湊排序 18 為什麼目標不是“沒有變化”呢 20 規模與效率 21 阻礙規模化的政策 22 促進規模化的政策 24 案例：編譯器升級 24 左移思想 26 權衡與成本 28 案例：白板筆 29 決策投入 30 案例：分散式構建 30 案例：時間與規模的博弈 32 資料驅動的決策 32 軟體工程VS 程式設計 33 小結 34 本章要點 34 第二部分文化第2章如何更好地參與團隊合作 37 隱藏代碼 37 天才神話 38 隱藏有害 40 及早檢測 41 巴士係數 41 小步快跑 42 拒絕隱藏 44 一切為了團隊 44 社交的三大支柱 45 三大支柱的重要性 46 謙虛、尊重和信任 46 無指責的回顧文化 50 谷歌範兒（Googley） 52 小結 53 本章要點 53 第3章知識共用 55 學習的挑戰 55 知識共用的哲學 57 設定基調：心理安全 58 導師制 58 大型群體的心理安全 59 不斷充實知識 60 提問 60 理解上下文61 擴大提問管道：向社區提問 62 群聊 62 郵寄清單 63 YAQS：問答平臺 63 分享你的知識：你總有可以教別人的地方 64 Office Hours 64 技術講座與課程 64 文檔 65 代碼 67 組織知識發展 68 培養知識分享的文化 68 建立規範的資訊源 70 讓資訊流動73 可讀性：通過代碼評審規範化指導 74 什麼是可讀性流程 74 為什麼需要可讀性流程 75 小結 78 本章要點 78 第4章平等工程 79 人類的偏見 80 理解多樣性的必要性 82 建立多元文化能力 82 使多樣性具有可操作性 84 拒絕單一的方式 85 挑戰既定流程 86 價值觀與成果 87 保持好奇心，向前推進 88 小結 88 本章要點 89 第5章團隊領導的藝術 91 經理和技術主管（或兩者兼任） 91 工程經理 92 技術主管 92 技術主管經理 92 從個人貢獻者到領導者 93 需要擔心的是……嗯，一切 94 僕人式領導95 工程經理 96 “經理”是一個令人厭惡的詞 96 如今的工程經理 96 反模式 98 反模式：雇用平庸的人 98 反模式：忽視低績效員工 99 反模式：忽視“人”的問題 100 反模式：做老好人 101 反模式：打破招聘門檻 102 反模式：像對待孩子一樣對待你的團隊 102 積極的模式 103 拋棄“自我”意識 103 成為一名禪師 104 成為催化劑106 移除障礙 106 成為老師和導師 107 設定清晰的目標 107 坦誠 108 追蹤幸福感109 出乎意料的問題 110 其他提示和技巧 111 對待人像植物一樣 113 內在激勵和外在激勵 114 小結 115 本章要點 115 第6章大規模團隊領導力 117 總是在做決策 118 飛機的故事 118 識別盲點 119 識別關鍵的權衡 120 決策，然後反覆運算 120 總是不在場 122 你的使命：建立一個“自驅”的團隊123 劃分問題空間 123 總是在擴展 126 成功的迴圈127 重要VS 緊急 128 學會放棄 130 保護你的精力 131 小結 133 本章要點 133 第7章度量工程生產力 135 為什麼要度量工程生產力 135 鑒別：它值得度量嗎 137 根據目標和信號來選擇有意義的指標 141 目標 142 信號 144 指標 145 使用資料驗證指標 145 採取行動並跟蹤結果 150 小結 150 本章要點 150 第三部分流程第8章風格指南與規則 155 為什麼要有規則 156 創建規則 157 指導原則 157 風格指南 165 修改規則 168 流程 169 風格仲裁者170 例外情況 170 指南 171 應用規則 173 錯誤檢查工具 174 代碼格式化工具 175 小結 177 本章要點 177 第9章代碼評審 179 代碼評審流程 180 穀歌如何進行代碼評審 181 代碼評審的好處 184 代碼正確性185 代碼理解 187 代碼一致性187 心理和文化方面的好處 188 知識共用 189 代碼評審實踐 190 禮貌而專業190 小的變更 191 清晰的變更描述 193 評審者數量少化 193 盡可能的自動化 194 代碼評審類型 194 綠地代碼評審 194 行為變更、改進和優化 195 缺陷修復和回滾 195 重構和大規模變更 196 小結 197 本章要點 197 第10章文檔 199 什麼是文檔 200 為什麼需要文檔 200 像代碼一樣對待文檔 202 瞭解文檔的讀者 204 讀者的類型205 文檔類型 206 參考文檔 207 設計文檔 210 新手教程 210 概念文檔 212 著陸頁面 213 文檔評審 214 文檔的哲學 216 WHO，WHAT，WHEN，WHERE 和WHY 216 開頭，中間和結尾 217 優秀文檔的要素 217 丟棄文檔 218 什麼時候需要技術文檔工程師 219 小結 219 本章要點 220 第11章測試概述 221 為什麼要寫測試 222 “Google Web Server”的故事 223 當今開發速度下的測試 224 編寫，運行，回應 224 測試代碼的好處 227 設計測試套件 228 測試細微性 229 測試範圍 233 碧昂絲規則235 代碼覆蓋率236 穀歌規模下的測試 237 大型測試套件的陷阱 238 穀歌測試的歷史 239 入職培訓課240 測試認證 241 “馬桶測試” 241 如今的測試文化 242 自動化測試的局限性 243 小結 244 本章要點 244 第12章單元測試 245 可維護性的重要性 246 防止脆弱的測試 247 努力做到不更改測試 247 通過公共API 進行測試 248 測試狀態，而不是交互 252 編寫清晰的測試 253 使測試完整簡潔 254 測試行為，而不是方法 255 不要把邏輯放進測試 260 編寫清晰的失敗資訊 261 測試與代碼共用：DAMP，而不是DRY 263 共用值 265 共用設置 267 共用helper 和驗證 269 定義測試基礎設施 270 小結 270 本章要點 270 第13章測試替身 273 測試替身對軟體發展的影響 274 谷歌的測試替身 274 基本概念 275 測試替身的示例 275 縫（Seams） 276 模擬（Mocking）框架 277 使用測試替身的技術 279 偽造（Faking） 279 打樁（Stubbing） 279 交互測試 280 實際實現 281 實際實現比隔離更好 281 如何決定何時使用實際實現 283 偽造（Faking） 285 為什麼偽實現（Fakes）如此重要286 什麼時候寫偽實現 286 偽實現的保真度 287 偽實現應該被測試 288 如果沒有偽實現怎麼辦 288 打樁 289 過度使用打樁的危險性 289 何時使用打樁合適 291 交互測試 292 狀態測試優於交互測試 292 何時使用交互測試合適 293 交互測試的實踐 294 小結 296 本章要點 296 第14章較大型的測試 299 什麼是較大型的測試 299 保真度 300 單元測試中的常見問題 301 為什麼不要有較大型的測試 303 穀歌的較大型的測試 304 較大型的測試和時間 305 穀歌規模下的較大型的測試 306 大型測試的結構 308 被測系統（SUT） 309 測試資料 314 驗證 315 較大型的測試的類型 316 一個或多個交互二進位檔案的功能測試 316 流覽器和設備測試 317 性能、負載和壓力測試 317 部署配置測試 318 探索性測試318 A/B 差異回歸測試 319 用戶接受度測試（UAT） 321 探針和金絲雀分析 321 災難恢復與混沌工程 322 用戶評估 324 大型測試和開發者工作流 325 編寫大型測試 325 運行大型測試 326 大型測試的所有權 329 小結 330 本章要點 330 第15章棄用 331 為什麼棄用 332 為什麼棄用很難 333 將棄用融入設計 335 棄用的類型 336 建議性棄用336 強制性棄用337 棄用警告 338 棄用流程的管理 339 流程負責人340 里程碑 340 棄用的工具341 小結 342 本章要點 343 第四部分工具第16章版本控制與分支管理 347 什麼是版本控制 348 為什麼版本控制很重要 349 集中式版本控制系統VS 分散式版本控制系統 351 真實來源 354 版本控制VS 依賴管理 356 分支管理 356 分支等同於在製品 357 開發分支 358 發佈分支 359 穀歌的版本控制 360 單一版本 361 場景：多個可用版本 362 “單一版本”規則 363 （幾乎）沒有長週期的分支 363 發佈分支呢365 單一代碼倉（Monorepos） 365 版本控制的未來 367 小結 369 本章要點 370 第17章代碼搜索 371 Code Search 的使用者介面 372 如何使用Code Search 373 在哪裡 373 做什麼 374 如何用 374 為什麼 375 誰以及何時375 為什麼需要一個單獨的Web 工具 375 規模 375 無需設置即可流覽全域代碼 376 專業化 377 與其他開發工具集成 377 開放API 379 規模對設計的影響 379 搜索查詢延遲 380 索引延遲 381 穀歌的實現 382 搜索索引 382 排序 383 權衡 387 完整性：代碼庫的Head 387 完整性：所有結果VS 相關的結果 387 完整性：Head VS 分支 VS 所有歷史 VS 工作空間 388 表達性：Token VS 子串 VS 規則運算式 389 小結 390 本章要點 391 第18章構建工具與構建哲學 393 構建系統的目的 393 沒有構建系統會發生什麼 395 但是我只需要一個編譯器 395 用shell 腳本來拯救 396 現代構建系統 397 一切都是為了依賴 397 基於任務的構建系統 398 基於製品的構建系統 402 分散式構建408 時間，規模，權衡 412 處理模組和依賴 413 使用細細微性依賴與1：1：1 規則 413 小化模組可見性 414 管理依賴 414 小結 419 本章要點 420 第19章 Critique：穀歌的代碼評審工具 421 代碼評審工具的原則 421 代碼評審流程 423 通知 424 步：創建一個變更 425 差異比較 425 分析結果 426 緊密的工具集成 428 第二步：請求評審 429 第三步和第四步：理解和評論變更 430 評論 430 瞭解變更狀態 432 第五步：批准變更（評價變更） 434 第六步：提交變更 435 提交後：跟蹤歷史 436 小結 437 本章要點 438 第20章靜態分析 439 有效靜態分析的特點 440 可擴展性 440 易用性 440 讓靜態分析發揮作用的關鍵經驗 441 關注開發者的體驗 441 讓靜態分析成為核心開發者工作流的一部分 442 賦予用戶貢獻的權力 442 Tricorder: 穀歌的靜態分析平臺 443 集成的工具444 集成回饋管道 445 建議的修復446 按項目定制447 預提交 448 編譯器集成448 編輯和流覽代碼時的分析 449 小結 450 本章要點 450 第21章依賴管理 451 為什麼依賴管理這麼難 453 衝突的需求和菱形依賴 453 引入依賴 455 相容性承諾455 引入時的注意事項 457 穀歌如何處理引入的依賴 459 從理論上講，依賴管理 460 沒有變化（又名靜態依賴模型） 461 語義化版本號 462 綁定分發模式 463 Live at Head 464 SemVer 的局限性465 SemVer 可能過度約束 466 SemVer 可能過度承諾 467 動機 468 小版本選擇 469 那麼，SemVer 有效嗎 470 資源無限的依賴管理 471 匯出依賴 473 小結 477 本章要點 477 第22章大規模變更 479 什麼是大規模變更 480 誰來處理LSC 481 原子變更的障礙 483 技術限制 483 合併衝突 483 “沒有鬧鬼的墓地” 484 異構性 484 測試 485 代碼評審 487 LSC 的基礎設施 489 政策與文化489 代碼庫分析490 變更管理 491 測試 491 語言支援 491 LSC 流程 493 授權 493 變更創建 494 切片與提交494 清理 498 小結 498 本章要點 498 第23章持續集成 499 CI 的概念 501 快速回饋迴圈 501 自動化 503 持續測試 505 CI 的挑戰 511 封閉測試 512 穀歌的CI 515 CI 案例研究：Google Takeout 518 但是我無力做CI 524 小結 525 本章要點 525 第24章持續交付 527 持續交付在穀歌的習語 528 速度是一項團隊運動：如何將部署分解為可管理的單元 529 隔離評估變更：特性開關 530 力求敏捷：建立發佈火車 531 沒有一個二進位是完美的 531 趕上你的發佈期限 532 品質與聚焦用戶：只發佈有用的功能 533 左移：更早地做出資料驅動的決策 534 改變團隊文化：建立發佈規則 535 小結 536 本章要點 537 第25章計算即服務 539 馴服計算環境 540 將瑣事自動化 540 容器化與多租戶 542 總結 545 為託管計算編寫軟體 545 為失效設計架構 545 批次處理VS 服務 547 管理狀態 549 連接到服務550 一次性代碼551 CaaS 隨時間和規模的演化 552 抽象容器 552 一個服務統禦餘眾 555 提交的配置557 選擇計算服務 558 集中化與定制化 559 抽象層次：Serverless 561 公有雲VS 私有雲 565 小結 566 本章要點 567 後記 569