前端工程化

工程化即系统化、模块化、规范化的一个过程。如果说计算机科学要解决的是系统的某个具体问题，或者更通俗点说是面向编码的，那么工程化要解决的是如何提高整个系统生产效率。

Web

前端工程化包含如下：

1.代码规范: 保证团队所有成员以同样的规范开发代码。
2.分支管理: 不同的开发人员开发不同的功能或组件，按照统一的流程合并到主干。
3.模块管理: 一方面，团队引用的模块应该是规范的;另一方面，必须保证这些模块可以正确的加入到最终编译好的包文件中。（以上两点可以总结为模块化或者组件化开发。）
4.自动化测试：为了保证和并进主干的代码达到质量标准，必须有测试，而且测试应该是自动化的，可以回归的。
5.构建：主干更新以后，自动将代码编译为最终的目标格式，并且准备好各种静态资源，
6.部署。 将构建好的代码部署到生产环境。

一、模块化

定义： 模块化就是将一个大文件拆分成相互依赖的小文件，再进行统一的拼装和加载。（方便了多人协作）。

JS模块化方案：

1、CommonJS的核心思想是把一个文件当做一个模块，要在哪里使用这个模块，就在哪里require这个模块，然后require方法开始加载这个模块并且执行其中的代码，最后会返回你指定的export对象。
CommonJS 加载模块是同步的，所以只有加载完成才能执行后面的操作，不能非阻塞的并行加载多个模块。
2、AMD（异步模块定义，Asynchronous Module Definition），特点是可以实现异步加载模块，等所有模块都加载并且解释执行完成后，才会执行接下来的代码。
3、ES6 的模块功能汲取了CommonJS 和 AMD 的优点，拥有简洁的语法并支持异步加载，并且还有其他诸多更好的支持（例如导入是实时只读的。（CommonJS 只是相当于把导出的代码复制过来））。

CSS模块化方案：

在less、sass、stylus等预处理器的import/mixin特性支持下实现、css modules。
虽然SASS、LESS、Stylus等预处理器实现了CSS的文件拆分，但没有解决CSS模块化的一个重要问题：选择器的全局污染问题;
CSS in JS是彻底抛弃CSS，使用JS或JSON来写样式。这种方法很激进，不能利用现有的CSS技术，而且处理伪类等问题比较困难；
CSS Modules 原理：使用JS 来管理样式模块，它能够最大化地结合CSS生态和JS模块化能力，通过在每个 class 名后带一个独一无二 hash 值，这样就不有存在全局命名冲突的问题了。
webpack 自带的 css-loader 组件，自带了 CSS Modules，通过简单的配置即可使用。

二、组件化

定义：

将一个完整的页面/系统/产品，根据功能性、复用性

页面上所有的东西都是组件。页面是个大型组件，可以拆成若干个中型组件，然后中型组件还可以再拆，拆成若干个小型组件，小型组件也可以再拆，直到拆成DOM元素为止。DOM元素可以看成是浏览器自身的组件，作为组件的基本单元。

组件化实际上是一种按照模板(HTML)+样式(CSS)+逻辑(JS)三位一体的形式对面向对象的进一步抽象。

实现方案：

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

目录结构的制定

目录结构的合理设定，能为项目带来很多优点：

有助于提高项目的逻辑结构合理性；
对应扩展和合作；
方便资源的统一定位管理。

编码规范

制定一套良好的编码规范可以增强团队开发协作、提高代码质量。

推荐参考凹凸实验室打造的前端代码规范。

编码规范包括：

HTML规范

基于 W3C、苹果开发者等官方文档，并结合团队业务和开发过程中总结的规范约定，让页面HTML代码更具语义性。

CSS规范

统一规范团队 CSS 代码书写风格和使用 CSS 预编译语言语法风格，提供常用媒体查询语句和浏览器私有属性引用，并从业务层面统一规范常用模块的引用。

JS规范

统一规范团队 CSS 代码书写风格和使用 CSS 预编译语言语法风格，提供常用媒体查询语句和浏览器私有属性引用，并从业务层面统一规范常用模块的引用。

图片规范

了解各种图片格式特性，根据特性制定图片规范，包括但不限于图片的质量约定、图片引入方式、图片合并处理等，旨在从图片层面优化页面性能。

命名规范

从目录、图片、HTML/CSS文件、ClassName 的命名等层面约定规范团队的命名习惯，增强团队代码的可读性。

前后端接口规范

“基于 Ajax 带来的 SPA 时代”，这种模式下，前后端的分工非常清晰，前后端的关键协作点是 Ajax 接口，引发一个重要问题：前后端的对接界面双方却关注甚少，没有任何接口约定规范情况下各自撸起袖子就是干，导致我们在产品项目开发过程中，前后端的接口联调对接工作量占比在30%-50%左右，甚至会更高。往往前后端接口联调对接及系统间的联调对接都是整个产品项目研发的软肋。
接口规范主要初衷就是规范约定先行，尽量避免沟通联调产生的不必要的问题，让大家身心愉快地专注于各自擅长的领域。

对于这一SPA阶段，前后端分离有几个重要的关注挑战：

职责分离

前后端仅仅通过异步接口(AJAX/JSONP)来编程；
前后端都各自有自己的开发流程，构建工具，测试集合；
关注点分离，前后端变得相对独立并松耦合。

规范原则

接口返回数据即显示，前端仅做渲染逻辑处理；
渲染逻辑禁止跨多个接口调用；
前端关注交互、渲染逻辑，尽量避免业务逻辑处理的出现；
请求响应传输数据格式：JSON，JSON数据尽量简单轻量，避免多级JSON的出现；

响应格式

响应基本格式及处理状态值的规范
基本响应格式
列表响应格式

特殊内容

下拉框、复选框、单选框统一由后端逻辑判定选中返回给前端展示；
关于Boolean类型，JSON数据传输中一律使用1/0来标示，1为是/True，0为否/False
关于日期类型，JSON数据传输中一律使用字符串，具体日期格式因业务而定；

文档规范

组件管理

git分支管理

三、自动化

前端工程化的很多脏活累活都应该交给自动化工具来完成。

需要秉持的一个理念是:

任何简单机械的重复劳动都应该让机器去完成
图标合并
持续继承
自动化构建
自动化部署
自动化测试

工程化

欢迎访问：个人博客地址