浅谈前端工程化

 

第一章 背景及现状

　　不知道你的团队如何定义前端开发，据我所知，时至今日仍然有不少团队会把前端开发归类为产品或者设计岗位（这点本人深有体会！！！），虽然身份之争多少有些无谓，但我对这种偏见仍是心存芥蒂，试着从工程的角度系统的介绍一下我对前端，尤为是对web前端的理解。只要咱们还把本身的工做看做为一项软件开发活动，那么我相信读过下面的内容你也必定会有所共鸣。

　　前端，是一种GUI软件！

　　现现在前端可谓一应俱全，产品形态五花八门，涉猎极广，什么高大上的基础库/框架，拽炫酷的宣传页面，还有屌炸天的小游戏……不过这些一两个文件的小项目并不是是前端技术的主要应用场景，更具商业价值的则是复杂的Web应用，它们功能完善，界面繁多，为用户提供了完整的产品体验，多是新闻聚合网站，多是在线购物平台，多是社交网络，多是金融信贷应用，多是音乐互动社区，也多是视频上传与分享平台，多是系统应用，门户、数据可视化平台……

　　从本质上讲，全部Web应用都是一种运行在网页浏览器中的软件，这些软件的图形用户界面（Graphical User Interface，简称GUI）即为前端。

　　如此复杂的Web应用，动辄几十上百人共同开发维护，其前端界面一般也颇具规模，工程量不亚于通常的传统GUI软件。

　　尽管Web应用的复杂程度与日俱增，用户对其前端界面也提出了更高的要求，但时至今日仍然没有多少前端开发者会从软件工程的角度去思考前端开发，来助力团队的开发效率，更有甚者还对前端保留着”如玩具般简单“的刻板印象，日复一日，刀耕火种。

　　“历史悠久”的前端开发，始终像是放养的野孩子，原始如斯，难免让人慨叹！

　　随着前端开发复杂度的日益增长，各类优秀的组件框架也遍地开花。同时，咱们面临业务规模的快速发展和工程师团队的不断扩张。目前来讲，Web业务日益复杂化和多元化，前端开发已经由以WebPage模式为主转变为以WebApp模式为主了。如今随便找个前端项目，都已经不是过去的拼个页面+搞几个jQuery插件就能完成的了。工程复杂了就会产生许多问题，如何进行高效的多人协做？如何保证项目的可维护性？如何提升项目的开发质量？...

　　咱们但愿能在平常开发中制订一个规范化的前端工做流，很好地规范统一项目的模块化开发和前端资源，让代码的维护和互相协做更加容易更加方便，令前端开发自动化成为一种习惯。同时，让你们可以释放生产力，提升开发效率，更好更快地完成团队开发以及项目后期维护和扩展。

第二章 构建前端工程的几个阶段

2.1 第一阶段：库/框架选型

　　前端工程建设的第一项任务就是根据项目特征进行技术选型（ps:以上排序不分排名前后）。

　　基本上如今没有人彻底从0开始作网站，哪怕是政府项目用个jQuery都很正常吧，React/Vue/Angular等框架横空出世，解放了很多生产力，合理的技术选型能够为项目节省许多工程量这点毋庸置疑。

2.2 第二阶段：构建、管理工具

　　选型以后基本上就能够开始敲码了，不过光解决开发效率还不够，必需要兼顾运行性能。前端工程进行到第二阶段会选型一种或多种构建工具，对代码进行压缩、校验、管理，以后再以页面为单位进行简单的资源合并（ps:以上排序不分排名前后）。

　　前端开发工程化程度之低，经常出乎咱们的意料。不少人在大型互联网公司工做时是没有多少概念的，直到离开大公司的温室，去到业界与更多的团队交流才发现，能作到这个阶段在业界来讲已然超出平均水平，属于“具有较高工程化程度”的团队了，查看网上形形色色的网页源代码，能作到最基本的JS/CSS压缩的Web应用都已跨入标准互联网公司行列，不难理解为何不少前端团队对于前端工程构建的认知还仅停留在“压缩、校验、合并”这种程度。

2.3 第三阶段：JS/CSS模块化开发

　　分而治之是软件工程中的重要思想，是复杂系统开发和维护的基石，这点放在前端开发中一样适用。在解决了基本开发效率运行效率问题以后，前端团队开始思考维护效率，模块化是目前前端最流行的分治手段（ps:以上排序不分排名前后）。

　　不少人以为模块化开发的工程意义是复用，其实应该是模块化开发的最大价值应该是分治。无论你未来是否要复用某段代码，你都有充分的理由将其分治为一个模块。

　　JS模块化方案不少，AMD/CommonJS/UMD/ES6 Module等，对应的框架和工具也一大堆；CSS模块化开发基本都是在less、sass、stylus等预处理器的import/mixin特性支持下实现的。虽然这些技术由来已久，在现在这个“言必及React”的时代略显落伍，但想一想业界的绝大多数团队的工程化落后程度，放眼望去，绝不夸张的说，能达到第三阶段的前端团队已属于高端行列，基本具有了开发维护通常规模Web应用的能力。

　　

　　尤为是node的出现，除了用JS能够写服务端业务，众多的模块化、构建工具结合node真的是丰富了整个前端生态圈。

　　然而，作到这些就够了么？

2.4 第四阶段：组件化开发与资源管理

　　前端是一种技术问题较少、工程问题较多的软件开发领域。

　　当咱们要开发一款完整的Web应用时，前端将面临更多的工程问题，好比：

1. 大致量：多功能、多页面、多状态、多系统；
2. 大规模：多人甚至多团队合做开发；
3. 高性能：CDN部署、缓存控制、文件指纹、缓存复用、请求合并、按需加载、同步/异步加载、移动端首屏CSS内嵌、HTTP 2.0服务端资源推送。

　　这些无疑是一系列严肃的系统工程问题。前面讲的三个阶段虽然相比曾经“茹毛饮血”的时代进步很多，但用于支撑第四阶段的多人合做开发以及精细的性能优化彷佛还欠缺点什么。到底，缺什么呢？

2.4.1 组件化开发

　　前端从来以“简单”著称，在前端开发者群体中，小而美的价值观占据着主要的话语权，甚至成为了某种信仰，想与其余人交流一下工程方面的心得，获得的回应每每都是两个字：过重。

　　工程方案其实也能够小而美！只不过它的小而美不是指代码量，而是指“规则”。找到问题的根源，用最少最简单明了的规则制定出最容易遵照最容易理解的开发规范或工具，以提高开发效率和工程质量，这一样是小而美的典范！

　　分治的确是很是重要的工程优化手段。在我看来，前端做为一种GUI软件，光有JS/CSS的模块化还不够，对于UI组件的分治也有着一样迫切的需求：

　　如上图，这是我所信仰的前端组件化开发理念，简单解读一下：

1. 页面上的每一个 独立的 可视/可交互区域视为一个组件；
2. 每一个组件对应一个工程目录，组件所需的各类资源都在这个目录下就近维护；
3. 因为组件具备独立性，所以组件与组件之间能够 自由组合；
4. 页面只不过是组件的容器，负责组合组件造成功能完整的界面；
5. 当不须要某个组件，或者想要替换组件时，能够整个目录删除/替换。

　　其中第二项描述的就近维护原则，是最具工程价值的地方，它为前端开发提供了很好的分治策略，每一个开发者都将清楚的知道，本身所开发维护的功能单元，其代码必然存在于对应的组件目录中，在那个目录下能找到有关这个功能单元的全部内部逻辑，样式也好，JS也好，页面结构也好，都在那里。

　　组件化开发具备较高的通用性，不管是前端渲染的单页面应用，仍是后端模板渲染的多页面应用，组件化开发的概念都能适用。组件HTML部分根据业务选型的不一样，能够是静态的HTML文件，能够是前端模板，也能够是后端模板：

　　不一样的技术选型决定了不一样的组件封装和调用策略。

　　基于这样的工程理念，咱们很容易将系统以独立的组件为单元进行分工划分：

 

　　因为系统功能被分治到独立的模块或组件中，粒度比较精细，组织形式松散，开发者之间不会产生开发时序的依赖，大幅提高并行的开发效率，理论上容许随时加入新成员认领组件开发或维护工做，也更容易支持多个团队共同维护一个大型站点的开发。

　　结合前面提到的模块化开发，整个前端项目能够划分为这么几种开发概念：

名称	说明	举例
JS模块	独立的算法和数据单元	浏览器环境检测(detect)，网络请求(ajax)，应用配置(config)，DOM操做(dom)，工具函数(utils)，以及组件里的JS单元
CSS模块	独立的功能性样式单元	reset样式，栅格系统(grid)，字体图标(icon-fonts)，动画样式(animate)，以及组件里的CSS单元
UI组件	独立的可视/可交互功能单元	页头(header)，页尾(footer)，导航栏(nav)，搜索框(search)
页面	前端这种GUI软件的界面状态，是UI组件的容器	首页(index)，列表页(list)，用户管理(user)
应用	整个项目或整个站点被称之为应用，由多个页面组成	SPA（单一页面应用）、PWA（渐进式Web应用）

　　以上5种开发概念以相对较少的规则组成了前端开发的基本工程结构，基于这些理念，前端开发就成了这个样子：

示意图	描述
	整个Web应用由页面组成
	页面由组件组成
	一个组件一个目录，资源就近维护
	组件可组合， 组件的JS可依赖其余JS模块， CSS可依赖其余CSS单元

　　综合上面的描述，对于通常中小规模的项目，大体能够规划出这样的源码目录结构：

 

　　若是项目规模较大，涉及多个团队协做，还能够将具备相关业务功能的页面组织在一块儿，造成一个子系统，进一步将整个站点拆分出多个子系统来分配给不一样团队维护。以上架构设计历经许多不一样公司不一样业务场景的前端团队验证，收获了不错的口碑，是行之有效的前端工程分治方案。

2.4.2 静态资源管理

　　上面提到的模块化/组件化开发，仅仅描述了一种开发理念，也能够认为是一种开发规范，假若你承认这规范，对它的分治策略产生了共鸣，那咱们就能够继续聊聊它的具体实现了。

　　很明显，模块化/组件化开发以后，咱们最终要解决的，就是模块/组件加载的技术问题。然而前端与客户端GUI软件有一个很大的不一样：前端是一种远程部署，运行时增量下载的GUI软件。

　　前端应用没有安装过程，其所需程序资源都部署在远程服务器，用户使用浏览器访问不一样的页面来加载不一样的资源，随着页面访问的增长，渐进式的将整个程序下载到本地运行，“增量下载”是前端在工程上有别于客户端GUI软件的根本缘由。

 

　　上图展现了一款界面繁多功能丰富的应用，若是采用Web实现，相信也是不小的体量，若是用户第一次访问页面就强制其加载全站静态资源再展现，相信会有不少用户由于失去耐心而流失。根据“增量”的原则，咱们应该精心规划每一个页面的资源加载策略，使得用户不管访问哪一个页面都能按需加载页面所需资源，没访问过的无需加载，访问过的能够缓存复用，最终带来流畅的应用体验。

　　这正是Web应用“免安装”的魅力所在。由“增量”原则引伸出的前端优化技巧几乎成为了性能优化的核心，有加载相关的按需加载、延迟加载、预加载、请求合并等策略；有缓存相关的浏览器缓存利用，缓存更新、缓存共享、非覆盖式发布等方案；还有复杂的BigRender、BigPipe、Quickling、PageCache等技术。这些优化方案无不围绕着如何将增量原则作到极致而展开。

　　因此：第四阶段前端开发最迫切须要作好的就是在基础架构中贯彻增量原则。

　　相信这种贯彻不会随着时间的推移而改变，在可预见的将来，不管在ES5亦或者ES6/7时代，不管是AMD/CommonJS/UMD亦或者ES6 module时代，不管端内技术如何变迁，咱们都有足够充分的理由要作好前端程序资源的增量加载。正如前面说到的，第三阶段前端工程缺乏点什么呢？我以为是在其基础架构中缺乏这样一种“智能”的资源加载方案。没有这样的方案，很难将前端应用的规模发展到第四阶段，很难实现落地前面介绍的那种组件化开发方案，也很难让多方合做高效率的完成一项大型应用的开发，并保证其最终运行性能良好。在第四阶段，咱们须要强大的工程化手段来管理”玩具般简单“的前端开发。

2.5 第五阶段：规范化

　　模块化和组件化肯定了开发模型，而这些东西的实现就须要规范去落实。规范化实际上是工程化中很重要的一个部分，项目初期规范制定的好坏会直接影响到后期的开发质量：

• 目录结构的制定
• 编码规范
• 先后端接口规范
• 文档规范
• 组件管理
• Git分支管理
• Commit描述规范
• 按期CodeReview
• 视觉图标规范
• ...

2.6 总结

　　在业界内有这么一句话：任何简单机械的重复劳动都应该让机器去完成。现代前端技术再也不是之前刀耕火种的年代了。因此前端工程化的不少脏活累活都应该交给自动化工具来完成。

　　我的总结经验，认为前端工程化主要应该从模块化、组件化、规范化、自动化四个方面来思考。

　　如何选型技术、如何定制规范、如何分治系统、如何优化性能、如何加载资源，当你从切图开始转变为思考这些问题的时候，我想说：你好，工程师！

　　最后要特别感谢“Fouber”工程师（https://github.com/fouber/）的精心分享。