我从谷歌工程师文化中学到的 6 个核心原则

开发 后端
每周,一组谷歌员工都会在厕所的墙壁上粘贴一页来分享本周的测试小建议。有时这页纸会讨论依赖注入,并提供一个简单的示例展示如何用不同语言使用它;有时它可能会分享如何安装一个用于测量团队代码库测试覆盖率的软件。“Testing on the Toilet”起初是个奇怪又有趣的方式,来教给工程师在工作中会用到的一些新的东西,这也被突出为Google文化中的核心力量:向工程师组织有效的传播一系列最佳实践。

每周,一组谷歌员工都会在厕所的墙壁上粘贴一页来分享本周的测试小建议。有时这页纸会讨论依赖注入,并提供一个简单的示例展示如何用不同语言使用它;有时它可能会分享如何安装一个用于测量团队代码库测试覆盖率的软件。“Testing on the Toilet”起初是个奇怪又有趣的方式,来教给工程师在工作中会用到的一些新的东西,这也被突出为Google文化中的核心力量:向工程师组织有效的传播一系列***实践。

[[124916]]

(PHOTO CREDIT: PAUL KELLER

我大学毕业后便加入Google的搜索质量团队,在2006年中旬到2008年中旬在其工作,在这期间,公司的规模从8000人上涨到20000人。在我的***个项目,我同两位***天赋的工程师一起工作,短短六个月,我们原型化、测试并启动了网站的新功能,每天向数百万用户在google.com上展示相关搜索。作为团队的新员工,自始至终最突出的感受是在这样的环境中,公司如何能使像我这样的新工程师快速成长起来。

如果这不是Google工程文化的关键要素,对于我们这样规模的团队在如此短时间内发布新特性是极为困难的。这些要素能够让我迅速地获得Google的代码库、工具和基础设施。它们也是使公司能够达到今天50000雇员规模的原因。

一些前谷歌员工可能抱怨公司变得迟缓和官僚,但是不可否认它已经获得很高的成就和很大的规模,在《财富》评选的100家最适合工作的公司中名列前茅。

这有我从谷歌工程文化中获得的六个核心原则,你可能能够从中获益:

把工程资源用于共享工具和抽象概念。

在早期谷歌在工具和抽象概念上大力投资,例如Protocol Buffers,MapReduce,BigTable和其他在工程中自始至终都会用到的东西。解决问题好的态度并使得每个人能够接受已经带来巨大的收益。每个团队都花费较少的心理周期选择使用哪个工具,专注于工具的团队能够更关注提升工程生产力,和改善已经使用的工具和服务。每个团队可能使用截然不同的工具链,这也意味着当你学习了基本单元结构后,更容易理解许多项目背后的设计。这个方法的负面影响就是有些时候你可能感觉你的case是被强行塞入一个特别的良好支持的工具,即使它不是***的。

在新工程师培训中投资可重复使用的训练材料。

我在谷歌能够迅速变得如此高产的一个原因是公司在培训材料上面花了大力去投资,其称之为Codelabs,Codelabs包括了公司的核心抽象模型,解释它们为什么被设计出来,突出代码库的相关片段,以及通过实现练习验证理解它们。如果没有它,我将会花更多的时间来学习各种我需要去了解的各种技术,这也意味着我的队员要花费更多的精力向我去解释它们。我在谷歌这样积极的经历,强有力的影响了我在后来的Quora新人培训过程中大力推崇Codelabs使用的决定。

标准化编码约定。

每个关于空格、大小写、行长度、是否使用智能指针等约定,可能似乎是不重要的,但是到了谷歌这样的大规模时会带来巨大的影响。我不是***次承认,当代码校验人员挑刺我的代码令我感到十分不愉快,就因为我没有正确的缩进或在行长度超出了规定的两个字符。但是因为大家都遵循同样的约定,使得浏览代码变得大大容易。当更换团队或在跨部门项目中工作时,这几乎没有额外支出去学习新团队的约定。当团队规模很小时,约定是那种很容易被忽视的东西,但是在代码和团队规模逐渐壮大在这方面越来越做出改变,这样你事实上希望从始至终都是一致。如果可能早期在约定一致性上保持一致,或者使用谷歌开源的风格指南。

通过代码复审(Code Review)提升代码质量。

对每次改变进行代码复审减缓了迭代更新的速度,但是提升了代码质量,新工程师收到反馈后,他们需要迅速的采取***的实践并专注于公认的代码质量等级。总体的代码质量越高,也就意味着新工程师在模仿周围人员的代码同时,初期就会写出更加简洁的代码。因此,代码复审有助于公司在较大规模上位置较高的软件质量。

用正确数据解决很多问题。

谷歌研发主管Peter Norvig经常谈到在解决复杂问题上“不合理的数据有效性”。正确的数据能够帮助你了解用户,划分办公室政治,解决争论,并让你跟上进度。开发日志和数据基础工具,如Sawzall和MapReduce,使谷歌的工程师从大量数据中筛选出来变为可能。

自动化测试来衡量你的代码。

谷歌有十分强烈的单元测试文化,“厕所测试”就是一个例子,差不多我每做一次代码的改动都伴随一个单元测试,代码复审员将会严格地检查他们。这让开发变慢,但它也意味着成百上千的工程师可以改变代码库中的同一部分而不会牺牲过多的质量和可靠性。谷歌以同样的方式在共享工具上进行投入,它也会共享测试框架,并通过***的测试实践让大家写测试变得更容易。

当我后来在Ooyala和Quora帮助他们构建团队和产品时,谷歌的工作强烈地让我思考,在哪些地方什么会形成良好的工程文化。然而,在谷歌这样规模的公司工作好并不一定意味着会在不同机构的不同发展时期的工作同样会好。每个工程决策都包括一系列权衡,但是谷歌工程文化提供了一部分权衡,而你可以从这里开始。

原文链接:http://www.techug.com/what-i-learned-from-googles-engineering-culture

 

 

责任编辑:张伟 来源: 程序师
相关推荐

2012-12-25 09:43:08

2021-03-09 09:55:02

Vuejs前端代码

2012-12-26 09:20:30

2019-09-02 22:34:48

2021-07-26 07:47:36

C# 工作面试

2013-08-19 12:46:27

2015-10-21 09:12:17

中国谷歌工程师

2016-01-18 10:06:05

编程

2020-12-31 10:47:03

开发Vuejs技术

2024-04-07 14:11:42

ITGenAI

2020-03-16 14:25:57

软件开发 经验

2012-07-12 00:22:03

创业产品

2020-06-14 15:09:00

JavaScript开发技术

2016-09-21 10:10:50

2015-01-12 10:01:35

2014-09-05 13:37:29

程序员

2015-09-24 09:41:04

Amazon云停机云安全教训

2020-05-19 13:46:33

勒索软件信息安全攻击

2013-10-24 14:51:52

工程师组织

2013-09-17 13:52:00

工程师产品产品文案
点赞
收藏

51CTO技术栈公众号