他山之石,可以攻玉。

话说本人从毕业到现在一直在某 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
    • 某 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 内部大家都不愿意写,我个人认为这个问题确实无解,页面随便一改就导致大量测试失效,我还没见任何一家公司解决