八卦Google的前端开发方式及流程

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 个主要阶段：

1. 代码风格检查

• 应该主要参考这个文档

• 非常严格，据说还会检查命名什么的

• 有段子说 Python 作者 Guido van Rossum 写的 Python 代码无法通过检查，所以一直没提交。。。我认为这是假的，因为他老人家写的 rietveld 还是挺符合某 G 规范的

2. 单元测试检查

3. 代码 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 来提高效率（重构、自动完成、方便跳转到定义等）

　　对于专业做前端的同学，看到 GWT 多半不喜欢，感觉就是多此一举，但如果是 Java 出身的工程师其实是很容易接受的，尤其是对于习惯了 Java 的代码组织方式及强类型语言的人，反而会很不习惯 JavaScript 这种弱类型的语言，觉得太难控制太容易出错了，比如拿到一个变量，在 Java 代码中通过它的类型就能知道它的数据结构，但 JavaScript 就不行了，只能在运行时 console.dir 出来或找相关实现的代码，从我个人体会来看，对于陌生代码，JavaScript 版本的理解难度要明显高于 Java 版本。

　　话说某 G 曾经弄过一个叫 Wave 的产品，后来产品失败后就将代码开源出来了，我认为这个代码能反应出 G 内部在使用 GWT 时的开发风格，我用 cloc 统计了一下它的代码情况，结果如下：

　　神奇吧，这么复杂的前端交互应用，只有 1 个 56 行的 JS 文件，而且其实这个 JS 还是无关紧要的，所以你可以理解为什么某 G 只招懂 Java 或 C++ 的工程师了吧。

　　后来某 G 的 Lars Bak 大神推出了 Dart，在我看来就是用来取代 GWT 的，前面说到的 GWT 优点在 Dart 都有，而且在 I/O 2012 有一个演讲题目是 Migrating Code from GWT to Dart，赤裸裸啊。

　　另外其实某 G 内部也不是所有人都喜欢 GWT，比如 Plus 就没使用，而是直接基于 Closure 开发，并使用 Closure template。

　　说到 Closure，就不得不提它的起源：Gmail，在 WebApps 2010 会议上，有篇 PPT 介绍了 Gmail 代码的情况，以下摘抄其中几个信息：

• 2004 年就有 9400 行代码了，还有个 JS 编译器（Closure compiler 的前身）来压缩代码、检查错误等

• 2005 年有 22000 行代码，10000 行注释

• 2006 年有 52000 行代码，23000 行注释，开始使用面向对象，并初步形成 Closure library

• 2007 年重写，代码达到 90000 行，注释居然有 97000 行（太厉害了。。。），开始出现模块化机制，而且出现了 Closure Templates

• 随后开始内部使用，并最终对外推出了 Closure 系列工具

• 演讲人认为 Type-checking is important and possible

• 有报道说在这个会议中演讲人还透露 Gmail service 也是用 JS 写的，代码有 443000 行

• 对于这个消息，我不确定是否真实，但确实是有可能，08 年时 Stevey Yegge 也说过某 G 的规范有漏洞，没说 JS 只能用在前端，而且他还真这么做过。

　　最后插一句我的观点：对于我所处的团队及用户类产品来说，GWT 没有意义，而 Dart 虽然比起 GWT 要好得多，但和 JS 交互实在太麻烦，导致它的使用场景很有限，语法有明显变化，使得难以让大部分前端工程师接受（Lars Bak 就在 I/O 2013 上吐槽工程师太纠结语法，看起来大神在内部推广时肯定遇到不少阻力）。对于类型检查的好处，我个人是比较赞同的，因此我更喜欢 TypeScript 这 种增强形方案，因为它可以逐步适应，既有类型支持的优势，又能直接使用现有代码。