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

　　话说本人从毕业到现在一直在某 B 公司工作，前些年折腾过不少开发方式和工具，但总觉得或许有更好的方案，所以很好奇其它公司内部是如何工作的，我曾经浏览过某 Y 公司内部无所不包的 TWiki，也拜访过某 F 总部了解他们的开发流程，但对某 G 公司却了解不多，只零零碎碎知道一些，这两天抽空梳理了之前收集到的各种资料，希望能给 FEX 后续改进提供参考。

注意：以下内容主要信息来自网上收集、『In The Plex』这本书及闲聊，纯粹为了技术交流和讨论，仅代表个人观点，本人从未在某 G 工作过，不受 NDA 限制，但大部分信息无法确认真伪，加上某 G 很大，每个部门都有可能不一样，所以这里的信息也是比较片面的，欢迎大家提供更多参考信息。

分工协作

　　首先，某 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

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

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

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

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

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

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

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