说一下谷歌的开发流程

首先，某 G 大部分产品线都不区分前端工程师和后端工程师，一我的须要用从前到后都负责开发，尽管这几年彷佛有变化，能看到专门的Front End 职位了，但应该是不多数产品线的作法。

 

N 年前有人去 G 面试过，和他闲聊后了解到某 G 要求应聘者必须至少要会 C++ 和 Java 中的一种，只会 Python/PHP 是不够的，要是只懂 JS 就更不行了。这个信息很关键，能用来解释一些内部现象，后面我会提到。

 

我我的认为前端工程师确实应该了解基本的后端知识，某 B 公司之前不少前端工程师都只负责模板（好比 Smarty）开发，这致使一个很严重的问题，那就是前端工程师每每不知道如何搭建环境，开发时须要依赖后端工程师提供环境和数据，严重影响了开发效率，这也是为何 FIS 还内嵌了本地服务功能。

 

另外国内有公司还对前端工程师作进一步细分，按照职能分为写 HTML/CSS 和 JS 的，对于我所属的团队，我我的并不赞同这种作法，由于 HTML 和 JS 是密切相关的，这样分工将不利于代码管理与优化，尤为是交互复杂的页面，由于 JS 很依赖 HTML，拆分反而增长沟通成本，但或许在重运营的网站这么作会更好。

 

代码管理方法

如下是一些零碎了解到的几点：

 

内部全部人都能看到代码

 

听说在 09 年时某国家的 office 有例外（来自『In The Plex』第 6 章，内容比较不和谐，这里就不展开了）

 

提交代码须要相关人员的 review

 

这使得某 G 内部工程师能够很方便地切换项目，不多一我的只负责一个项目

 

代码只有最新版(trunk)，没有 release 版本，没有版本号

 

通常你们喜欢新增接口

若是要修改原有的接口，就必须通知全部使用方，不过由于全部人都能看到全部代码，因此很容易找到有谁使用

 

据了解某 F 也是这样的

有个代码的搜索引擎

 

我认为这种方式比让工程师写文档靠谱多了，由于绝大部分调用这个库的代码都是类似的，因此直接给出例子能让别人更容易上手

 

估计和下线的 Code Search 比较像（好像仍是某高管写的，不过我忘记在哪看到的了）

 

若是想使用某个基础库，最好的方法是搜索使用到这个库的相关代码，抄过来

 

代码依赖是经过全局的方式统一管理的

 

我猜应该很相似 Chromium 中的 GYP，熟悉 node 的同窗能够理解为 npm，不过是支持多语言的

 

以前在某 G 工做过的 iOS 工程师也在某篇后来删除的文章中透露代码中不放 Xcode 项目文件，而是由工具生成出来（话说这篇文章挺有价值的，惋惜老外不喜欢转帖，致使如今找不到了）

 

这种依赖管理方式让人想起某 A 公司（卖书那个，不是卖水果的）内部完善的 SOA 机制，不过某 A 喜欢基于 service 来重用，而某 G 看起来喜欢代码级别的重用

 

不多使用第三方库

 

只能选用内部维护的版本，好比相似这个 MySQL

 

会将第三方库的编译工具改为内部的，好比 Chromium 中都改为 GYP 方便管理

 

听说想申请用某个新第三方库须要审核，周期比较长

 

代码管理软件用的 Perforce

 

某 G 直接将这个公司买下了（未确认，但下面那篇论文是在某 G 网站上的，因此我感受消息可靠），Perforce 的员工为某 G 内部定制了一套代码管理工具

 

另外我找到一篇 Perforce 的性能优化的论文，这里面透露了不少 G 公司内部的代码状况（发表时间是 2011 年 5 月），如下信息取自这篇论文：

 

这个程序用了 17 年，有 2 千万次 changelist（能够理解就是 ci 数量）

 

最大的 client 有 6 百万个文件（应该绝大部分是数据吧，要知道 chromium 项目也就不到 30 万个文件）

 

文档及相关数据文件也放上面

 

Reivew 工具叫 Mondrian（确认就是 Rietveld 的前身）

 

总体来讲某 G 的代码管理方式有不少可取之处，尤为是代码开放，能最大程度地调动开发人员的主动性与协做意识，从而创造出更大的价值。不过没有版本管理这点是个双刃剑，我也没想好是否这样会更好。

 

feature flag

 

由于没有分支，代码只有一份，因此要实验新功能就得经过 flag 来控制的，这个 flag 由线上 Borg 系统来管理，能作到针对某一部分的 Cookie 开启不一样的 feature，方便进行对比抽样。

 

若是某个功能最终不上线，后续须要手工删除相关代码。

 

这个 flag 开关功能在某 F 也有，我认为这是大型网站是必备功能，但须要注意，这个系统自己会成为关键节点，以前某 F 的相似系统挂过，直接致使整个网站大部分功能都关闭了，因此一旦出问题后果很严重。

 

严格的代码检查

 

听说某 G 工程师大部分时间在写单元测试，单元测试能够保证 UI 无关代码的质量，但对于页面测试就很难了，虽然可使用 selenium，但某 G 内部你们都不肯意写，我我的认为这个问题确实无解，页面随便一改就致使大量测试失效，我还没见任何一家公司解决（某 F 说他们用的是 Watir，但主要用于保证登陆等基本功能可用），目前看来惟一可行的就是自动页面截图 diff，某 G 在 Consumer Surveys 这个产品中也在尝试。

 

听说某 G 的项目大多没有严格的上线时间点，因此不能以项目紧急为借口来不写单元测试，这点和天朝不太同样，你们更倾向牺牲质量来追求速度。

 

另外国外公司通常对浏览器兼容性问题都不怎么关注，由于现代浏览器中的兼容性问题比之前好得多，这点某 G 和某 F 公司同样，只支持高版本的 IE。

 

由于只有主干，因此提交代码很谨慎，须要通过 3 个主要阶段：

 

代码风格检查

 

应该主要参考这个文档

 

很是严格，听说还会检查命名什么的

 

有段子说 Python 做者 Guido van Rossum 写的 Python 代码没法经过检查，因此一直没提交。。。我认为这是假的，由于他老人家写的 rietveld 仍是挺符合某 G 规范的

 

单元测试检查

 

代码 owner 的 Review

 

提交一旦出错可能会致使影响其它人的工做（由于每一个人都依赖主干啊），甚至遭到其它国家 office 工程师的指责，因此你们对于代码提交都很是谨慎，再三确认，压力不小。

 

在单元测试、代码风格和 review 的执行上，某 G 作得很完全，这点值得学习，国内你们彷佛更喜欢开发效率而不是质量。

 

前端如何开发

 

除了 Gmail、Maps、Plus 这样的特例，基本上都是由后端模板生成页面，不多项目使用 JS 来写界面，更少使用 MVC 框架，这点其实在不少公司都差很少，好比某 B 也是同样的，除了地图及广告管家等产品，其它产品基本上都是经过模板生成的。

某 G 的页面是一般是由 Java 或 C++ 语言所写的模版引擎生成的，并且开源出来了，分别是 Closure,Templates 和 CTemplate，话说某 B 在几年前也本身写了个 C++ 的模板引擎，但目前基本被淘汰了。

对某 G 来讲，「前端」工程师要写 Java 和 JavaScript，而「后端」服务主要是 C++（某些地方开始使用 Go 了，好比这个）。

前面说到招人时都要会 Java，这带来的结果是大多数团队成员更了解 Java 而不是 JavaScript，因而在这种背景下很天然地诞生了 GWT 这个神奇的东西，它在内部不少地方使用，按照内部人士的说法，主要的考虑是：

 

能自动生成跨浏览器浏览器代码

 

结构规范，经过编译器就能提早发现不少问题

 

能使用强大的 IDE 来提升效率（重构、自动完成、方便跳转到定义等）