Fergus Henderson 是在谷歌工作十余年的软件工程师。1979年，当他还是儿童时即开始学习编程，而后进行了编程语言设计与实现的学术培养，在墨尔本大学，他与他的博士导师共同创建的研究小组开发了编程语言 Mercury。他担任了八届国际会议委员，并且发布了超过500，000行开源代码。他曾经作为comp.std.c++新闻组的主持人，而且是ISO c & c++委员会公认的“技术专家”。他有着15年以上的商业软件从业经历。在谷歌，他是Blaze的初始开发着之一，后者是谷歌使用的一种构建工具。他的工作还涉及语音识别、语音命令（在siri之前！）、语音合成的服务器端软件。他目前负责管理谷歌的文本转语音小组，但是仍然编写和评审大量代码。他编写的软件安装在了数十亿的设备上，并且每天数十亿次被使用。

内容：

1.介绍

谷歌已经成为一个现象级成功的公司。不仅在搜索与广告方面，谷歌还提供了其他基础的产品，包括谷歌地图、谷歌新闻、谷歌翻译、谷歌语音识别、Chrome、Android等等、通过收购其他小公司，谷歌极大的增强和规模化了很多其他产品，比如说YouTube，并且为许多开源工程做出了广泛的贡献。谷歌还展示了很多尚未发布的优秀产品，比如说自动驾驶汽车。

谷歌的成功有诸多原因，比如说启发性的领导，优秀的人才，较高的招聘标准，以及通过在快速发展的市场快速占领先机而取得的经济实力。然而，谷歌优秀的软件工程实践也是帮助其成功的原因之一。这些实践伴随世界上最有才华的工程师们的智慧的积聚和提纯而不断进化。我们打算将我们的知识同世界一同分享，并且分享一路走来从错误中汲取的教训。

本篇论文的目的是简要编目并描述谷歌的关键软件工程实践。其他组织和个人从而能够将其与自身的软件工程实践进行比较，然后考虑是否将谷歌的部分实践应用到自身。

很多作者发表了关于谷歌成功的原因与历史的著作与文章，但是这些大部分着眼于谷歌的市场、管理与文化。只有一部分探索了软件工程方面的问题。而且其中大部分也只是涉及了单一的方面，没有人将谷歌整体的软件工程实践进行简要的总结。而这就是这篇论文的目的。

2.软件开发

2.1 源代码仓库

大部分谷歌的代码都保存在一个统一的代码仓库上，每个谷歌的工程师都可以访问。值得注意的例外是，两个特大开源工程，Chrome 与 Android 的代码存放在单独的仓库上。有一些高价值或者安全级高的代码的读权限进行了更严格的控制。截止2015年1月，谷歌代码仓库有86TB数据，包含10亿个文件。其中900万个源代码文件，代码的行数超过20亿。历史提交次数为350亿次，并且以每个工作日4万次的速度递增。代码的写权限被严格控制：只有属主才有权批准对应子目录的修改。但是通常来说每个工程师能够访问一段代码、检出、构建这段代码，并且在本地进行修改，并且进行测试。他可以将代码的修改发送给对应的属主进行评审，如果属主批准，就可以提交对应的修改。从文化上，每个工程师都被鼓励去修复任何他们看到的存在问题的代码，去了解如何修复这些问题，不论（这些问题）是否超出了自己项目的边界。这样的举动给予了工程师授权，导致了更高质量的代码结构，更好的满足了使用者的需求。

几乎所有的开发在仓库的“HEAD”进行，而不是在分支上。这样能够帮助及早鉴别集成问题以及最小化合并代码的工作量。这样也使得安全修复更简单更快捷的推出。

通常在对应测试所依赖的文件改动之后，自动化的系统频繁的进行测试，即使这样不总是可行。系统会自动通知构建失败模块的属主与评审者，典型的时间在几分钟左右。大部分小组为了着重显示当前的构建状态，会安装突出的显示器甚至带有灯泡的雕塑（绿色表示构建成功，测试通过；红色表示构建成功，测试失败；黑色表示构建失败）。很多比较大的小组甚至有“构建警察”，他们通过与有问题的修改的作者进行协作，解决问题或者回滚修改，来保证测试持续通过。（“构建警察”的角色通常由小组内成员或者经验丰富的成员之间轮流担当）聚焦在保证测试通过保证了在“HEAD”开发是切实可行的，即使是对于非常大的组。

代码所有权。代码仓库的每个子树均包含一个文件，列出了此目录属主的ID 。每个子目录可以选择继承或者屏蔽母目录的属主。每个子树的属主控制子树的写权限（见下节“代码评审”）。每个子树至少需要两个属主，通常会多于两个，特别实在办公区域不在一地的小组。整个小组成员均是子树的属主也比较常见。任何谷歌的人都可以对子树发起修改，但是必须是经过属主批准。这样可以保证没处修改都能由理解对应修改的工程师去评审。

更多谷歌代码仓库的信息，可以参考 [17, 18, 21];查看另一个大公司对于同样挑战的应对，可以参考[19]。

2.2 构建系统

谷歌使用分布式的构建系统，名字叫做Blaze，用来负责编译软件和运行测试。它提供了在整个仓库构建与测试软件的标准命令。Blaze标准的命令与高度优化的实现使得任何工程师构建和测试软件简单快捷。一致性是工程师能够跨越项目边界而进行修改的关键因素。

程序员通过编写“构建”文件给Blaze决定如何构建软件。构建元素，比如库、程序、测试通过高级“构建说明”声明它们的名称、源文件、依赖库。构建说明由高级“构建规则”构成，后者说明了一些高级概念比如“这是由一组源文件构成的c++库，并且依赖其他库”。由构建系统将构建规则映射为一组构建步骤。比如说编译、链接、使用什么编译器，什么编译标记等等。

在某些情况下，值得注意的是Go 程序，构建文件能够自动生成（及更新）。因为构建文件中的依赖关系是（通常是）源文件中依赖关系的抽象。即使这样构建文件也会被检入代码仓库，这样保证了构建系统能够通过分析构建文件而非源文件快速确定依赖关系。同时这也避免了构建系统与其所支持的不同编程语言的编译器或者分析工具之间的过耦合。

构建系统的实现利用了谷歌的分布式计算结构。每个构建的负责分布在成百上千个机器上。这使得快速的并行构建大型程序与运行上千项测试成为可能。

单独的构建步骤必须是“封闭”的，只能依赖声明的输入。确保正确声明所有依赖是分布式构建的结果：只有声明的依赖会被发送到构建步骤的机器上。构建系统能够发现真正的依赖。甚至构建使用的编译器都是作为构建系统的输入。

单独的构建步骤是确定的。因此构建系统能够换成构建结果。工程师将他们的工作空间同步到老的改正数，重新构建系统能够得到一样的二进制结果。构建缓存可以在不同的用户之间安全分享。（为了获得确定性的结果，必须要将构建系统使用的工具的不确定因素排除，比如说抹去构建结果中的时间戳）。

构建是可靠的。构建系统追踪依赖的构建规则的改变，知道在构建规则变更时重新构建。即便是当构建的输入没变，仅编译的选项发生变化式。它也能够正确处理构建中断或者构建过程中源文件变更的情况，这时只需要重跑构建命令，而不需要作出类似于“make clean”一样的操作。

构建结果在云端缓存，包含中间结果。如果其他的构建请求构建结果，系统会重用它们而非重新构建，即使请求来自不同的用户。

增量构建非常迅速。构建系统驻留在内存中，当重构命令发出时系统可以增量分析上次构建依赖的修改。

提交前检查。谷歌拥有一套工具，能够在发起代码评审或提交代码前自动运行一系列测试。每个子树含有一个配置文件决定运行什么测试，是否在代码评审时、代码提交前运行测试。测试可以是同步的，比如在评审前或者代码提交前运行（适合一些快速的测试），或者是异步的，将结果发送到评审讨论邮件流中（代码评审在评审邮件流中进行，邮件流的内容也会展现在web端的代码评审工具上）。

2.5 Bug 追踪

谷歌使用一个叫做Buganizer的系统追踪bug、需求、用户问题、进程（比如发布与清理操作）。每个bug都被归类到层次化的模块中，每个模块对应有代理人和邮件cc列表。当提交代码评审时，工程会被提示填写对应的issue id 。

小组定期扫描开放的issue并且将其分配给合适的工程师在谷歌很普遍。有些小组有专人对应bug分类，其他小组则在例会上处理bug分类。很多小组使用标签表示bug分类情况、以及对应在那个版本中解决。

2.6 编程语言

谷歌工程师被强烈推荐使用以下五种官方批准的编程语言之一：C++ , Java , Python ,Go ,JavaScript。最小化编程语言数量有利于程序复用以及工程师之间的协作。

每种语言都有编程风格指南，确保全公司的语言都采用相似的风格、布局、命令规范等书写。另外还有全公司范围的可读性培训，由关注代码可读性的资深工程师通过对受训者的代码修改进行评审、直到受训者学会如何写出具有可读性的代码为止。每次提交代码修改，都需要有参与过“可读性”培训的人员参与批准。

除了五种语言之外，还有很多领域专用的语言用于特定用途（比如构建语言表明构建目标与依赖）。

不同语言之间的交互主要通过 Protocol Buffers 来实现。Protocol Buffers 是将结构化数据高效并且有扩展性的编码的一种方式。它包含一种专用语言表示结构化数据，还有一个编译器用来生成c++,java,python中构建、访问、序列化、反序列号对象的对应代码。谷歌版本的 Protocol Buffers 与谷歌的RPC 库集成在一起，通过rpc框架自动序列化与反序列化请求和应答，实现简单的跨语言rpc。

流程的相通性是确保研发简单容易（即使语言不同或者代码量巨大）的关键。有一套单独的命令集合来执行普通的软件开发任务（比如检出、编辑、构建、测试、评审、报bug等等）。无论什么样的工程或者是语言都可以使用同样的命令。工程师不需要因为他们所编辑的代码是不同的语言或者不同的工程就开发单独的流程。

2.7 调试与性能监控工具

谷歌的服务器上链接了许多用来对运行中的服务器进行调试的库。假如服务器崩溃，有一个信号处理程序自动将调用堆栈写入日志，并且保存core文件。如果崩溃是由于堆内存耗尽，服务器会导出抽样后的实时堆对象的分配点信息。还有检查输入输出rpc、修改命令行标志、资源消耗、性能分析等的web 调试接口。这些工具极大的增加了定位到传统调试工具（如gdb ）不易定位到的问题点的简单性。

2.8 发布工程

只有少数的组拥有专门的发布工程师，对于大部分的组来说，发布工作都是由普通的工程师完成的。

大部分软件都会频繁的发布，周版或者半月版比较常见，有的组甚至发每日版。这是通过将常规发布任务自动化完成的。频繁发布能够帮助工程师保持动力（如果一件东西常年累月不能够发布，就不是那么让人兴奋了）而且通过更多的迭代加快整体速度。而且创造了更多的反馈和响应反馈的机会。

发布通常从空白的工作空间开始，首先同步到最近一次构建成功的版本，然后创造发布分支，发布工程师可以选择(cherry-pick)额外的修改到发布分支，比如说从主分支到发布分支。然后软件会从头开始编译并运行测试。如果所有测试通过，构建结果会被打包。整个发布过程都是自动化的，工程师只需要运行一些简单的命令，或者在菜单上选择哪些修改就可以了。

一旦候选版本打包完成，它将会被加载到“暂存”服务器上，由少量用户（有时就是开发组）进行集成测试。

一个典型的方法是将生产流量的一部分发送给暂存服务器，当然这部分也会被发到生产服务器做真正的处理。暂存服务器的返回被抛弃，生产服务器的结果返回到用户。这样保证了任何严重的问题（如服务器崩溃）都在投入生产前能够被发现。

下一步通常是推送到一或多个线上开发服务器（即“金丝雀”版本），处理线上生成流量。与暂存服务器不同，这些处理最终会反馈给真实用户。

最终发布版会被推送到所有数据中心的服务器。对于高流量、高可靠性的服务，推送在数天之内逐步推送的，为的是减小可能之前未捕捉到的bug导致的影响。

更多谷歌发布工程的信息，参见《SRE Book》的第8章以及参考文献[15]。

2.9 发布准入

任何用户可见的修改或者重大的修改都需要核心开发组以外的一帮人批准。特别是批准要保证代码符合合法性、隐私性、安全性、可靠性（比如说有监控器监控宕机并通知到合适的工程师）、商务性要求。

发布流程也被设计到保证公司里合适的人在新产品、新特征发布时会被通知到。

谷歌有一个内部的发布批准工具用来追踪评审与批准记录、以确保每个产品的发布流程符合定义的发布规范。这个工具容易定制化，所以不同的产品或者产品族可能会有不一样的评审和批准流程。

更多发布流程信息，参见《SRE Book》第27章。

2.10复盘

当生产系统出现严重的停顿或者不测时，当事人都需要写一个事后分析报告。分析报告包含标题、总结、影响、时间线、根本原因、什么有用/没用以及行动项。焦点在于问题本身，以及如何在将来避免它们，而不是责备人。影响部分要试图量化问题的影响，在停机时间，丢失的查询（或者失败的rpc）以及损失的收入等方面进行。时间线部分要给出导致停机的事件、诊断与修复步骤的时间线。“什么有用/没用”的部分给出吸取的教训：哪种事件能帮助快速定位与解决问题，什么做错了（通常以指给对应人的bug的形式记录），什么可以减轻未来发生相似问题的可能性和/或严重性。

欲知更多关于谷歌复盘文化的信息，参见《SRE Book 》的第15章。

2.11频繁代码重写

在谷歌，大部分软件几年就会重写一次。

这可能看起来代价非常大。这的确消耗了谷歌相当一部分资源。然后它能谷歌敏捷与长期成功的关键之一的好处。在几年的周期上，一个软件的需求会变化的非常大，因为软件环境以及相关技术的改变，技术或者市场的变化影响了用户的需求与期望。几年前的软件是在老的需求下开发的，真对当下的需求并不是最优的，而且还积累了一定的复杂性。代码重写可以砍掉为了已经不重要的需求而带来的复杂性，而且，重写能够传承知识而且给小组的新成员带来归属感。归属感对生产效率来讲至关重要：工程师会投入更多的精力到开发和缺陷修复到他们认为是“自己的”代码上面。频繁重写还能够鼓励工程师在不同的项目之中产生流动性，以此鼓励想法的交织。代码重写还能保证代码能够用更现代的技术和方法论编写。

3.项目管理

3.1 20%的时间

工程师被允许花20%的时间到他们选择的任何的项目上，不需要经理或者任何人的批准。对工程师的信任非常有价值，有几点原因。首先它允许任何一个有好点子的人（即使这个想法没有被其他人立刻看到值得一做），拥有充足的时间去开发原型、demo或者讲稿去展现他们想法的价值。其次，它对本来可能暗中执行的东西实现了可视化的管理。在其他没有20%政策的公司里，工程师有时会在不知会管理层的情况下私下进行“臭鼬工厂”项目（即秘密进行的项目）。如果工程师能够公开他们的项目会更好，在日常工作状态更新中描述这些项目。即使他们的工作付出与项目的价值不符合的情况下。公司级别的政策和文化支持这样的事情。第三、允许工程师将小部分工作投入到更有趣的事情里，使得工程师充满激情，阻止了他们工作热情的熄灭（如果他们感到被强制100%投入到无趣的工作中则很容易发生）。充满激情的工程师与热情熄灭的工程师之间的生产力差距可不止20%。第四、这鼓励了创新文化，看到别的工程师在20%工程上进行有趣的实验，其他人也会争相效仿。

3.2目标与关键成果（OKR）

每个谷歌的工程师和小组都要以文档的形式记录他们的目标和为了实现目标的进展评估。小组要设定季度和年度目标，并且要给出可衡量的成果标准。每一层级都要设定目标，一直到整个公司的层面。在每个季度末尾，向着每个量化目标的进展都会记录下来并且给一个0.0（无进展）到1.0（100%完成）的评分。OKR与OKR评分在整个谷歌都是可见的（除非是高度机密的项目），但是这些不会直接用于个人绩效的评估。

OKR需要设置的高一点，期望的平均打分是65%，这意味着每个小组被鼓励设置一个比他们可能完成的进展多一倍的目标。如果一个小组的评分高于65%，那么下个季度会被鼓励设置更具雄心的目标，反之，则会被鼓励设置更保守的目标。

OKR提供了交流公司的每个部分之间工作的关键机制，并且通过社交方面激励工程师有更好的绩效。当工程师们知道自己小组的OKR会开会讨论决定的时候，会有天然的动力去争取更好的评分，即使这和他们的绩效与薪资并不直接挂钩。定义关键成果和可量化指标帮助引导个人的自驱力完成对共同目标产生实际影响的工作。

3.3项目批准

尽管谷歌有定义好的发布流程，但是却没有定义好的项目批准和取消的流程。虽说我在谷歌已经超过10年，自己也当了经理，但是还是不能理解怎么做那样的决定。部分原因是在公司里面这个方法不是统一的。每个级别的经理都对自己小组项目负责，自行决定他们觉得合适的流程。某些情况下，决定是自下而上决定的，工程师在小组的范围里面决定自己做什么项目。某些情况下，决定是自上而下的，由主任和经理决定哪些项目先做，哪些可以获得额外的资源、哪些会被取消。

3.4 组织重组

偶尔主任会决定取消某个大项目，然后每个为这个项目工作的工程师都要寻找新的项目组。

近似的会有偶尔的“碎片重组”效应，多个异地办公的项目会被整合到更少的地点办公，有些地方的工程师会被要求切换项目或者小组。这些情况下，工程师有在他们办公地点中已有的工作职位和角色中选择的自由。或者说，他们也可以选择保留原来的职位而选择去整合后的地点办公。

另外，其他类型的组织重组，比如说合并或者拆分小组，汇报关系变更，看起来发生的很频繁，不知道谷歌跟其他大公司比起来怎么样。在大的、技术驱动的公司，某种程度上技术重组可以避免由于技术和需求改变带来的组织性低效。

4.人事管理

4.1 角色

如同我们将在下文解说到的一样，谷歌将技术与管理线的职级序列阶梯分离；将技术领导的指责与管理分离；将科研嵌入工程化；产品经理、项目经理，运维工程师（sre）共同支持工程师，看起来至少上述实践中的部分对维持谷歌发展出的创新文化至关重要。

谷歌的工程部分有少量不同的角色，每个角色都有对应的职级序列，一系列级别、升职（以及对应的加薪等），来认可下一级别的表现。

主要的角色有：

工程经理。这个是清单中唯一的一个人员管理角色。其他角色中的个人比如说软件工程师也可能管人，但是工程经理一直管人。工程经理通常是前工程师，拥有一贯的技术水平，并且相当的人员管理经验。

技术领导和管理领导之间是有区别的。工程经理不一定带项目，项目是由技术领导负责的。技术领导可以成为工程经理，但通常都是软件工程师。一个项目的技术领导对项目的技术决定有拍板的权力。

工程经理负责拣选技术领导，负责所在团队的绩效。他们负责指导和协助职业发展，进行绩效评估（采纳同行的评价，如下文），负责某些层面的薪酬，以及招聘流程的某些部分。

工程经理普遍直管3-30个人，最常见的是8到12个人。

软件工程师（SWE）

大部分从事软件开发工作的人都是这个角色。谷歌招聘软件工程师的招聘标准是非常高的；通过招聘非常优秀的工程师，困扰其他工程师的软件难题会被避免或者最小化。

谷歌对与技术与管理的职级发展序列是分开的。尽管软件工程师可以管人，或者转岗到工程经理，管人不是升职的必要条件，即使对于最高级别也是。在更高的级别上，需要表现出领导力，不过可以通过很多形式。比如说创作一个优秀的软件，产生巨大的影响或者说被其他工程师使用，就是足够的。这非常重要，意味着技术水平高但是缺乏与人沟通的技巧或者意愿的人仍然有职级发展的道路，而不需要走管理路线。这样避免了一个问题，有的组织的个人为了职业发展担任人员管理职位，但是却忽视了团队中的人员管理工作。

研究科学家

本角色的招聘标准非常严格，门槛很高，要求被论文发表记录证明有杰出的研究能力并且能写代码。很多在谷歌的学界人才可能够格作为软件工程师但是却不够格做科学家。大部分有博士学位的人都是软件工程师而非科学家。科学家通过包含发表情况的科研成果来考评，除了这个和头衔不同之外，科学家和软件工程师并没有什么大的不同。他们都可以做原创研究和发表文章、做新产品和技术、都能够写代码做开发。谷歌的科学家通常和软件工程师结伴工作，在一样的团队中做一样的开发或研究。这种将科研嵌入工程的实践对于降低将新研究成果并入发布产品的难度贡献极大。

站点稳定性工程师（SRE）

作业系统的维护是由软件工程团队维护的，不同于传统的系统管理员类型，SRE的招聘要求和软件工程师的要求略有不同（软件工程技能可以稍低，如果有其他技能比如网络、unix系统补偿的话）。SRE的本质和目的在《SRE book》中讲的已经很好了，我们在这不做进一步讨论了。

产品经理

产品经理负责产品管理工作，从产品用户的主张出发，他们协调软件工程师的工作；向用户传达产品的重要性；与其他团队协调工作；追踪bug和排期；确保每项工作就位，以产出高质量的产品。产品经理通常不自己写代码，但是他们会同软件工程师一同工作，确保他们写出正确的代码。

项目经理/技术项目经理

项目经理的工作大体上与产品经理类似，但是他们管理的是项目、流程、作业（如数据采集），技术项目经理与项目经理类似，不过他们要有和工作相关的专业技能，比如说语音处理的人要求有语言学知识。

软件工程师和项目经理的比例在不同的组织间是不同的，但是比例通常比较高，在4:1到30:1之间。

4.2基础设施

谷歌因为有趣的设施而闻名遐迩，比如说滑梯、球窝和游戏室。这些帮助引发和保持才华。谷歌提供的非常棒的免费咖啡，也是类似的效果，而且巧妙的鼓励员工待在办公室。饥饿绝不是离开的理由，经常安置的“小厨房”，员工可以随便取一些小吃和饮品。它也是交换想法的重要场所，因为很多交谈都是从那开始的。健身房、运动、驻场马杀帮助员工保持有型、健康、快乐，以提高效率和增强记忆力。

谷歌的工位是开放的，经常比较稠密。这样方便了沟通，但是也有争议，有时是个人专注力被破坏为代价的。这样做也非常的经济。

员工都有自己的工位，工位频繁调整（每6-12个月，通常是因为组织扩张的原因），主要是由经理安排的，以方便沟通，因为工位相邻或者靠近更方便交流。

谷歌的会议室都配备有最先进的视频会议设备，与预先计划好的会议进行连接只不过是点一下屏幕的事。

4.3 训练

谷歌鼓励多种方式的员工教育：

新员工（“nooglers”）要参加必修课程；

技术人员（软件工程师和科学家）开始要参加“codelab”：每种技术的在线培训课程，还有编码作业。

谷歌向员工提供很多在线针对个人的培训教程；

谷歌也支持员工在外部机构学习；

而且，每个新人还会被指派一个“导师”和“伙伴”来帮助加速学习。一些非官方的指导也会在与经理的例会、组会、代码和设计评审以及非正式的流程上进行。

4.4 转岗

在公司的不同部分间转岗是被鼓励的。这有助与在不同组织间传播知识与技术，以及加强组织间沟通。在一个岗位12个月并且表现良好，可以申请转岗到其他岗位/办公地点。软件工程师还被鼓励接受临时的一些任务指派，比如说与运维进行6个月的岗位轮换。

4.5 绩效与奖励

谷歌及其强调反馈。工程师可以通过“同级奖金”和“荣誉”互相给予正面反馈。一个员工每年可以两次提名其他任何员工“同级奖金”-100美元现金-因为其超出职责的贡献。只需要填写web上的表单。员工也可以给予“荣誉”一种，形式化的表达对工作的认可，但是没有财务奖励，“荣誉”不需要超出职责的贡献，也没有次数的限制。

经理也可以颁发奖励，包括即使的奖励，比如说项目完成时。与其他公司一样，谷歌的员工也会根据绩效获得年终奖和股票。

谷歌的晋升流程详细而谨慎，涉及到自己提名或者经理提名，自评、同级评审、经理批准。最后由晋升委员会基于上述输入做决定，最后结果取决于委员会进一步的评审。确保正确的人得到晋升对保持正确的激励员工至关重要。

不好的表现，则由经理进行反馈，如果必要的话则包含一份改进计划，设定了固定的目标和进展评估。如果计划失败，则可能开除员工，不过这在谷歌极少发生。

经理的绩效由反馈调查决定，每个员工每年两次要填写他们经理的反馈表，结果匿名汇总到经理处。这种向上的反馈对改进整个组织管理的质量非常重要。

5. 结论

我们简要的描述了谷歌大部分关键的软件工程实践，当然谷歌现在是庞大且分散的组织，组织的某些部分有不一样的实践，不过大部分都团队都遵循本文所描述的实践。

在很多迥异的软件工程实践，以及其他与软件工程实践无关的令谷歌成功的实践一起的情况下，将每个实践与收益之间刻画量化、客观的关联是非常困难的。然而，这些实践在谷歌是经过时间的考验的，他们收到了数千名优秀工程师的主观评价。

对于那些在其他组织中倡导使用谷歌的某一方面的实践的人，也许这么说可以帮助你-“它们对于谷歌来说足够好用”

鸣谢：

略

参考：

略：

原文地址：

Software Engineering at Google