[译] Google 教我有关扩展软件开发团队的几个要诀

原文: What Google Tought Me About Scaling Engineering Teams

本文由 The Effective Engineer 作者 Edmond Lau 授权翻译，Soft & Share 获作者授权翻译。

--------------------------------------------------------------------

每周，一群 Google 员工会在世界各地办公室的洗手间门板上粘贴一页纸分享这一周的测试技巧。某一周，可能讨论dependency injection，并提供在各种语言如何使用它的简单范例; 另一周，可能分享如何设置一个工具来测量团队代码基底(codebase)的测试覆盖率。 “测试在洗手间”(注1) 的首创精神是一个古怪和有趣的方式来教工程师新的和有用的知识，如同他们正在进行自己的业务。 如此也强化了Google工程文化的一个关键优势：有效地向大型工程组织的成员传播一套一致的、有见地的最佳实践。

我在大学一毕业就加入了 Google 搜索品质小组，从2006年年中至2008年年中，公司从大约8000名员工增长到近20000名。 (注2) (注 3) 我在我的第一个项目中与两位非常有才华的工程师合作，在短短的六个月内，我们在google.com上进行原型、测试和推出了一个新功能，每天向数百万用户展示相关的搜索。身为团队中象征的Noogler (google 新进工程师)，在整个体验中令人印象深刻的是，公司如何能够让像我这样的新进工程师很快融入团队并高效地工作。类似 StarTrek 的Borg 种族，(注 4)公司已很精通同化新工程师的艺术。

如果没有 Google 工程文化的某些关键元素，像这样规模的团队要在短时间内发挥影响力发布新功能是非常困难的。 这些元素使我能够在短时间内很快地了解Google的代码基底(codebase)、工具和基础架构。也是同样的元素，使公司达到目前的规模，拥有超过50,000名员工。一些前Google 员工可能会抱怨怎么公司已经变得这么缓慢或是官僚，(注 5)但不可否认的是，它仍然能够在如此大的规模下达到高水平的成功，也是 Fortune 100强最值得工作的公司。

以下是我从 Google工程文化中学到的六个核心原则，你可以从以下各项中学习：

• 致力共享工具和抽象(abstractions)的工程资源。 从很早以前起，Google对于整个工程组织共用的工具和抽象(abstractions)，如 Protocol Buffers、MapReduce、BigTable等方面密集地投资，。 这种好好地一次把问题解决然后让所有内部的人都能采用的态度最终获得很高的回报。 每个团队不用花太大的心力去考虑要使用哪些工具，有专门的工具团队服务且专注于改善，提高工程团队的生产力，这些改善很容易传播给每位已在使用工具或服务的人。和既有的工程组织（每个团队可能使用非常不同的工具链）形成对比，这一理念也意味着，一旦你已经知道基础的建构区块后，便能很容易地理解许多项目背后的设计。这种方法的缺点是，有时你可能会被迫把你的使用案例做些调适，以配合某些特殊支持的工具，甚至它对于你目前的工作来说不是最好的。
• 为新进工程师投资可重复使用的培训教材。我能够迅速在Google中有生产力的原因之一是因为Google一直以来投入大量资源投入到名为 codelabs 的培训文档中。 Codelabs包含了公司的核心抽象层(core abstractions)，解释了为什么它们被如此设计，突显程序库中的相关片段，然后通过几个实践的练习验证理解。没有这些，我需要更多的时间来了解我能有效率工作所需要知道的众多技术，这也意味着我的同事不得不花更多的时间向我解释这些知识。我在Google Codelabs的正面经验强烈地启发我后来在Quora的到职流程推动codelabs的决心。
• 标准化编程风格。关于空格、大写、行长、是否使用智能指针(smart pointers)等的每个约定可能单独看起来微不足道，但是当你达到Google的规模时，具有巨大的影响。我不会是第一个承认，当代码审查者对我的代码挑三拣四，只因为我不正确地缩进一行或因添加两个字符而超过规定的行列长度很烦的人。 但是因为每个人都遵循相同的规定，浏览原代码明显地容易许多。在交换团队或处理跨功能项目时，将需要费点功夫来学习新团队的规定。 当你的团队小的时候，很容易就忽略的像规定这种事，但随着代码基底(codebase)和团队成长到某个程度，需要花在变更上的力气越来越多，你会开始意识到需要一些一致性。 如果可能，尽早规划团队一致的规定，或者也可直接使用Google开源的样式指南(style guides)。
• 透过代码审查提高代码品质。要求代码审查并为每个更改以程序来强制运行，减慢了迭代速度，但优化了代码的品质。新进工程师将由于收到他们需要的回馈，可快速掌握最佳实践并收敛代码的品质到可接受的水准。整体上有更高品质的代码意味着新进工程师以这品质起始建模，如此将更有可能一开始就写出更干净的代码。 因此，代码审查是有助于公司扩大规模还能让所开发的软件维持高品质的流程。
• 取得正确的数据(而且要很多)来解决许多问题。 Google 研究部主任 Peter Norvig 经常谈到“数据由不合理变有效” (注6)(注7)(译注 : 经由合理化模型将许多混乱的文本、图像和影片变成有效消息)，以解决复杂的问题。 正确的数据可以帮助你了解用户、分析办公室政治、解决争议，并追踪进度。开发日志和数据基础架构（例如Sawzall和MapReduce）使Google的工程师可以筛选大量数据。
• 自动化测试以扩展你的代码。 Google 有非常强大的单元测试文化，“测试在洗手间”是其中一个明显的案例。几乎每一个我所做的代码修改都伴随着一个单元测试，代码审查人员将严格检查它们。这使得开发一个指定的变更比较慢，但也意味着成百上千的工程师可以在代码基底(codebase)里相同的部分做扩充与修改，而不牺牲太多的品质或可靠性。 类似投资共享工具的作法，Google 也共享测试框架并致力最佳测试实践的教育训练，让写测试更加容易。

后来我到Ooyala和Quora帮助创建产品和团队时，在Google有效的实践方法（以及无效的）强烈地告诉我要针对我所待的地方想想做什么能创造良好的工程文化。在Google规模的环境运作良好的决策并不一定会在不同成长阶段的组织有效。 每一工程方面的决策都牵涉到一整组的取舍，不过Google的工程文化提供一套很不错的取舍参考标准帮助你开始。

此文源自作者在 Quora 一则回复