Google 里的软件工程学
简评：原文作者 Fergus Henderson 在 Google 工作了 10 年以上，目前负责 Google 的 text-tospeech 工程小组。有很多书籍或文章会从 商业/管理 等非技术角度来讲 Google 是如何运作的，这篇文档则是从软件工程学的角度来讲 Google 是如何运作的。
Google 的成功有很多原因，其中一个重要原因就是 Google 不断积累的、优秀的软件工程实践经验。
本文的目的是梳理并简要介绍 Google 软件开发的核心流程，内容上主要分为软件开发 (Software development)、项目管理 (Project management) 和团队建设 (People management) 三个方面。
原文目录
▎软件开发
源码仓库（The Source Repository）
- 单一源代码仓库，除了核心配置和安全相关代码，任何工程师都可以访问任何代码，并可以根据需要修改
- 所有开发都基于 master 分支，发布的时候才创建发布分枝
- 代码的每个子树都有 owner，任何修改都需要 owner 批准
Blaze 分布式构建系统（The Build System）
- 构建和测试存储库中的任何软件通常非常简单和快捷
- 开发人员只需要编写 BUILD 文件，并且每个构建系统仅依赖 BUILD 文件所声明的文件
- 构建系统的优化：可靠，自动跟踪依赖关系，增量构建，缓存构建结果以便复用
- 自动代码检查和测试
代码审查（Code Review）
- 完善的代码审查工具，如可视化的 Web 界面、电子邮件集成、自动展示测试或静态分析的结果
- 每个变更都必须由至少另外一人审查，并将审查结果自动复制到项目维护者的邮件列表
- 鼓励小的变更，大的变更可以拆分为一系列较小的变更
测试（Testing）
- 鼓励和广泛使用单元测试，Mocking 非常普遍
- 广泛使用集成测试和回归测试
- 自动测量测试覆盖率
- 部署之前进行负载测试，显示关键的 metrics，比如延迟、错误率以及它们随请求速率的变化情况
Bug 跟踪（Bug tracking）
- Google 使用名为 Buganizer 的 Bug 跟踪系统
- 使用标签分类 bug
- 每个 bug 都有一个默认的 assignee 和抄送邮件列表
编程语言（Programming languages）
- 鼓励使用 C++、Java、Python 或 Go之一，最小化不同编程语言的数量
- 每种语言都有 Google 风格指南，还有一个公司范围内的可读性培训
- 不同语言之前使用基于 Protocol Buffers 的 RPC 通信
- 为所有语言提供通用的开发工具，比如代码签出、编辑、构建、测试、审查、bug 报告等
调试和分析（Debugging and Profiling tools）
- 在通用框架中提供调试和代码跟踪工具
- 提供用于调试的网络接口检查 RPC 调用的时间、错误率和频率限制以及资源消耗、性能分析数据等
发布（Release engineering）
- 频繁发布（比如每周或每两周），自动化发布任务，提高工程师积极性，允许更多迭代以加快整体速度
- 发布分支，将 master 的修改 cherry-pick 到发布分支
- 发布到 staging 服务器，测试部分生产流量的副本
- 发布到 canary 服务器，测试真实生产流量的一个子集
- 最后逐步发布到所有服务器
Launch approval
- 任何用户可见的更改或重大的设计变更都需要工程团队之外的很多人员的审查和批准，以确保这些变更满足符合法律、隐私、安全、可靠性以及业务需求
- Google 内部的 Launch approval 工具会跟踪这些审查和批准
Post-mortems
- 任何重大的生产故障都需要写一份事后的总结文档，描述事件的原因、影响以及如何解决
- 重点关注如何避免它们再次发生（而不是追究人员责任）
频繁重写（Frequent rewrites）
- 大部分软件每隔几年都会重写一次
- 减少了累计复杂性
- 有助于适应当前的最佳实践，鼓励新的想法
- 也是一种团队成员之间传递 ownership 的方式
- 这是 Google 保持敏捷和长期成功的关键
▎项目管理
20% 时间
- 允许工程师将 20% 时间花在喜欢的任何项目上
- 有助于新想法的原型开发和演示，提高员工积极性
- 鼓励创新企业文化
OKRs（Objectives and Key Results）
- 个人和团队要明确记录目标并评估这些目标的进展情况，团队设置季度和年度目标
- 建立关键结果来量化 OKR，用 OKR score 评估进展情况
- 设置野心勃勃的 OKR 指标，即设置期望为目标的 65%
- OKR 是全公司透明的，是一种简化的沟通框架，使每个人都清晰了解公司的目标以及自己的位置
项目审批（Project approval）
- Google 没有明确的项目审批流程，一般通过自下而上的方式进行
公司重组（Corporate reorganizations）
- 因项目取消而重组时工程师可以自由选择新的团队或角色
- 在很大程度上，技术驱动公司应该进行频繁的重组以避免组织效率低下
▎团队建设
角色（Roles）
技术角色与管理角色分开，项目由技术主管领导和决策，而经理负责管理技术主管，指导职业发展，并负责绩效评估。
- 软件工程师
- 研究科学家
- SRE
- 产品经理
- 项目经理
工作环境（Facilities）
- Google 提供丰富的娱乐、运动和餐饮设施
- 开放式办公鼓励沟通
- 先进的视频会议设施方便不同团队的沟通
培训（Training）
- 新员工培训，每个新员工都有导师和伙伴（Buddy）
- 「Codelabs」和丰富的培训课程
- 也支持外部机构学习
换岗（Transfers）
- 鼓励在不同部门换岗，帮助公司内传播知识
- 允许 12 个月内表现良好的员工更换项目
- 鼓励临时性的参与其他项目
绩效考核和奖励（Performance appraisal and rewards）
- 鼓励「peer bonuses」和「kudos」
- 明确详细的晋升过程，确保正确的人得到晋升
- 匿名反馈调查评估经理的绩效
▎小结
本文简要介绍了在 Google 使用的重要软件工程的实践方法。Google 是一个庞大并且多元化的组织，有一些部门用的是不同的实践方法，但是这里描述的实践方法被 Google 大多数的团队所遵循。
实践方法的详细内容请移步文末的英文原文链接。
