从抄起键盘一把梭到严谨细致的「前端工程化」

发布于 2019/04/23 19:27
阅读 1K+
收藏 3

【开源中国 APP 全新上线】“动弹” 回归、集成大模型对话、畅读技术报告”

近两年,不少前端开发者喜欢自嘲自己是「前端配置工程师」,这个说法其实是他们面对繁琐的开发环境配置时,无奈之下的一种调侃,但也侧面反映了前端开发环境配置之复杂 —— 甚至可以细分出一个“职业岗位”。

那所谓「前端工程化」又是如何诞生的呢?过去的 Web 开发相对比较简单,对页面的要求不高,但随着技术的进步和需求的多样化,Web 开发越来越复杂,复杂不仅体现在最终呈现给用户的页面上,更重要的是对功能和性能的要求也更加高。

项目不断变大,工程也越加复杂,随即而来的许多问题就凸显出来了 —— 如何进行高效的多人协作?如何保证项目的可维护性?如何提升项目的开发质量?

这个时候,「前端工程化」应运而生,它要解决的正是如何提升整个团队的生产效率以及节约开发成本

同样是工程,前端的工程化问题与传统的软件工程虽然有所不同,但所面临的问题是一样的。软件工程化关注的是性能、稳定性、可用性和可维护性等方面,除了注重基本的开发效率和运行效率的同时,还要思考维护效率。从这方面来看,前端工程本质上是软件工程的一种,一切以这些为目标的工作都能称为“前端工程化”。

而所谓工程化其实是一种思想,而非某种技术。

单打独斗的个人开发对前端工程化问题不会过多考虑,但更多时候,在团队开发乃至更大型的项目开发中,需要打造的前端界面规模甚大,面对复杂和庞大的 Web 应用,如果缺乏统一标准的开发流程和规范,后期的开发工作将会寸步难行。

既然前端工程化主要应用于团队开发中,认识前端工程化的最好场景就是来自团队开发。

Feflow (读音 /ˈfefləʊ/)是腾讯开源的用于提升工程效率的前端工作流和规范工具。Feflow 借鉴了 Pipline 的思想,将日常的研发工作划分为:初始化、本地开发、打包构建、检查、发布上线五个步骤。分别对应 init、dev、build、test 和 deploy 五个基本命令。除了服务好基本的开发工作流和规范,Feflow 提供了易于扩展的插件机制,用于打造团队统一的工具链生态。

我们采访了腾讯开源项目 Feflow 负责人 cpselvis,让他和我们分享 Feflow 的诞生和实现过程,以及关于前端工程化的见解。

项目地址:https://github.com/feflow/feflow/

为什么要开发 Feflow?

我们于2017年3月投入开发 Feflow,那时 NOW 直播产品刚诞生半年左右,业务在快速发展,团队人员也在不断增加,我们面临着日益复杂的业务场景对研发效率的挑战。主要有 3 个方面的问题:

一、创建项目不智能。开发新项目需要经过以下的步骤:

  1. 在 Git code 上手动创建一个 Git 仓库
  2. 新项目基于原有旧项目拷贝基础上进行开发
  3. 由于 C 端产品对质量和性能的极致要求,因此每个新项目都需要申请 Badjs ID、monitor ID、离线包ID等等,需要去不同的系统里手动申请
  4. 最后还有关于项目维护的问题,之前是直接将构建脚本放在项目里面直接暴露给业务开发者,开发者可以按需随意修改。但随着时间的推移,每个项目构建脚本差异很大,而且也不利于构建脚本的升级。

二、研发规范缺失和落地困难。比如常见的 Git commit 规范、JS 规范和 README 规范。

举例说明,曾经由于 JS 规范的缺失,团队成员修改了充值页面的 JSON 配置,并加入重复的 KEY,正式发布后导致部分 vivo 手机白屏。而这种事故本可以通过规范以避免。

三、工具链不统一。团队成员平时会因为自身需要而开发一些小工具,比如压缩图片、代码统计、一键同步 IVWEB 社区文章到 KM 等,如此一来必然会造成需要全局安装多个命令行工具,使用起来也不方便。

经过广泛的调研和搜集,最后发现公司乃至业内都没有一套比较好的方案,因此我们决定开发 Feflow(Front-end workflow),以解决前端工作流和规范相关的问题

FeFlow 最初希望解决哪些问题,目前已解决哪些问题 ?

Feflow 这套方案核心的关注点包括两个方面:

  1. 基础的前端工作流程。从初始化、开发、构建、规范检查和最终的发布链路
  2. 打造团队统一的工具链,通过插件机制将开发相关的工具连接起来。

最终以 CLI 命令行 / GUI 的形态暴露给开发者使用,以达到简化开发流程、统一团队开发规范和提升开发效率的目的。

Feflow 如何解决这些问题?

Feflow 具备高可扩展性的特点,Feflow 自身只提供标准化的命令行内的日志存储和输出、插件机制、更新机制等核心功能。

总体来说,Feflow 的定制性十分高。对于基础的前端工作流程,每个特定的业务团队可以自定义脚手架、构建器、部署器等组件以满足业务需要,当然也可以直接采用 Feflow 官方生态里面的优秀组件。

对于打造团队统一工具链方面,Feflow 内部提供了强大的插件机制,包括插件安装、插件管理、插件开发等,通过插件可以自定义子命令,将团队开发过程中的自动化工作进行整合。

对于上述的这些功能,Feflow 如何实现?

Feflow 的技术架构从下到上一共分为 4 层,分别是:

  1. 控制台/GUI:用于和用户进行交互,以输入命令行或者界面操作的形式提供
  2. 参数解析器:解析命令的含义
  3. 核心层:提供核心能力,包括插件机制、日志输出和存储、更新机制。同时提供内置的基础命令
  4. 插件生态:这层为业务提供了自定义脚手架、构建器和插件开发的多样化选选择

Feflow 与常见的 CI/CD,DevOps 这些模式是否有相通之处?

三者的出发点都是为了优化研发流程。

相对而言,Feflow 和 CI/CD 的联系更大点。CI/CD 通常来说是整个公司的技术基础设施,但也只是一个壳,至于项目的构建脚本、打包规则、代码规范检查、单元测试用例等等都需要开发者自己提供。

Feflow 正好用于提供构建、代码检查、单元测试等服务。另外也支持项目的初始化和本地开发工作,CI/CD 无法解决这方面的问题。

Feflow 是否带来开发效率方面的提升,以及降低后期维护成本,如何做到的?

是的。我们主要从以下几个方面来提升开发效率和降低后期维护成本:

  1. 打通内部系统。大公司的内部系统普遍都非常多,比如我们日常使用的监控上报系统就有至少 5 个,因为 C 端项目对于性能和质量有着极致的要求,我们需要从多个纬度(JS 报错、页面渲染成功率、接口调用成功率、首屏时间、产品数据上报等)去监控 Web 页面的情况。在以往,大家都是手动去各个系统里面申请,需要频繁切换并且有些内部系统使用起来上手成本也比较高。这时,我们推送相应的系统提供相应的接口,以实现自动化的需求。
  2. 统一团队开发方式。我们将前端工程按照开发周期分成了 5 个阶段,并且使用特定的命令与之对应,比如:初始化(init)、本地开发(dev)、打包构建(build)、测试用例和规范检查(test)、发布上线(deploy)。通过这种标准化的流水线生产方式,可以有效地磨平个体的差异,让大家的开发习惯保持一致,从而减少项目交接所耗费的时间。
  3. 制定和执行研发规范。我们知道,由于业务的快速发展和人员的不断增加,一套合理的研发和协作规范可以减少沟通成本,同时避免不规范的操作导致的外网问题。我们制定了多套规范,包括:Git 提交格式、分支和 Tag、Javascript、目录结构规范、README 文档编写、上线 Checklist 规范等等,并且将规范和 CI/CD 工具进行有效的结合,从而让项目的后续维护变得更加简单。

能否将 Feflow 与同类的产品进行对比?

事实上,腾讯内部的前端工程化方案有微信的 WeFlow(已开源)、 腾讯新闻的 Leah 方案。

Weflow 旨在构建环节的问题,目前应用在微信广告和朋友圈相关的前端代码构建,以 GUI 的形态提供给开发者使用。

而 Leah 做的事情会更大更多,除了前端工程化,还包括组件化、前端异常监控和智能切图等。

 公司以外的前端工程化方案也有很多,比如:vue-cli、create-react-app、百度的 Fis、阿里云的 dawn 等等。Vue-cli 和 create-react-app 仅适合用于特定框架 Vue/React,适合个人开发者使用。Fis 目前已不再维护,阿里云推出的 dawn 定义了一套模板和中间件的接入方式,功能扩展主要通过中间件来扩展。

相比 vue-cli 和 create-react-app 而言,Feflow 具备高可扩展性,不限定在某一种框架使用,开发者也可以定制自己的模板、构建器、插件等等。

Feflow 未来规划有何打算?

Feflow 未来有两方面的计划,一是紧跟腾讯大趋势开源协同,将会在2019年5月左右正式开源到腾讯的 GitHub 仓库,同时公司内联合其它兄弟团队,比如应用宝、新闻、教育、微信等团队共同建设公司级的前端工作流和规范方案。

另一方面,我们也在积极探索和打造 GUI 的前端工作流和规范体系,相比 CLI,GUI 上手更简单,适合不喜欢命令行操作的同学,同时 GUI 的交互体验也更加友好。

和我们谈谈前端工程化的意义和价值吧

不妨把前端工程化可以看作成团队技术引擎,它是前端技术从刀耕火种到目前各类技术如 React、ReactNative、Node.js、小程序等百花齐放的发展过程中演变而来的。

我觉得前端工程化的价值一方面体现在可以有效地标准化团队的开发方式,抹平个体成员之间的差异,将开发工作以流水线的方式进行运作;另一方面,通过前端工程化,可以将重复繁琐、无技术含量的工作交给工具,从而释放生产力,让开发人员可以将时间和精力专注于业务逻辑和产品体验的打磨上。

前端工程化做得更深入的话可以做成公司的基础设施,促进公司多个前端团队共建,避免重复造轮子的情况。比如:基础的前端发布系统、数据 Mock 服务、移动测试代理、接口联调平台等可以大家一起建设。

对于在团队实践前端工程化有何建议?

以我的经验,首先需要找到合适的切入点,知道团队的痛点在何处。这里的“痛点”可以从工作群、周会讨论的 ISSUE 和问卷调查等渠道收集大家的反馈意见,了解是哪些问题阻塞了大家的开发效率和开发体验;另外也可以调研分析存在哪些繁琐的手工操作可以通过工具进行自动化处理。

比如早期的时候,我们团队都是手动创建 Git 项目,然后新项目基于拷贝原有老项目进行开发,手动申请监控ID等。后来,团队打造 Feflow 解决了项目创建和开发不智能的问题,并且通过文章、周会分享的形式安利大家使用 Feflow,最终得到大家的认可。

事实上,在团队内部实施前端工程化的过程中遇到不少阻力,比如规范执行落地。当时我们推出团队的 Git 提交规范和分支规范,但很多成员不遵守,同时很多新成员加入团队后,尚未熟悉团队规范就快速投入业务开发,最终导致提交格式和分支不规范。

为此,我们通过邮件日报的形式每天扫描某个 Git group 的前 100 条提交,不符合规范的通过邮件或者建群进行提醒,此后为了更加智能地执行规范,我们将它集成到 CI 工作流,构建之前先进行强制校验,不符合 Git 提交格式规范和 ESLint 规范的直接拒绝构建。

总而言之,打造工具的过程中一定要收集大家的反馈意见,并且根据反馈意见不断地去优化使用体验。

加载中
OSCHINA
登录后可查看更多优质内容
返回顶部
顶部