他山之石,可以攻玉。

话说本人从毕业到现在一直在某 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 内部大家都不愿意写,我个人认为这个问题确实无解,页面随便一改就导致大量测试失效,我还没见任何一家公司解决(某 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 统计了一下它的代码情况,结果如下:

----------------------------------------------------------
Language files blank comment code
----------------------------------------------------------
Java 2329 50121 139226 245856
Python 34 1308 2537 4451
CSS 57 617 1670 2791
XML 148 1009 2627 2487
Ant 15 131 335 987
HTML 8 124 155 831
Bourne Shell 9 61 190 185
Javascript 1 12 26 56

神奇吧,这么复杂的前端交互应用,只有 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 这种增强形方案,因为它可以逐步适应,既有类型支持的优势,又能直接使用现有代码。

内部工作流程

以下是打听到的某个产品项目开发流程:

  • PM 或工程师提出某个想法,UX 做原型 mock
  • PM 申请项目审核(通过率不高)、工程师开发 UX 无关部分
  • 工程师完成开发
  • 线上小流量实验
  • PM/工程师分析实验结果,完成报告,申请全量上线(通过率不高)
    • 通过数据来证明这个功能是有价值的
    • 需要解释这些数据的变化原因
  • 分批逐步上线,这个过程中还会有很多审核
  • 最终确定是否要上线(通过率不高)

一般整个项目周期很长(至少一季度),项目最终上线时间点无法确定,大部分的项目最终都无法正式上线。

最大的特点是完全靠数据说话,而不是由某个 PM 决定一切,以前有个视觉设计师在离开 G 后就在博客上吐槽这点,他认为这会导致无法进行大胆的界面改版。

这个流程和我们搜索产品几年前的开发流程很类似,对于成熟的搜索引擎来说这么做确实有它的道理,毕竟随便改个什么都很可能影响收入,当然要十分谨慎了,但这种开发方式并不适合面向用户类的产品,如社区、游戏等,因为开发周期太长了,很容易错过时机。

某人一天的工作

这里拿 Matt Welsh 来举例介绍一个工程师在某 G 一天的工作,虽然他不是做前端开发的,但他目前在 Chrome 团队负责[移动 Web 性能优化]((http://matt-welsh.blogspot.com/2013/04/running-software-team-at-google.html),所以还是比较相关,而且最重要的是他比较喜欢写博客,有意无意地透露了很多信息,所以我比较好公开谈。

另外话说他之前还是哈佛的计算机终身教授(!!!),八卦很多,比如差点说服小扎同学不要搞什么社交网络了,还是好好学习拿毕业证书。。。

这篇文章里,Matt Welsh 介绍他的一天是如何度过的(另外还提到了在哈佛当教授是如何度过的,也很有意思),我摘抄如下:

  • 9:00,到公司,查邮件
  • 9:30-10:15,写代码,增加功能,编写单元测试,发起 changelist 代码 review,喝无糖可乐
  • 10:15-11:00,切换 git 分支到其它项目,查看同事 review 代码的结果,回复评论并发新版本 changelist
  • 10:00-11:30,再次切换 git 分支,提交一个要运行 3 小时的 MapReduce 任务分析网络延迟日志
  • 11:30-12:00,和山景城的团队成员开视频会议
  • 12:00-12:35,午餐
  • 12:35-14:00,检查邮件,检查 MapReduce 任务运行状态,回复代码 review 的评论,再次提交代码,然后查看任务列表确定接下来的工作
  • 14:00-15:00,和在剑桥(有评论指出这里是波士顿的剑桥,不是英国那个)、山景城等多个地区的团队成员开项目会议
  • 15:00-16:00,喝红牛,这时 MapReduce 任务已经跑完了,生成图表,分析数据中不符合预期的部分,整理代码,准备下一次 MapReduce
  • 16:00-17:00,喝苏格兰威士忌(scotch)并玩吉他英雄(Guitar Hero)
  • 17:00,收拾笔记本回家

看完后我的几点体会是:

  • 前面提到的代码只有 trunk 并不准确,当然每个部门确实可能不一样
  • 代码 review 做得很认真
  • 看起来任务很明确,所以虽然工作时间是 9-5,但效率挺高,这点我最为好奇的,怎么做到将工作安排这么具体?
  • 除了写代码,分析数据也是每天的重要工作,具体分析什么可以通过他的论文了解,看得出来是很细致的

内部工具

2008 年前的内部工具情况可以通过这篇文章这个 PPT 了解,不过之后就不清楚了,看起来很多外部工具都有内部版本(Docs、Mail、Talk、Calendar 等)。

这里说一下 Chromium 项目中我看到的工具使用情况:

  • 网站是基于 Sites 搭建的
  • 设计文档喜欢使用 Docs,因为可以在线编辑和评论功能,所以多人协作会很方便
  • https://codereview.chromium.org/
  • 在 Groups 中进行讨论
  • 使用 code 来管理 issues
  • Buildbots 来进行编译和集成测试
  • 搭建了各种检测工具来保证质量,具体细节推荐读这本书,看完这本书我最大的体会是没什么神奇的东西,完全靠细心的工作

可用的石头

以下是我认为可以借鉴的地方:

  • 源码不分版本,对内部所有人公开
    • 在 FEX 内部已经是这样了,但我们应该推动更广泛的开放与共享
  • 严格的代码规范及单元测试机制
    • FEX 所有项目将接入 Travis CI
    • 代码规范及单元测试的强制检查
    • 代码 owner 的 review 机制
  • 通过实际例子来使用,甚至不用看文档
    • 加强对 demo 及 example 的要求,不能是简单的 hello,而最好是从产品线实际使用案例中抽取出来
  • 文档及相关资料和代码放一起
    • 这能保证找起来很方便
    • 如果由于种种原因不能放一起,至少也要放链接
  • 外部产品有内网版,比如 Docs
    • 典型的 Eating your own dog food
    • 在内网提前测试外部产品的新功能,而且一般内部人员都会很积极地吐槽,对产品改进很有帮助
  • GWT 的静态检查机制
    • 整理这篇文章时我发现 TypeScript 也已经接近 1.0 版本了,看起来时机快成熟了,后续计划尝试 TypeScript
作者:nwind (http://wuduoyi.com/) - 我可以学 

八卦某 G 的前端开发方式及流程的更多相关文章

  1. 八卦某 G 的前端开发方式及流程--百度FEX前端nwind信息搜集神技能

    他山之石,可以攻玉. 话说本人从毕业到现在一直在某 B 公司工作,前些年折腾过不少开发方式和工具,但总觉得或许有更好的方案,所以很好奇其它公司内部是如何工作的,我曾经浏览过某 Y 公司内部无所不包的 ...

  2. css背景精华所在+前端页面开发流程

    background属性 background属性是css中应用比较多,且比较重要的一个属性,它是负责给盒子设置背景图片和背景颜色的,background是一个复合属性,它可以分解成如下几个设置项: ...

  3. 【JavaScript】停不下来的前端,自动化流程

    http://kb.cnblogs.com/page/501270/ 流程 关于流程,是从项目启动到发布的过程.在前端通常我们都做些什么? 切图,即从设计稿中获取需要的素材,并不是所有前端开发都被要求 ...

  4. svn迁移gitlab,构建前端打包发布流程

    前端资源迁移     目前公司的前端资源托管在svn服务器上,由于团队的逐渐扩大,svn的分支管控越来越不灵活,而且对于以后前端流程一体化的处理支持不是很好,因此决定在版本控制上转向git.git的好 ...

  5. 前端开发工程师 - 05.产品前端架构 - 协作流程 & 接口设计 & 版本管理 & 技术选型 &开发实践

    05.产品前端架构 第1章--协作流程 WEB系统 角色定义 协作流程 职责说明 第2章--接口设计 概述 接口规范 规范应用 本地开发 第3章--版本管理 见 Java开发工程师(Web方向) - ...

  6. 前端可视化项目流程,涉及three.js(webGL),3DMax技术,持续更新

    最近在做一个可视化展示的项目,记录一下流程: 建模,模型来源,可以参考沙盘展示类项目,自己建模或者拼装其他源模型(本人以前是3D建模师,可以应付一些简单的场景) 有效模型导入到web端,这里采用的ob ...

  7. Grunt usemin前端自动化打包流程

    前端优化是尽量减少http请求,所以我们需要尽量合并压缩文件,然后调用压缩后的文件,比如多个css文件压缩成一个,多个js文件合并压缩等,usemin能够自动在html中使用压缩后的文件,达到上面的目 ...

  8. 使用npm构建前端项目基本流程

    现在各种前端框架, 库文件基本都托管到npm上, 我们平常下载到别人的项目文件, 也基本是用npm 构建的, 不了解点node和npm那是寸步难行. 下面介绍的代码示例不敢说是最佳实践, 但都是我亲自 ...

  9. vue项目搭建通过vue-cli包括组件路由的使用实现基本的前端项目全流程

    github上项目地址:https://github.com/comonly/javaweb_blog/tree/master/blog_diverse_frontend 具体搭建流程及实现方式:ht ...

随机推荐

  1. iOS真机调试——Certificates, Identifiers &Profiles 简介

    Certificates, Identifiers &Profiles 简介 每次到这个页面,我都不知道这几个选项是干啥的,我相信有很多同学跟我一样,所以首先我们就来先介绍下Developer ...

  2. jQuery技术内幕电子版5

    4. 转换HTML代码为DOM元素 先创建一个文档片段DocumentFragment,然后调用方法jQuery.clean(elems, context, frag-ment, scripts)将H ...

  3. SharePoint 命令使用集锦 (持续更新中...)

    首先要定位到 cd "Program Files\Common Files\Microsoft Shared\web server extensions\14\BIN" 下面   ...

  4. HW3.3

    import java.util.Scanner; public class Solution { public static void main(String[] args) { Scanner i ...

  5. 在VirtualBox中安装了Ubuntu后,Ubuntu的屏幕分辨率非常小,操作非常不便。通过安装VirtualBox提供的“增强功能组件”,-摘自网络

    在VirtualBox中安装了Ubuntu后,Ubuntu的屏幕分辨率非常小,操作非常不便.通过安装VirtualBox提供的“增强功能组件”,可以解决这一问题,并且使用非常方便. 一.环境 | En ...

  6. [struts2]struts标签遍历map[转]

    转至:http://hanxin0311.iteye.com/blog/1745792 private Map<String, String> strMap = new HashMap&l ...

  7. 安装、配置JDK的步骤

    1.配置环境变量,打开我的电脑--属性--高级--环境变量,新建系统变量JAVA_HOME .变量值:jdk的目录,比如d:/java.选择“系统变量”中变量名为“Path”的环境变量双击该变量,把J ...

  8. C# ip hash算法实现ip分流

    private void button42_Click(object sender, EventArgs e) { Dictionary<int, string> proxyIpNodes ...

  9. bootstrap-table对前台页面表格的支持

    1.bootstrap-table是在bootstrap的基础上面做了一些封装,所以在使用bootstrap-table之前要导入的js和css有 1)基本的还是jQuery <script t ...

  10. Win8启用便签

    启动或显示 Sticky Notes : Win+R--->StikyNot.exe 备份Sticky Notes保存位置 : %AppData%\Microsoft\Sticky Notes\ ...