前端工程化概述

工程化出现的原因

从广义上来讲，前端工程化其实就是遵循一定的标准和规范，通过工具去提高生产效率，降低开发成本的一种方式。

工程化在近些年被广泛的关注和探讨，其主要原因主要是因为现代化前端应用功能要求在不断提高，业务逻辑变得日益复杂。

前端技术作为当下互联网时代唯一不可或缺的技术，前端可以说是占据了整个开发行业的半壁江山。

从传统的网站，到现在的H5, 小程序，移动App, 桌面应用等等。前端技术几乎是无所不能的全面覆盖。尤其是Node的发展，更是将前端推向了前所未有的高度。

抛开这些表象问题深入到本质，也是行业对开发人员的要求发生了天翻地覆的变化。

以往前端写demo，套模板，调页面这种刀耕火种的方式已经完全不符合当下对开发效率的要求，前端工程化就是在这样一个背景下被提上台面，成为前端工程师必备的开发方式之一。

我们常说，技术往往是为了解决问题而存在的，前端工程化也不例外，我们这里列举一些大家在日常开发过程当中经常会面临的一些问题。来简单说明前端工程化解决的究竟是什么样的问题。

首先第一点比如说你想要在开发过程中使用ES6，ES7这些新的语法特性，去提高我们的编码效率和技术能力，但是我们都知道浏览器的更新速度虽快但用户更新的速度确相对较慢，这些特性很多情况下是不被旧版本的浏览兼容的。

再比如我们想要去使用Less或者Sass或者PostCSS这样的工具去提高CSS的编程性，但是这种工具在我们的运行环境中是没有办法直接被支持的。

还有就是我们想要去使用像模块化或者组件化方式去提高我们项目的可维护性，但这两种方式在我们实际运行环境当中同样也不能直接被支持。

那除了这些支持的工作以外还有一些我们在开发过程中经常会手动去做的一些重复性工作也比较明显，比如说部署上线前需要手动压缩代码及资源文件，部署过程需要手动上传代码到服务器。

机器去取代人做这种重复性的工作，实际上是很合理的，因为机器不会像人一样经常犯错误。

除了这些之外还有就是多人协作开发，无法硬性统一大家的代码风格，这也就导致从仓库中pull回来的代码质量无法保证，经常出现从从库中拉回来的代码无法运行。

除了这些我们每个人都会遇到在开发具体功能的时候会发现有很多的功能我们需要去等待后端服务接口提前完成，我们才可以做具体的编码。

因为有了这些问题，才有了前端工程化，当然工程化解决的问题远不止这些。我们一般总结成以下几点。

第一点就是传统语言或语法的弊端，在一个就是我们没有办法直接去使用模块化或者是组件化这样的方式去组织我们的代码。还有就是我们在日常开发过程中有大量的重复的机械式工作。

还有就是我们很难去统一各个开发人员之间的编码风格以及对我们仓库的代码做质量保证。

最后就是我们在开发的过程中整个前端项目对后端的依赖是非常严重的，不仅仅是我们在编码的时候还有我们在部署的时候，因为我们需要把项目打包放到后端项目当中，才可以去做部署工作。

工程化的出现可以很好的为我们解决这些问题。

什么是前端工程化

总结一句话，一切以提高效率，降低成本，质量保证为目的的手段都属于工程化。一切重复的工作都应该被自动化。

工程化既然说是一个工程，那他就体现在一个项目周期的各个环节，从项目创建 - 编码 - 预览、测试 - 提交 - 部署 - 监控，每一个环节都可以通过过程化的方式，大大的提高我们的效率。

我们可以在创建项目的阶段使用脚手架工具，自动的帮我们完成基础结构的搭建。

在编码环节，我们可以借助工程化的工具自动化的去帮我们做一些代码格式化，代码风格校验，代码的编译，构建，打包。从而去确保我们每一个开发人员写出的代码都是相同的风格，除此之外我们还可以借助编译工具让我们在开发阶段直接可以使用一些新的特性，提高编码效率。

传统的预览环节我们可能需要借助apache或者nginx这样的web服务器提供一个基础的Web服务，让我们的应用可以在上面运行起来，这种传统的web服务是没办法提供一些热更新体验的。

对于现代化的web工具是可以提供热更新的体验的，热更新就是我们再编码完成过后就可以在浏览器里面直接看到最新的效果，不用手动刷新，这是一个十分友好的开发体验。

除此之外，我们在开发阶段肯定会用到编译，编译就是实际编写的代码和最终运行的代码之间有一个转换。

如果实际运行时出现了一些问题，需要去定位源代码对应的位置，我们就需要借助source-map这样的工具去完成。

除此之外呢，我们需要有一些类似mock的方式去解决我们再后端服务未完成的情况下，我们怎么样去提前开发具体的业务功能，这也就是常说的假接口的方式，只不过这个假接口和真实的后端接口是以相同的规格存在的。

在我们提交代码的阶段，我们可以使用githooks这样的工具配合lint工具，自动化的在我们代码提交之前去做项目整体的检查，包括项目质量的检查和代码风格的检查，确保我们不会把有问题的代码提交到仓库当中，这样也就解决了我们之前说的从仓库当中拉回的代码无法运行的问题。

除了对项目的质量做检查之外甚至连提交的日志也就是我们说的gitlog都可以做严格的限制，这样一来我们就可以在日后做回滚的时候有很大的参考价值。

在部署环节，工程化表现出来的功能会更多，开发者可以用一行上传命令去代替传统的ftp，甚至还可以去实现在代码提交过后自动化的通过持续集成或者持续部署的方式自动将我们上传的代码部署到服务器，这也就避免了我们手动，人为去操作产生的一些不稳定因素。

工程化不等于工具

工程化的核心应该是对项目整体的一种规划或者架构，而工具在这个过程中只是用来帮我们落地实现这种规划或架构的一种手段。很多人一提到工程化就会想到weppack，其实并不是这样，webpack是一个打包工具，或者说他是工程化当中的一环。但并不是整个工程化。

我们以一个非常普通的项目为例，落实工程化的第一件事应该是规划一个项目整体的工作流架构，其中包括我们要规划文件的组织结构，源代码的开发范式。

开发范式就是我们使用什么样的语法，什么样的规范，什么样的标准。

我们要通过什么样的方式实现前后端的分离，是基于ajax做前后端分离还是基于中间层去做分离。这些都是我们一开始的时候先明确的一个规划。

有了这些整体的规划之后，我们再具体去考虑，我们应该选择搭配哪些工具去做哪些具体的配置选项。去实现我们工程化整体的一个规划，这才是工程化应该有的过程。

可以从一些成熟的工程化方案中找到一些思路，比如create-react-app, vue-cli, angular-cli, gatsby-cli, 这些并不只是简单的脚手架，这些应该是属于特定类型的项目，官方给出的集成式工程化方案。

这里我们拿vue-cli来举例说明

vue-cli不仅仅创建了项目，更多的是约定了vue的项目应该是一个什么样的结构，它为我们做了很多文件和文件夹的约定。除了约定之外还提供了很多工具，让开发者可以有热更新的开发服务，自动编译vue的单文件组件，以及一些其他的模块文件。除此之外还可以做一些代码风格的校验，也就是lint。

这些东西实际上都是集成在vue-cli的一些service当中的，现在我们再来看 vue-cli 我们就知道，他并不是只为我们创建了项目，更多的还是后面的一系列东西，这些东西就是我们说的工程化主要的几个维度，可以说，上面这些脚手架，是工程化的集成。

最后回到主题工程化并不是工具，这一点不要弄混了。

NodeJs对工程话的意义

node的出现，对于前端而言除了让javascript有了一个新的舞台，更多是的让整个前端行业进行了一次革命。没有node就没有前端今天的辉煌。

可以毫不夸张的说，没有NodeJS就没有今天的前端，而且在很长一段时间当中我们用到的工具，几乎都是用NodeJS开发的。

所以说前端工程化是由NodeJS强力驱动的，除了这些，工程化看来实际上是个十分庞大的概念，这个过程也在不断的成长和发展，值得强调的是不管他如何发展，始终他都是为了解决问题而存在的，切莫为了技术而技术。