InfoQ科技 Angular转到 React,网易严选的前端工程化实践,从

前端日益发展 , 从最初的HTML、CSS、JavaScript三大基础 , 到后来的jQuery、Backbone、AngularJS , 再到现在的Angular、React、Vue三大框架流行 , 技术的演进既带来了更多的可能 , 也带来了一些问题 。 例如:团队如何高效合作、项目如何统一维护、代码如何规范等等 。 前端工程化的出现 , 就是为了解决这些日益突出的问题 。 它旨在制订规范化的前端工作流 , 并规范统一项目的模块化开发和前端资源 , 让代码的维护和互相协作更加容易更加方便 。
今年我们团队由Angular技术栈转变成React技术栈 , 在这个大背景下 , 我们急需一套完善的工程化方案来帮助技术栈落地 。 在通过确定目标、定义规范、技术调研、开发实现等一系列步骤之后 , 制定了一套完善的工程化方案 。 它帮助解决开发流程中的问题 , 让开发更加专注业务本身 , 提高整个系统生产效率 。
目标定义作为一个工程化方案 , 最终的目标是尽可能解决项目生命周期里遇到的问题 , 例如:
规范保障每个团队都会根据实践经验 , 总结出一套自己的规范(项目规范和流程规范) 。 让这一套规范在落地到实际的开发中时 , 除了人为的约束 , 更多的应该是通过工具约束 。 工程化就是把团队的经验沉淀到脚手架和开发套件中 , 让新项目或新成员可以复用这些经验 。
提效一个好的工程化方案 , 是可以提升开发效率的 , 这个提效包括初始化项目 , 完备项目的dev环境 , 数据mock , build打包等一系列流程 , 既要让项目“搭建-开发-部署”更快捷高效 , 也要方便项目的后期维护和迭代 。
减少人力在开发过程中可能会遇到一些重复人力的工作 。 例如A、B两个系统有一个相似的列表页 , 这个列表页不能作为组件抽离 , 但是又在多处能用到 , 这部分资源(代码模板)复用急需一个中间媒介来完成 。 假如资源/项目需要升级了 , 大多情况是资源开发者出一个升级文档 , 然后升级的人按照文档一步步修改 。 这是很重复的一份工作 , 因为假如你手上有十个项目 , 你就需要把相同的事情做十遍 , 这一步重复的工作我们希望可以通过工具来完成 。
同时 , 我们的工程化方案应该符合以下四个特点:
渐进式(技术演化能力)易于迭代扩展性(可伸缩、可插拔)易于部门共建易用性(贴合实际)易落地数据统计与分析基于以上的目标 , 下面来看一下整个工程化的方案设计 。
首先 , 介绍整个方案的架构图:
InfoQ科技 Angular转到 React,网易严选的前端工程化实践,从
文章图片
架构图
可以看到整个架构图分为四层:
1、底层依赖
最底层依赖了规范、webpack、schematics、node、eslint , 它是上次架构的基石 。
规范这里包括了项目规范和流程规范 , 是整套方案需要遵守的约定;因为这套规范是根据大量的实际业务总结出来的 , 所以它是贴合业务场景 , 便于整体方案落地的 。 schematics引入主要是为了解决上面说到的资源相关的问题 , 后面会详细讲到 。2、插件封装层
这一层主要是对上层需要实现的功能做一个划分 , 然后通过插件的形式实现 。 例如:
将一系列模板抽离作为一个集合 , 然后将项目初始化时需要做的模板选择和模板处理放到init插件中完成 , 不同团队可以根据规范自定义插件;开发编译阶段需要的webpack和server、build脚本放在@sharkr/scripts插件中完成 , 不同团队可以根据规范自定义插件;前面说到的资源复用和资源升级问题 , 统称为文件处理相关 , @sharkr/schematics-cli插件提供这个能力;@sharkr/eslint-config-react插件提供eslint检查;还有一部分公共能力封装成util插件 , 方便共享 。这种插件的方式可以使工具具有很强的扩展性 , 在跟其他团队共建时 , 可以很方便的做一些自定义 , 但是又符合统一的规范 。
3、统一命令层