什么是前端工程化？

虽然前端工程化的概念兴起还没几年的时间，可是对于“工程化”这个词并非一个新鲜词了，在其余软件开发的领域很早就已经有了高度的工程化，例如Web服务端开发。只不过那个时候，前端工程师并无工程化的意识，也没有必要对前端进行工程化的操做，毕竟在那个时期，前端的开发工做只能算是整个项目开发过程当中的“附属品”。那为何这几年，前端工程化的概念又忽然成为了热点话题了呢？要想讲好前端工程化其实并不容易，我就从下面几个方面入手，对前端工程化的概念作个简单的讲解，仅仅是我的理解，但愿你们多多交流讨论。

      一、前端为何要工程化？

      在回答前端工程化这个问题以前，咱们应该先考虑另一个问题：前端开发中会不会涉及到业务？再详细一点，就是前端工程师到底需不须要了解服务端的业务逻辑，再或者说，要不要将一部分服务端的业务逻辑放到前端来实现。这个问题没有标准的答案，实际上应该属于工程协做问题，就是谁该干什么的问题。

      最先的前端开发就是实现页面，顶多再写写JS让页面能够有交互的特效。可是随着需求的增长，咱们不只要作Web应用，还要作App、小程序以及各类端。在这种需求日增的状况下，必须得考虑一种新的方式，优化前端的开发工做，例如，解决代码冗余，项目可维护性，提高版本迭代速度等等一系列的问题。前端工程化的概念也就是在这中状况下被提出了。

      二、实现前端工程化的基础——先后端分离

      实际上，如今的前端工程化应该还处于早期阶段，毕竟前端工程师这个岗位也才诞生没几年。在互联网发展的早期，Web应用不少状况下都是由服务端工程师一肩挑，前端开发顶可能是写写HTML代码，实现页面的布局，而后再把写好的HTML静态文件交给后端工程师套模板，由于当时大部分的Web应用都是使用的服务端渲染技术，例如Java的JSP。

      这种传统模式下的协做开发效率很是低，若是在页面测试中发现了一个bug，这个bug是因为一个ClassName的值少写了一个字母，你说这种状况究竟是前端工程师的错，仍是后端工程师套模板时的粗枝大叶呢？毕竟一个网站上有成千上万个DOM节点，谁也不能保证一行代码都不会写错。再假如，项目上线后发现网页的实际像素和设计稿上存在1像素的误差，这个时候就须要由前端工程师从新设计一次HTML静态页面，而后再交给后端工程师继续套模板，等整个流程走完以后，你会发现一个更加严重的问题，整个项目中仅仅是1像素的误差，就有可能要调动整个开发团队来处理这1像素的问题，极大的浪费了团队资源。

      上面的问题也仅仅是传统开发问题中的冰山一角，面对这么多的问题，先后端分离开发也就应运而生了。先后端分离开发，为前端工程化的发展提供了生存的土壤。随着市场需求的不断变化，前端开发从传统的WebPage模式，转变到WebApp模式，Web产品形态的变化也不断推进着前端工程师的工做内容发生变化。在应对各类“变化”，前端工程师们也要设计出本身的前端开发“方法论”。

      前端工程化的主要目标就是解放生产力、提升生产效率。经过制定一系列的规范，借助工具和框架解决前端开发以及先后端协做过程当中的痛点和难度问题。

      三、如何实施前端工程化？

      明确先后端开发的分工，是实现先后端分离的第一步，也是后面实现前端各类优化方案的基础。前端工程师主要负责的内容包括：

      静态资源和动态资源的处理；

      JavaScript实现前端业务逻辑；

      HTML模板文件的产出；

      中间层Web服务，通常由Node.js实现；

      前端单元测试；

      前端项目部署；

      其中，静态资源包括.js文件、.css文件以及各类格式的图片、媒体文件等，这些文件不依赖于服务器，只须要在浏览器里面解析就能够了；动态资源是指HTML的模板，若是项目不是由服务器完成渲染的SPA（单页面）应用，那咱们就要考虑如何实现HTML模板的渲染了。前端项目部署是指静态资源文件在测试服务器上的部署，以及HTML模板文件在Node.js中间层服务器上的部署。

      从项目开发的总体环节来讲，实现前端工程化还须要熟练掌握下面几个方面：

      （1）使用Webpack实现项目构建

      构建，简单来讲就是编译，前端开发的全部文件最终归属是要交给浏览器去解析、渲染，并将页面呈现给用户，构建就是将前端开发中的全部源代码转化为宿主浏览器能够执行的代码。前端构建产出的资源文件只有三种，HTML、CSS、JS文件。须要完成编译的内容有：

      没法被浏览器直接识别的JS代码，包括ES6/7/8/9/10等符合ECMAScript规范的JS代码；

      没法被浏览器直接识别的CSS代码，包括SASS/LESS等预编译的CSS语法；

      没法被浏览器识别的HTML模板代码，包括jade、ejs、artTemplate、mustache等Node.js模板引擎；

      项目构建其实就是为了弥补浏览器自身的缺陷和不足，是一种面向语言的编译过程。那么，除了针对语言自己以外，前端的构建还应该考虑到Web应用的性能优化。这些优化主要是为了减小HTTP请求，提高用户体验，包括：

      依赖打包，将同步依赖的文件打包在一块儿，减小HTTP请求数量；

      资源嵌入，例如将小于10kb的图片编译为base64格式嵌入文档，减小HTTP请求；

      文件压缩，减小文件体积，缩短请求时间；

      为文件加入hash指纹，以应对浏览器缓存策略；

      将开发环境下的域名与静态资源文件路径修改成生产环境下的域名和路径；

      文件名称的改变；

      这里须要解释一下，前端的构建工具除了Webpack以外，还有其余的工具，例如Gulp、Grunt等，为何这里只提到了Webpack？其实，Gulp、Grunt只能算是工做流管理工具，它们自己是不提供具体的功能，全部的构建、部署等功能都要由对应的插件来完成，使用Gulp和Grunt只是便于项目各个环节工做流程的控制。并且，这两款工具的话题热度和使用率远不及Webpack，Webpack虽然是近两年才崛起的构建工具，但目前依然成为了最流行的构建工具之一，Vue和React两大前端框架的Webpack Loader也是有官方或做者本人编写的。因此，咱们在讲前端工程化构建时，推荐使用Webpack这款工具。

      （2）使用Babel完成JavaScript编译

      JavaScript能够说是前端最为核心的一门编程语言了，也就是咱们常说的“JS”，JS自己是能够直接在浏览器中执行的，那么为何还要使用Babel再编译一次呢？其实，这里要解释一下，在ECMAScript2015（简称ES6）正式发布之后，前端工程师关注的重心就由“JS”转向了“ES”，做为专业的前端工程师们应该都了解，JavaScript ≠ ECMAScript。

      ECMAScript是一个标准，JavaScript是对ECMAScript标准实现的一个子集。宿主浏览器的API（BOM和DOM）再加上JavaScript，就组成了咱们传统认知中的JavaScript。可是随着ECMAScript的版本不断迭代更新，带来的并非开发的便利，因为浏览器对ECMAScript新规范的支持实现比较滞后，即便是目前最新版的Chrome浏览器也没有彻底支持ECMAScript2015（ES6）的全部规范，并且ECMAScript2017都已经发布了，为了更好的让新的ES规范可以无缝衔接浏览器，Babel编译JavaScript语法的做用就突显出来了。

      Babel的做用简单来讲，就是将浏览器未实现的ECMAScript规范语法转化为可运行的低版本语法，例如将ES6的class转化为ES5的prototype实现。

      （3）CSS预编译

      CSS做为浏览器能够直接识别的样式语言，弥补了HTML原生样式的不足，对于早期互联网开发中，样式的要求并不复杂，仅须要少许的CSS代码便可。可是在现在追求用户极致体验的潮流下，CSS的开发要求不断提升，复杂的CSS开发变成一件很是繁琐和痛苦的事情。最主要的缘由仍是受限于浏览器的实现和CSS自身的弱编程能力。

      CSS预编译器的工做原理是提供便捷的语法和特性供开发者编写源代码，随后通过专门的编译工具将源码转化为CSS语法。

      （4）模块化开发

      模块化开发和组件化开发是两个彻底不一样的概念，模块化属于架构层面的概念，前端工程化与模块化的关系就相似于组装车间与零件的关系。使用模块化开发，能够解决下面几个问题：

      避免命名冲突；

      便于依赖管理；

      利于性能优化；

      提升可维护性；

      提升代码可复用性；

      在ES6规范发布以前，前端模块化开发主要有三种规范，分别是：CommonJS、AMD、CMD。

      CommonJS是一种只适用于JavaScript的静态模块化规范，适合Node.js开发，但并不适合浏览器环境；而AMD/CMD规范并非彻底一致的，但核心功能是统一的，两个规范都重点解决了浏览器对前端模块化的需求。

      ES6 Module规范推出以后，前三者的模块化规范也逐渐退出前端的历史舞台。ES6 Module是语言层面的规范，与应用场景无关，因此一个不涉及运行环境API调用的模块能够在任何场景下运行。可是目前浏览器尚未彻底支持这种规范，因此，要实现ES6 Module规范的话，还须要使用构建工具进行编译。

      （5）组件化开发

      前面提到了，组件化和模块化是两个彻底不一样的概念，模块化是文件层面上对代码和资源的拆分，组件化是设计层面上对UI的拆分。从UI中拆分出来的一个结构单元，成为UI组件，一个UI组件单元包含了HTML模板、CSS样式、JS逻辑。在页面的设计过程当中，页面上的每个元素都是组件，页面也是一个组件，只不过页面是一个大型组件，而后这个大型组件又由多个中小型组件拼装而成。中型组件还能够再拆分红小型组件，小型组件再拆分红DOM元素，DOM元素也属于浏览器自身的组件，是组件的基本单元。这种组件化开发就是前端开发的“分治思想”。

      （6）开发环境的本地服务器与Mock服务

      在前端工程化开发中，经过构建工具能够将代码进行编译，而后在浏览器中进行调试，可是在开发过程当中源码的每次修改都须要执行一次构建，构建完成后才能在浏览器里运行，这对前端工程师来讲无疑就是一种灾难。要完美的解决这个问题，可使用本地服务器与构建工具结合，对源码进行监听并在修改以后触发动态构建，使用自动化构建的方式代替人工。这种动态构建是使用本地服务器解决开发层面上的问题。

      Mock服务解决的是先后端协做开发的问题，先后端开发人员提早约定好规范，前端工程师经过本地服务器提供的Mock数据接口辅助前端逻辑的编写和功能模块的开发。若是项目中须要服务器端渲染（***），本地服务器还须要具有解析HTML模板的能力，同时Mock服务提供***所需的初始化数据。

      前端工程师可使用本地服务器提供的Mock数据接口，在后端人员开发的同时，进行前端逻辑的并行开发，等到后端真实接口开发完成后，将前端请求的地址从Mock服务迁移到服务器的生产环境便可。

      （7）规范化约束

      不管是服务器端开发仍是前端工程化开发，规范化的约束都相当重要。开发人员在设计项目的总体架构时，为了考虑到项目的可扩展性、可维护性、高内聚性等因素，会对代码进行封装，使用配置化操做，为项目开发带来便利，这必然要求业务代码编程范式遵循既定的约束。这种约束虽然带来了开发上的便捷，可是在必定程度上制约了代码的可移植性。例如，在项目中使用了某个构建工具来解决项目需求，可是若是有一天项目须要更换另外一个构建工具时，代码中原有的构建工具的配置会成为冗余代码，并且不能保证这类配置不会对新构建工具产生冲突。即使是没有产生冲突，对代码的性能优化也是会带来必定负面影响的。工程化方案做为一种服务，应该尽可能下降对项目产生的负面影响。这是制定编程范式约束规范时最重要的考虑因素。

      （8）项目部署流程化

      站在前端开发的范畴来讲，项目部署是指前端开发人员将构建产出的代码包部署到测试服务器的过程，而并不是是将测试完成的代码发布到生产环境的过程。在部署过程当中，要考虑目标服务器、路径信息是否与项目一一对应，而且可供负责部署到生产环境的开发人员进行配置，部署的操做流程应尽可能简单。

      在部署流程中，使用命令行取代工具执行（例如FTP）本地部署，可以极大的提升部署的速度和效率，可是这只是初级阶段的部署流程。考虑团队协做和安全方面的因素，最佳的方式应该是搭建一个可供严格审查、队列控制、操做简化的部署平台，而且有专人负责掌握流程进度。虽然这种搭建部署平台的方式在必定程度上减缓了总体的部署速度，可是增强了团队协做和安全保障。

      四、前端工程化将来的发展如何？

      目前，Web应用开发的分工模式还处于探索期，并且从最近流行的“大前端”的趋势来看，前端工程师的发展或许会突破Web领域，向多端领域发展，例如React Native、Weex、Electron、小程序等。从诞生之初“切图仔”到大前端概念，前端工程师的定位和负责的技术范畴一直在变化，可是前端工程师产出的服务对象永远是用户。在Node.js以前，浏览器是前端工程师生存的“一亩三分地”，Node.js的出现打破了这个局面，以至出现了“大前端”的发展趋势。

      Node.js中间层+浏览器是目前实现“大前端”的基本模式，前端工程师掌握着与用户相关的全部资源，可以全面地掌握开发进度以及实现更合理的先后端分离方案。这种模式让前端工程师突破浏览器的瓶颈，迈向Web应用层面，这也是将来前端发展的主流趋势。

      不管是专一于浏览器，仍是兼顾了Node.js中间层，前端工程师的利剑始终指向的是面向浏览器的Web领域，前端工程化所提供的是一种服务，服务对象是不断参与到项目迭代过程当中的前端开发人员，服务的内容涉及到开发、构建、部署等各个环节。

      前端工程师在将来的定位必然会发生变化，可是前端工程化惟一不变的原则是始终之前端开发为中心，前端工程化没有统一的行业标准，也没有固定的形态，更没有最合理的方案，只要前端工程师的定位还在不断的变化，前端工程化的进程将会一直持续下去。

想要学习web前端的同窗，能够参考千锋成都web前端培训班提供的学习大纲；