从 Angular转到 React，网易严选的前端工程化实践前端日益发展

前端日益发展，从最初的 HTML、CSS、JavaScript 三大基础，到后来的 jQuery、Backbone、AngularJS ，再到现在的 Angular、React、Vue 三大框架流行，技术的演进既带来了更多的可能，也带来了一些问题。例如：团队如何高效合作、项目如何统一维护、代码如何规范等等。前端工程化的出现，就是为了解决这些日益突出的问题。它旨在制订规范化的前端工作流，并规范统一项目的模块化开发和前端资源，让代码的维护和互相协作更加容易更加方便。
今年我们团队由 Angular 技术栈转变成 React 技术栈，在这个大背景下，我们急需一套完善的工程化方案来帮助技术栈落地。在通过确定目标、定义规范、技术调研、开发实现等一系列步骤之后，制定了一套完善的工程化方案。它帮助解决开发流程中的问题，让开发更加专注业务本身，提高整个系统生产效率。
目标定义作为一个工程化方案，最终的目标是尽可能解决项目生命周期里遇到的问题，例如：

规范保障

每个团队都会根据实践经验，总结出一套自己的规范（项目规范和流程规范）。让这一套规范在落地到实际的开发中时，除了人为的约束，更多的应该是通过工具约束。工程化就是把团队的经验沉淀到脚手架和开发套件中，让新项目或新成员可以复用这些经验。

提效

一个好的工程化方案，是可以提升开发效率的，这个提效包括初始化项目，完备项目的 dev 环境，数据 mock ， build 打包等一系列流程，既要让项目“搭建 - 开发 - 部署”更快捷高效，也要方便项目的后期维护和迭代。

减少人力

在开发过程中可能会遇到一些重复人力的工作。例如 A、B 两个系统有一个相似的列表页，这个列表页不能作为组件抽离，但是又在多处能用到，这部分资源（代码模板）复用急需一个中间媒介来完成。假如资源 / 项目需要升级了，大多情况是资源开发者出一个升级文档，然后升级的人按照文档一步步修改。这是很重复的一份工作，因为假如你手上有十个项目，你就需要把相同的事情做十遍，这一步重复的工作我们希望可以通过工具来完成。
同时，我们的工程化方案应该符合以下四个特点：

渐进式（技术演化能力）易于迭代
扩展性（可伸缩、可插拔）易于部门共建
易用性（贴合实际）易落地
数据统计与分析

方案设计基于以上的目标，下面来看一下整个工程化的方案设计。
首先，介绍整个方案的架构图：

文章插图
架构图
可以看到整个架构图分为四层：
1、底层依赖
最底层依赖了规范、webpack、schematics、node、eslint ，它是上次架构的基石。

规范这里包括了项目规范和流程规范，是整套方案需要遵守的约定；因为这套规范是根据大量的实际业务总结出来的，所以它是贴合业务场景，便于整体方案落地的。
schematics 引入主要是为了解决上面说到的资源相关的问题，后面会详细讲到。

2、插件封装层
这一层主要是对上层需要实现的功能做一个划分，然后通过插件的形式实现。例如：

将一系列模板抽离作为一个集合，然后将项目初始化时需要做的模板选择和模板处理放到 init 插件中完成，不同团队可以根据规范自定义插件；
开发编译阶段需要的 webpack 和 server、build 脚本放在 @sharkr/scripts 插件中完成，不同团队可以根据规范自定义插件；
前面说到的资源复用和资源升级问题，统称为文件处理相关， @sharkr/schematics-cli 插件提供这个能力；
@sharkr/eslint-config-react 插件提供 eslint 检查；
还有一部分公共能力封装成 util 插件，方便共享。

这种插件的方式可以使工具具有很强的扩展性，在跟其他团队共建时，可以很方便的做一些自定义，但是又符合统一的规范。
3、统一命令层
第三层是统一命令层，这一层做的事情就是，最终对用户暴露一个统一的工具 @sharkr/cli，在 cli 里去规范常用的一些命令，当然这些命令的具体实现都是调用下一层的插件。这些命令会应用到项目开发的生命周期中去。
在这一层中会添加埋点，用于收集命令、项目、使用包等相关情况，以便做数据的统计与分析，了解实际落地情况，也为未来迭代版本提供有效参考。