什么叫前端工程化

在回答这个问题之前，我先回顾一下前端的历史。大约78年前，前端工程师还不是一个受人重视的职位，日常工作也就是切个图，使用JQuery写个脚本，从某种意义上讲，只是后端的附属物。最近几年，尤其是在nodejs出现之后，前端越来越受到重视，甚至已经开始抢占了后端的市场。这同时也带来了一个问题，前端的规模越来越大，已经上升到了工程学的问题，如何提高前端工程师的开发效率变得非常重要。这就是前端工程化所要解决的问题。前端工程化是根据业务特点，将前端开发流程规范化，标准化，它包括了开发流程，技术选型，代码规范，构建发布等，用于提升前端工程师的开发效率和代码质量。

如何实现前端工程化

回答这个问题应该从一个前端工程的生命周期说起，在这个生命周期中任何的优化都应属于前端工程化的范畴。

任何一个软件工程大致上分为以上三步: 开发 -> 测试 -> 部署上线。具体到前端工程中，每一步又涵盖了很多细节。
开发阶段 - 前端三剑客为HTML, CSS和Javascript，运行环境为浏览器。但是大家在开发的过程中感觉原生的HTML, CSS和Javascript效率并不高，于是出现了模板，SCSS，Coffeescript/Typescript等中间型语言用于转义为原生的语言(ES6也属于这类情况)，所以应提供相关的构建工具用于转义。再者，在开发过程中，开发者希望在编码时，能够立马在浏览器中反应出变化，这又要求了自动刷新。同时在开发中，还面临过着JS依赖管理，性能优化等方面的问题。
测试阶段 - 前端本质上属于GUI的一种，所以不可避免的要有E2E(End to End Test)和保证功能的单元测试，测试的过程理应自动化，开发者只需要写出相应的测试用例，剩下的交给工程化框架去自动执行并反馈给开发者结果。
部署阶段 - 我相信没有任何一个前端工程师会傻逼到将开发后的代码直接推到线上，当你使用Chrome开发者工具去看别人的网站时，一般都是压缩过的代码。部署时候代码的组织形式肯定与开发时有很大的差异，例如从优化的角度上来说，要对代码进行压缩，静态资源部署到静态服务器上，对文件加上md5防止浏览器使用旧缓存等。关于部署的问题，大家可以参考张云龙的经典博文: 大公司是怎么开发和部署代码。

我的一些前端工程化实践

我在上一家公司工作时，前端的架构比较简单，典型的angular工程加上gulp去进行构建。当你手里有一把锤子时，你看什么都是钉子。这造成了很长一段时间内对前端工程化的理解就是使用gulp等构建工具。为什么gulp不能完全算是前端工程化解决方案呢？首先先看看gulp帮我们解决了哪些东西和没有解决哪些东西。通常情况下对gulp的使用会借助gulp的各种插件，以一种工作流的形式对代码进行检查，执行压缩，移动到相关目录下，发布到git仓库等。从某种意义上来说，gulp确实帮助提高了开发的效率，但是它所做的东西很有限，它只是帮我们进行了构建，而且构建方案需要我们自己去写，自由度相对较大，也没有解决开发目录约束，代码规范等一系列问题。

业界的一些前端工程化方案

一个符合前端工程化要求的方案应该包含以下要素:

开发规范
模块化开发
组件化开发
组件仓库
性能优化
部署
开发流程
开发工具

业界中比较优秀的方案有:

百度fis
UC scrat
腾讯mtjs

由于对第一种和第三种方案不太熟悉，我主要谈谈scrat是怎么解决前端工程化中的各种问题。
scrat包括两部分: 构建方案和前端模块化框架scrat.js。构建方案首先从开发目录结构对工程进行了约束，目录结构大致如下:
├─ component_modules (生态模块)
├─ components (工程模块)
├─ views (非模块化资源)
├─ ...
它将静态资源分为两种:
模块化资源: 具有独立性的模块所对应的静态资源。每个独立的模块将自己所需要的js、css、模板、图片等资源放在一起维护，使得模块具备独立性，引用模块的js即可。
非模块化资源: 虽然在模块化开发体系内，应该一切皆模块，但总有不应该成为模块的资源，比如入口页面、模块化框架、页面启动器等。
它定义自己的模块化系统，认为模块是可组合，可分解和更换的单元。工程师可以像搭积木一样开发和维护系统，通过组装得到一个完整的系统。scrat.js作为模块化开发框架，实现了js/css依赖管理，请求合并，按需加载，本地缓存等功能，达到效果优化。具体使用方案请参考其官网。

前端工程化还有哪些需要考虑的

我能想到的还有以下这些:
git工作流 - 如何提交代码？
Node中间层 - 用于渲染一部分模板和路由等。
CI/CD - 主要利用git hooks通知CI，执行对应的脚本(如gitlab)。
监控 - 前端监控主要分为性能监控和业务监控，它应支持自由配置各种报表和一系列报警规则。