正版 Google软件工程 [美]提图斯·温特斯,[美]汤姆·曼什雷克,[美]

目录 序 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 清晰的变更描述 1审者数量少化 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 模拟（Mo）框架 277 使用测试替身的技术 279 伪造（F） 279 打桩（Stubbing） 279 交互测试 280 实际实现 281 实际实现比隔离更好 281 如何决定何时使用实际实现 283 伪造（F） 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

[美]提图斯·温特斯(Titus Winters)，谷歌高级软件工程师，他是谷歌C++代码库的领导者：2亿5000万行代码，每月成千上万名不同的工程师在这些代码上工作。
[美]汤姆·曼什雷克(Tom Manshreck)，在谷歌软件工程部担任技术作家。他是C++ Library Team的成员，负责开发文档，开展培训课程以及为Abseil，谷歌的开源C++代码，编写文档。
[美]海勒姆·赖特(Hyrum Wright)，是谷歌的一名软件工程师，他领导着谷歌自动化变更工具团队。Hyrum对谷歌代码库的编辑比公司历史上任何其他工程师都要多。

这本书解释了谷歌做软件工程的方式，讲述了需要考虑的各种权衡。
如今，软件工程师不仅需要知道如何有效地编程，还需要知道如何发展适当的工程实践，以使代码库可持续且健康。这本书强调了编程和软件工程之间的区别。
软件工程师如何管理一个活跃的代码库，这个代码库在其生命周期里不断响应变化的需求，不断地发展？软件工程师Titus Winters和Hyrum Wright，携手技术作家Tom Manshreck，基于他们在谷歌的经验，坦率而有见地的为大家介绍了世界领先的从业者是如何构建和维护软件的。
“这本书解释了谷歌做软件工程的方式，这种方式让我有很高的生产力，并且很快乐，同时本书也直言不讳的讲述了需要考虑的各种权衡。”——Eric Haugh谷歌软件工程师
本书注重从实践出发选择和安排素材，同时又从理论上进行了全面深入的探讨。对诸如复用、风险管理和质量工程、测度和度量等理论性比较强的主题，没有专设章节，而是融合在相关的各种软件工程活动中讲述。

前言 本书的书名是“Google 软件工程”。软件工程到底是什么意思？“软件工程”与“编程”或“计算机科学”有什么区别？为什么谷歌会把自己对软件工程的观点编写成一本书，在50 年软件工程的历史中留下这一笔？ 术语“编程”和“软件工程”在我们的行业中已经交替使用了相当长的一段时间，尽管它们都有不同的和含义。大学生们倾向于学习计算机科学，并获得以“程序员”的身份编写代码的工作。 然而，“软件工程”听起来更为严肃，似乎它意味着应用一些理论知识来构建真实而的东西。机械工程师、土木工程师、航空工程师和其他工程领域的工程师都从事工程实践。他们都在现实世界中工作，运用自己的理论知识创造出真实的东西。软件工程师也创造“真实的东西”，尽管它相比其他工程师创造的东西来说并没那么实实在在。 与那些更成熟的工程专业不同，当前的软件工程理论或实践并没有那么严格。航空工程师必须遵循严格的指导方针和实践，因为他们计算中的错误会造成真实的损害体而言，编程在传统上没有遵循这样严格的实践。但是，随着软件越来越融入我们的生活，我们必须采用和依赖更严格的工程方法。我们希望本书能帮助其他人看到一条通向更可靠的软件实践的道路。 编程的时间 我们认为“软件工程”不括编写代码的行为，括组织在一段时间内用来构建和维护代码的所有工具和流程。一个软件组织可以引入哪些实践来限度地保持其代码的价值？工程师如何使代码库更具可持续以及软件工程学科本身更为严格？对于这些问题，我们没有基本的答案，但我们希望谷歌过去20 年的经验能够为我们找到这些答案指明可能的道路。 我们在这本书中分享的一个关键见解是，软件工程可以被认为是“随着时间而不断集成的编程”。我们可以为我们的代码引入哪些实践，使其在整个生命周期内，从概念到上市、到维护、再到弃用，具有可持续（能够对必要的变更做出反应）？这本书强调了我们认为的软件组织在设计、架构和编写代码时应该牢记的三个基本原则： 时间与变化 代码在其生命周期内需要如何适应。 规模与增长 组织在发展过程中要如何适应。 权衡与成本 组织如何从时间、变化、规模和增长中所学到的经验来做出决策。 贯穿所有章节，我们试图围绕这些主题，并指出这些原则是如何影响工程实践的，并让它们可持续的发展（完整讨论见第1 章）。 谷歌的视角 鉴于我们的规模和历史，谷歌对可持续软件生态系统的增长和演变有着的视角。我们希望我们所吸取的经验教训能对贵组织的发展和拥抱更多可持续实践有所帮助。 我们将本书的主题分为谷歌软件工程领域的三个主要方面： ? 文化。 ? 流程。 ? 工具。 谷歌的文化是的，但我们在发展我们的工程文化中所吸取的教训是广泛适用的。我们关于文化的章节（部分）强调了软件开发企业的集体，软件开发是一种团队工作，恰当的文化原则对于一个组织的成长和持续健康关重要。 我们的流程章节（第三部分）中概述的技术对大多数软件工程师来说都很熟悉，但是谷歌庞大规模和多年积累的大型代码库为开发实践提供了一个更完整的“压力测试”。在这些章节中，着重讲述了我们发现随着时间的推移以及规模的增长而起作用的东西，并且也还有我们仍然没有得到满意答案的领域。 后，我们的工具章节（第四部分）说明了我们如何利用对工具基础设施的投资，来为日益增长和老化的代码库带来收益。在某些情况下，这些工具是谷歌特有的，尽管我们指出了开源或第三方的替代方案（如果适用的话）。我们期望这些基本见解适用于大多数工程组织。 本书中概述的文化、流程和工具描述了典型的软件工程师希望在工作中学到的经验教训。当然并不是只有谷歌才能提供好的建议，我们在这里介绍的经验不是要指示你的组织应该做什么。本书是我们的观点，我们希望你会发现它是有用的，不管直接采用这些经验，还是在考虑自己的实践时将它们作为出发点，专门针对自己的问题领域进行优化。 这本书也不打算说教。谷歌本身仍然没有地应用书中的许多概念。我们从失败中吸取的教训是：我们仍然会犯错误，执行不的解决方案，并且需要不断改进。然而，谷歌工程组织的庞大规模使得每个问题都有多种解决方案。我们希望本含了其中的精华。 本书含的内容 本书并不涵盖软件设计，这是一门需要独立出书（并且已经有很多内容）的学科。尽管本书中有一些代码用于说明，但这些原则与编程语言无关，在这些章节中几乎没有实际的“编程”建议。因此，本文没有涉及软件开发中的许多重要问题：项目管理、API 设计、强化、化、用户界面框架或其他特定编程语言的关注点。它们在这本书中被遗漏并不意味着它们不重要。相反，我们选择不在这里讲述它们，是因为我们无法提供它们应得的待遇。我们试图使本书中的讨论更多的是聚焦于工程，而不是编程。 临别赠言 这本书代表了所有贡献者付出的努力和汗水，我们希望你能收到它：把它当做一个了解大型软件工程组织如何构建其产品的窗口。我们也希望，这是众多的声音之一，有助于推动我们的行业采取更具前瞻的思维和可持续的实践。重要的是，我们希望你喜欢这本书，并能从这本书中获得你关心的观点。 —— Tom Manshreck 内容约定 本书采用以下排版约定： 斜体（Italic） 表示新术语、URL、电子邮件地址、文件名和扩展名。 等宽字体（Constant width） 用于程序示例，以及段落中引用程序元素，如变量或函数名、数据库、数据类型、环境变量、语句和关键字。 等宽黑体（Constant width bold） 显示用户应键入的命令或其他文本。 等宽斜体（Constant width italic） 显示应替换为用户提供的或由上下文确定的值的文本。 O’Reilly 在线学习平台（O’Reilly Online Learning）40 年来，O’Reilly Media 于提供技术和商业培训、知识和见解，来帮助众多公司取得。 我们有一群和创新者，他们通过图书、文章、会议和在线学习平台分享知识和技术。O’Reilly 的在线学习平台提供按需访问的直播培训课程、详细的学习路径、交互式编程环境，以及由O’Reilly 和其他200 多家出版社出版的书籍和。 详情请访问oreilly.com。 联系我们 任何有关本书的意见或疑问，请按照以下地址联系出版社。 美国： O’Reilly Media, Inc. 1005 Gravenstein Highway North Sebastopol, CA 95472 中国： 北京市西城区西直门南大街2 号成铭大厦C 座807 室（100035） 奥莱利技术咨询（北京）有限公司 我们有本书的专属网页，你可以在那儿找到本书的勘误、示例和其他信息。网页地址：soreil.ly/software-engineering-at-google。 如果你对本书有一些评论或技术上的建议，请发送电子邮件到 bookquestions@oreilly.com。 有关其他图书、讲座、会议、新闻的信息，请访问我们的网站：.oreilly.com。 Facebook：facebook.com/oreilly。 Twitter：twitter.com/oreillymedia。 YouTube：.youtube.com/oreillymedia。 致谢 没有无数其他人的努力是不可能有这本书的。这本书中的知识都来自我们在谷歌的职业生涯中许多其他人的经验。我们是使者，他们来到我们面前，在谷歌和其他地方，教导我们现在呈现给你们的东西。我们不能在这里一一列举，但衷心地向你们致谢。 我们还要感谢Melody Meckfessel 在项目初期的支持，以及Daniel Jasper 和Danny Berlin 在项目完成过程中的支持。 如果没有策划人、作者和编辑的大量合作是不可能有这本书的。尽管作者和编辑在每一章或标注中都得到了明确的认可，但我们还是希望再次感谢那些对每一章做出贡献的人，他们为本书提供了深思熟虑的意见、讨论和评审。 Tom Manshreck：感谢我的父母让我相信自己，和我一起在餐桌旁完成工作。 Titus Winters：感谢父亲，为我指明道路。感谢母亲，倾听我的声音。感谢Victoria 对我的支持。感谢Raf，做我的后盾。此外，还要感谢Snyder，Ranwa，Z，Mike，Zach，Tom ( 以及Payne 一家), mec，Toby，cgd 和Melody，感谢他们的教诲、指导和信任。 Hyrum Wright：感谢父亲和母亲的鼓励。感谢Bryan 和Bakerland 公司，给了我次尝试软件的机会。感谢Dewayne，与我并肩作战。感谢Hannah，Jonathan，Charlotte，Spencer 和Ben，感谢他们的爱和关注。感谢Heather 一路的陪伴。

这本书解释了谷歌做软件工程的方式，讲述了需要考虑的各种权衡。 如今，软件工程师不仅需要知道如何有效地编程，还需要知道如何发展适当的工程实践，以使代码库可持续且健康。这本书强调了编程和软件工程之间的区别。 软件工程师如何管理一个活跃的代码库，这个代码库在其生命周期里不断响应变化的需求，不断地发展？软件工程师Titus Winters和Hyrum Wright，携手技术作家Tom Manshreck，基于他们在谷歌的经验，坦率而有见地的为大家介绍了的从业者是如何构建和维护软件的。 “这本书解释了谷歌做软件工程的方式，这种方式让我有很高的生产力，并且很快乐，同时本书也直言不讳的讲述了需要考虑的各种权衡。” ——Eric Haugh 谷歌软件工程师