前端工程化的目的：
-
解放生产力。对源代码进行预处理、自动打包/自动更新页面显示、去处理图片依赖和正式环境统一这几点在开发中极大提高了开发的效率。在搭建起项目工程之后开发人员只需要关注业务/代码即可。
- 保证项目质量，在多人协作，不同环境下开发。通过code lint等约束以及git commit预处理保证代码风格的一致统一，这一点对后续的代码维护很重要。
- 优化。通过前端工程化、自动化去合理的压缩合并资源文件。
前端工程化需要考虑哪些因素？
本人总结经验，认为前端工程化主要应该从模块化、组件化、规范化、自动化四个方面来思考，下面一一展开。
模块化
简单来说，模块化就是将一个大文件拆分成相互依赖的小文件，再进行统一的拼装和加载。只有这样，才有多人协作的可能。
js的模块化
在ES6之前，JavaScript一直没有模块系统，这对开发大型复杂的前端工程造成了巨大的障碍。对此社区制定了一些模块加载方案，如CommonJS、AMD和CMD等。现在ES6已经在语言层面上规定了模块系统，完全可以取代现有的CommonJS和AMD规范，而且使用起来相当简洁，并且有静态加载的特性。
css的模块化
虽然SASS、LESS、Stylus等预处理器实现了CSS的文件拆分，但没有解决CSS模块化的一个重要问题：选择器的全局污染问题。
所以我很赞同这句话：
与其费尽心思地告诉别人要遵守某种规则，以规避某种痛苦，倒不如从工具层面就消灭这种痛苦。
从工具层面，社区又创造出Shadow DOM、CSS in JS和CSS Modules三种解决方案。
-
Shadow DOM是WebComponents的标准。它能解决全局污染问题，但目前很多浏览器不兼容，对我们来说还很久远；
- CSS in JS是彻底抛弃CSS，使用JS或JSON来写样式。这种方法很激进，不能利用现有的CSS技术，而且处理伪类等问题比较困难；
- CSS Modules仍然使用CSS，只是让JS来管理依赖。它能够最大化地结合CSS生态和JS模块化能力，目前来看是最好的解决方案。Vue的scoped style也算是一种。
资源的模块化
Webpack的强大之处不仅仅在于它统一了JS的各种模块系统，取代了Browserify、RequireJS、SeaJS的工作。更重要的是它的万能模块加载理念，即所有的资源都可以且也应该模块化。
组件化
首先，组件化≠模块化。好多人对这两个概念有些混淆。
模块化只是在文件层面上，对代码或资源的拆分；而组件化是在设计层面上，对UI（用户界面）的拆分。
从UI拆分下来的每个包含模板(HTML)+样式(CSS)+逻辑(JS)功能完备的结构单元，我们称之为组件。
其实，组件化更重要的是一种分治思想。
这句话就是说页面上所有的东西都是组件。页面是个大型组件，可以拆成若干个中型组件，然后中型组件还可以再拆，拆成若干个小型组件，小型组件也可以再拆，直到拆成DOM元素为止。DOM元素可以看成是浏览器自身的组件，作为组件的基本单元。
规范化
模块化和组件化确定了开发模型，而这些东西的实现就需要规范去落实。
规范化其实是工程化中很重要的一个部分，项目初期规范制定的好坏会直接影响到后期的开发质量。
我能想到的有以下一些内容：
- 目录结构的制定
- 编码规范
- 前后端接口规范
- 文档规范
- 组件管理
- Git分支管理
- Commit描述规范
- 定期CodeReview
- 视觉图标规范
自动化
任何简单机械的重复劳动都应该让机器去完成。
-
图标合并
- 不要再用PS拼雪碧图了，统一走Webpack吧；
- 不要再用Icomoon了，统一走Webpack吧。
-
持续集成
-
自动化构建
-
自动化部署
-
自动化测试
