说一下谷歌的开发流程

首先，某 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 来提高效率（重构、自动完成、方便跳转到定义等）