腾讯Now直播前端工程化的实践之路

腾讯Now直播前端工程化的实践之路

受访嘉宾 | 程柳锋
编辑 | Yonie
在百花齐放的前端圈，层出不穷的组件框架已让前端开发者目不暇接，另外，再加上业务和开发团队的不断发展，前端开发人员面临的问题愈来愈多。日渐突出问题主要为：如何高效的与团队成员进行合做开发？项目愈来愈多，不一样技术栈的项目如何统一维护？如何制定和践行统一的开发规范？如何高效的部署和发布产品？
这个时候 前端工程化 概念的出现，解决了上面让开发者头痛的问题。它旨在制订规范化的前端工做流，并规范统一项目的模块化开发和前端资源，让代码的维护和互相协做更加容易更加方便。同时，让你们可以释放生产力，提升开发效率，更好更快地完成团队开发以及项目后期维护和扩展。
可是前端工程化具体是如何实践的呢？带着这样的问题，咱们采访了参加本次 ArchSummit 全球架构师峰会的腾讯 Now 直播产品 IVWEB 团队社区、工程化的负责人——程柳锋，程老师与咱们分享了腾讯 Now 直播在前端工程化上的具体实践方案。如下是本次的采访内容：
InfoQ：请您先作下自我介绍吧。
程柳锋：我是程柳锋，来自腾讯，前后参与腾讯 NOW 直播、NOW 语音交友、手 Q 群视频、群送礼等与直播相关的的泛娱乐产品的开发。另外我仍是整个腾讯 IVWEB 团队社区、工程化的负责人。现阶段主要关注团队的工程化建设，包括新技术的预研和落地，另外也积极探索行业前沿技术好比：WebAssembly、PWA 等。
InfoQ：一线开发人员参与前端项目过程当中须要关注哪些因素？
程柳锋：在产品迭代过程当中，前端的定位每每是处于应用层，负责 UI 开发和用户交互体验的工做。你们平常开发时接触的 To C 的产品居多，好比 BAT、美团、滴滴等大厂的产品。这类产品的量级比较大，基本上日均 DAU 能达到几百、几千万，甚至过亿。所以，这类产品对用户体验要求很是高，一个微小的 JS 脚本错误很容易引起血案。
以咱们团队为例，对于每一位开发者都有较高的专业能力要求，一般概括为三个要素。按照重要性顺序以下：

• 首先，是质量，开发者作出来的项目，其质量必须获得良好的保证，咱们也会在项目上线前经过完善的监控手段保障质量。好比：JS 脚本错误监控、接口成功率监控、测速监控、HTML/CSS/JS 加载成功率监控等等。
• 其次，是产品的性能。咱们但愿页面加载时首屏的白屏时间尽量短，至少达到秒开的加载体验。另外，还须要保证在弱网络的状况下，页面也可以很好的展现。

• 最后是研发效率，就是如何在较短的时间内，快速地进行业务需求的开发和上线。
  InfoQ：如今腾讯上线前端项目，或者说升级项目版本，大概须要多长时间呢？
  程柳锋：上线时间会根据具体的项目类型地变化而变化。咱们内部总体采用敏捷开发模式，一般一个项目从启动到上线在 2～3 周，其中一周为开发时间，一周为测试上线的时间。
  另外，对于重点攻坚项目咱们以前也有大胆的尝试。举个例子，在 2018 年年初时，直播领域里的答题玩法特别火爆。各家直播平台好比：花椒、映客、熊猫直播，包括腾讯、高德地图、支付宝等都在作直播答题的应用。咱们当时作这种攻坚项目，第一个版本从产品方案设计到最后上线发布仅仅花费两周时间。相对来讲时间仍是很是紧凑的，对一线开发人员做战能力有着较高的要求。
  InfoQ：前端工程化是您负责的重要工做之一，它都包括哪些内容呢？
  程柳锋：前端工程化是一个团队的基础设施之一，它更加偏向工程架构、研发流程相关的内容，主要有这样几个目的：

• 随着业务的快速发展，产品需求爆炸式增加，团队成员不断扩充，前端工程化的首要目的就是知足快速发展的业务须要。前端工程化须要标准化研发方式、研发流程（开发、测试、发布、线上监控），让你们从建立项目到最终项目上线、监控使用相同的开发习惯。这个是前端工程化的主要目的。

• 第二个目的，把团队的经验（好比作项目时踩的坑、通过试验得以验证的新特性等）沉淀到脚手架和开发套件中，使其余同窗在开发新项目时能够复用这些经验。

• 第三个目的是关注新技术的前端工程化落地场景，好比最近比较火的 Serverless、Flutter、小程序等技术。经过工程化的方式把新的技术与现有项目结合进行试验，试验成功后抽成脚手架和开发套件，其余同窗后续开发这类工程也特别简单，节省了其余同窗再次探索新技术的时间。让整个开发体验更加顺畅。
  InfoQ：前端工程化是何时提出来的？背景是什么？
  程柳锋：大约在 2010 年左右前端工程化的概念开始萌芽。前端工程化的提出，主要有如下两个缘由：

1.业务场景的不断的复杂，不少事情须要前端去承载。像 H五、跨端应用，以及如今 WebAssembly、PWA 等新技术，他们的出现都让浏览器端能够承载的事情更多了，不少业务逻辑由服务端、客户端迁移到了前端。

2.2009 年 Node.js 的兴起给前端工程化提供了工具层面的支持，如今你们写的构建工具、脚手架工具、代码规范检查，以及咱们作的 Pre Render，都是在 Node.js 的基础之上作的。前端工程化的概念还须要经过工具来加以践行和佐证，咱们经过 Node.js 编写 CLI 或基于 nw.js/Electron 的 GUI 工具，在项目的建立阶段，你们可使用统一的命令来建立项目、页面或组件；在项目的开发阶段，针对不一样技术栈的项目可使用不一样的开发套件进行本地开发、调试、和规范检查。
InfoQ：从 2009 年到如今也有 10 年的时间了，你以为如今前端工程化大概发展到什么阶段了？
程柳锋：前端工程化的价和团队规模成正相关的关系，团队规模越大，工程化的价值就更高。能够分为几个阶段：

• 第一个阶段：初创的团队，团队人数大约在十人以内，这时候前端工程化的主要做用是规范开发、协做规范。这个阶段团队人数相对比较少，你们经过简单的规范约束基本能够知足需求。
• 第二个阶段：团队规模在快速扩大，内部员工流动比较大，这个时候让你们都遵照以前制订的规范是比较困难的。经过工程化的 CLI/GUI 工具、脚手架、开发套件和插件，保证项目从建立到本地开发、测试，再到最后的发布、监控都可以正常的运转。
• 第三个阶段：团队若是达到必定规模（大约在 100 人以上），或者多个部门共同参与前端工程化的建设，从而有效的避免不一样部门重复造轮子的现象。
  InfoQ：在前端工程化的趋势下，CLI 和 GUI 这两个工具开发的背景是什么？解决了什么问题？
  程柳锋：若是把前端工程化分层的话，CLI 和 GUI 就是在最顶层。它们是直接和开发者进行交互的，最核心功能是规范开发流程。CLI 是命令行的形式，GUI 是图形界面的形式。中间层便是工具平台和规范，开发者经过 CLI 或 GUI 便可调用工具平台，快速打通与工具平台、开发规范的联系。底层为基础设施。咱们目前已在五个业务场景应用了 CLI 工具，分别是五个不一样技术栈的业务场景：商业化的运营活动、APP 内嵌的 H5 页面、ReactNative、Serverless、组件。
  InfoQ：前端工程化的脚手架能为开发人员缩短构建项目的时间，同时提升开发的效率，请您说一下前端脚手架的构建现状。能够从腾讯的构建现状或者业界的构建现状来说一下吗？
  程柳锋：这两个均可以说一下。咱们先来聊一聊整个行业的形态，如今市场上比较流行的前端框架主要是有如下几个：React、Vue、Angular、Weex。这些框架各自所对应的脚手架都只能开发本身技术栈的项目。而实际开发中，咱们须要面临不一样技术栈的开发场景，单一技术栈的脚手架没法知足需求。
  其次，使用的官方脚手架所包含的功能是最基础、最通用的。在腾讯的实际业务场景中，针对一些细粒度化的业务仍须要作二次定制。好比平常中须要上报的各类数据：监控信息、JS 数据、VIP 白名单日志、接口接口调用成功率、首屏渲染时间、HTML/CSS/JS 加载成功率等，用行业通用的脚手架彻底不能知足咱们的要求。咱们在行业脚手架的基础上进行维护，二次定制具备咱们业务特点的脚手架。
  咱们团队目前在这个背景下作了一个更加通用的技术方案。该技术方案基于 Yeoman，在 CLI 里面的集成了 Yeoman 的 Runtime。截止到如今为止，咱们公司内部总共有十个脚手架左右，你们能够共同维护这些脚手架，并进行二次定制。经过上层统一的 CLI 命令在建立项目时就能够选择使用哪一个脚手架。
  InfoQ：如今前端使用 Webpack 构建工具比较多，与以前使用过的构建工具相比，Webpack 的优势是什么？
  程柳锋：我我的以前用了不少种构建工具，如 YUI Compressor、Grunt、Gulp、Fis3 和 Rollup 等，目前咱们已经完成大部分业务从 Fis3 切换到 Webpack4，其中他们的区别主要有如下几点：
  1.从插件生态上来看，Webpack 相对 Fis3 拥有更高的维护频率（即发版节奏快）。从 Webpack1 到 Webpack5，基本上每一年出一个新版本。目前 Webpack4 已经正式发布了，Webpack5 也已经在 alpha 阶段，整个社区 Webpack 贡献者也不少，当你们遇到问题并提交 issue 至社区，问题均可以获得解决。

2.另外，Webpack 能够作的事情有不少。整个社区的 Loader、插件十分丰富。好比 HappyPack，其多进程多实例打包方案能够实现快速打包，相对 Fis3 来讲，其打包效率是很是高的。包括如今 Webpack 官方也原生提供了 thread-loader，也能够经过它进行多进程多实例的快速打包，从而让打包时间获得极大的优化。

3.Webpack 和其余构建工具的差异在于 Webpack 打包理念是革命性的。Webpack 把全部的资源都当作模块（好比 JS、CSS 图片、字体，或富媒体的文件等）。与其余构建工具相比，Webpack 最显著的特征是它经过各类 loader 去处理模块，这也是你们为何一直叫 Webpack 模块打包器的缘由。Grunt 和 Gulp 的构建过程都是以 Task Runner 的方式去作的。Gulp 是流式的构建，而 Grunt 每次的构建产物会存储到本地的 tmp 目录中，Gulp 是直接放到内存里，构建的时候相对 Grunt 更快一点。
InfoQ：腾讯把构建工具从 Fis3 迁移到了 Webpack4？在切换的过程当中有没有遇到什么困难呢？又是怎么解决的？
程柳锋：咱们当时切换的时候确实遇到了不少困难。第一个困难是 Fis3 里面支持了一些比较好的特性，而在 Webpack 却没有。这里面也能够举一些咱们在实际迁移过程当中遇到的例子，好比说 Fis3 支持 inline 语法，能够将 HTML 片断引用到另一个 HTML 中，也能够将一个图片 inline 过来自动 Base64，还能够合成雪碧图，总的来讲它能够精细化的控制资源。但在 Webpack 中是不支持 inline 语法、雪碧图的合成。咱们解决的方案是实现相关的 Loader，好比 inline Loader。对于雪碧图的 sprites-loader，在项目迁移的过程当中咱们把 Fis3 的资源内联语法 (?_inline) 和合成雪碧图语法 (?_sprite) 作了下兼容，新旧项目中都支持了。
其次，Fis3 中支持资源引入时的绝对路径写法，在迁移至 Webpack4 的过程当中也须要对它作兼容支持。
还有一个比较大的差异就是打包方式的不一样。用 Fis3 打包时是以 HTML 为入口，但在 Webpack4 中是以 JS 为入口，打包的入口发生了很大的变化。这时候，咱们也须要对以前的逻辑作些适配。
InfoQ：各个项目中使用的技术栈大不相同，这对项目组件化带来了什么样的影响？
程柳锋：这其实会带来的一个最大的影响是，不一样技术栈项目的组件没法复用到另外一个项目。因此针对于组件化的复用，咱们也作了一些适配，固然，不是全部的组件都适配，咱们只是对基础的组件作同构。上层的业务组件能够复用同构好的基础组件。同构相对来说比较难，但为了以后维护的便利性也是值得的。最好仍是根据各自的技术栈实现不一样的业务组件，并统一维护。
InfoQ：腾讯 NOW 直播产品在团队工具链、规范等开发配套设施的建设过程当中遇到了哪些问题？
程柳锋：这里面咱们也是遇到了很多问题。我先从规范提及吧。咱们团队成立之初，是从腾讯的 IMWEB 团队孵化出来的，这时咱们的工具链大多延用他们的工具链。随着这业务的快速发展，暴露出不少业务自身的痛点，原来的工具链没法知足现有需求。为了解决这个问题，咱们创建了新的工具链和规范。咱们首先创建了 Git 提交规范、Git 工做流规范、分支规范、README 规范、监控规范等。可是规范创建以后又面临另外一个巨大挑战：如何将这些规范落地实施呢？咱们在这方面作了不少尝试：

• 将 ESLint 的检查规则集成到咱们的基础设施上，就是将 ESLint 集成到 CI 和 CD 的流程中。当你们提交代码后，第一步会经过 ESlint 来检查代码是否经过，若是没有经过的话，就会拒绝本次构建，固然这个 ESLlint 检查只是增量检查。若是经过才会进行构建流程。这就是咱们 JS 规范的落地执行过程。针对 Git 分支规范和提交规范，咱们天天经过邮件扫描，查看前一百条的 Git 提交记录格式是否正确，如有问题，咱们会邮件知会相关同窗。
• 业务监控告警的规范执行，主要是靠技术负责人 Review，在项目每次发布上线以前，技术负责人会 Review 监控上报的项有完好失。同时咱们根据业务的重要性、访问量等指标将业务分为 3 个级别：重要业务、经常使用业务、普通业务。不一样级别的业务的监控要求也是不同的。
• 除此以外咱们还须要强制地将重要业务加到咱们的 CI 和 CD 流程里，就是单元测试和端对端的测试，每次代码 Commit 都会异步的经过腾讯的蓝盾进行单元测试和端对端测试，若是测试用例不经过，则不容许发布上线。

另外在工具建设的落地方面，咱们会作不少工具平台，好比监控平台、移动测试代理、组件平台等，但这些平台怎么落地？咱们也作了一些操做。以监控平台为例，咱们会把每一个业务对应的 JS 错误 ID、JS 报错率统计出来，并作一下排名。对于排名靠后的项目，会把相关人员、业务的名单展现出来，并通知相关的技术负责人、业务老板等。这个作法仍是比较好的，有利于你们及时发现问题和解决问题，同时也帮助整个团队改进工具平台。
InfoQ：在前端工程化的发展过程当中，腾讯 Now 直播产品经历了怎样的技术架构变化？
程柳锋：一开始腾讯前端工程化的建设与其余公司仍是有必定的差距，甚至说是落后的。最开始咱们团队的前端工程化局限于 Fis 构建的工程化。Fis 能够很好支持本地开发，但不支持建立项目、单元测试、端对端测试、代码检查的工程化。因此咱们第一阶段作的事情就是换掉 Fis，使用 Webpack 做为咱们的构建工具。
以前，整个腾讯 CI 这块的建设比较落后，CI 作得事情也比较有限。在作了脚手架和构建工具切换后，咱们团队搭建了 Jenkins，以便于代码的可持续集成。
搭建了 Jenkins 以后，接下来慢慢的迁移到整个公司，并接入了橘子 CI（Orange CI），借助 Orange CI 把不少 CD 的事情也一块儿作了。由于以前接入的 CI 还不完全，咱们 CI 完成以后，开发者仍然须要在平台上面手动的点击发布，预上线发布仍是有不少的人工操做。但咱们 CI 完成以后，每次 CI 完成以后它会自动构建出一个包。

• 若是是正常的 push，默认状况下，构建出来的包会自动的部署到测试环境，完成测试环境的部署任务。

• 若是打了一个 tag（就是运行 Git tag），或者在 CLI 运行了 deploy 的命令，这时它会自动的帮咱们把构建出来的包发送到线上。对于离线包，它也会发一个灰度离线包，咱们只须要验证没问题以后，本身再手动的发一个离线包便可。在有了 CI、CD 作支撑后，前面提到的规范和端对端的测试用例、单元测试等，均可以很好的集成进来了。
  这就是咱们 Now 直播产品整个前端工程化的技术架构，接下来，咱们也会去重点探索一下小程序、Serverless 的前端工程化要怎么作，这也是目前腾讯开源协同的 Team 在关注的事情。
  InfoQ：那如今腾讯这边的前端的发布系统已经能够实现项目自动部署了吗？
  程柳锋：如今已经彻底实现自动发布了。CI 和 CD 的过程很大程度上提高了咱们的开发效率。以前若是手动发布项目，你须要作不少操做。可是如今只需在不一样的发布系统里面点击一下就能够实现项目发布，发布时间从以前 15 分钟优化到仅仅一条命令就完成。
  InfoQ：您认为前端工程化在将来有哪些机遇和挑战呢？
  程柳锋：我认为有如下几个机遇：

1.前端工程化能够作不少事情，前面提到了有三个阶段，那么第四个阶段就是中台化，咱们能够联合多个部门共建前端工程化，让它的生态和体系更加完善，从而有效的避免重复造轮子的事情，这是每一个公司将来都要重点实践的事情。

2.前端技术发展异常活跃，新的技术和框架不断的出现。对于新的技术方案，咱们要及时的把它们整合进来，并探索它们的工程化，好比说像小程序、Flutter、Serverless 等这些新技术的工程化方案。

3.咱们认为前端工程化将来的定位将更加超前。新技术的预研有很大一部分是放在前端工程化中来作的。举个例子，以前咱们的项目是 React 16.2.0 版本，这个版本咱们用了一年多，但随着 React 框架不断的发布，当 React 发布到 16.8.0 的时候，React 会带来不少新特性，若是再用以前的 16.2.0 版本，开发者将没法感知 React 的新特性。这时候，经过前端工程化的方式，能够帮助你们快速的体验新特性。另外，还包括一些技术方案的尝试，好比像 WebAssembly、PWA 等，经过前端工程化的方式，可以更好的赋能咱们业务。