转载--web前端工程化

       

做者：赵雨森
连接：https://www.zhihu.com/question/24558375/answer/139920107
来源：知乎

## 模块化

简单来讲，模块化就是 将一个大文件拆分红相互依赖的小文件，再进行统一的拼装和加载。只有这样，才有多人协做的可能。

### JS的模块化

在ES6以前，JavaScript一直没有模块系统，这对开发大型复杂的前端工程形成了巨大的障碍。对此社区制定了一些模块加载方案，如CommonJS、AMD和CMD等，某些框架也会有本身模块系统，好比Angular1.x。

如今ES6已经在语言层面上规定了模块系统，彻底能够取代现有的CommonJS和AMD规范，并且使用起来至关简洁，而且有静态加载的特性。

规范肯定了，而后就是模块的打包和加载问题：
1. 用 Webpack+ Babel将全部模块打包成一个文件同步加载；
2. 用 SystemJS+ Babel分模块异步加载；
3. 将二者结合在一块儿。

### CSS的模块化

虽然SASS、LESS、Stylus等预处理器实现了CSS的文件拆分，但没有解决CSS模块化的一个重要问题：选择器的全局污染问题。

按道理，一个模块化的文件应该要隐藏内部做用域，只暴露少许接口给使用者。而按照目前预处理器的方式，导入一个CSS模块后，已存在的样式有被覆盖的风险。虽然重写样式是CSS的一个优点，但这并不利于多人协做。

为了不全局选择器的冲突，各厂都制定了本身的CSS命名风格：

• BEM风格；
• Bootstrap风格；
• Semantic UI风格；
• 咱们公司的NEC风格；
• ...

但这毕竟是弱约束。选择器随着项目的增加变得越多越复杂，而后项目组里再来个新人带入本身的风格，就更加混乱了。

因此我很赞同这句话：

与其费尽心思地告诉别人要遵照某种规则，以规避某种痛苦，倒不如从工具层面就消灭这种痛苦。

从工具层面，社区又创造出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也属于这一种。

## 组件化

首先，组件化≠模块化。好多人对这两个概念有些混淆。

模块化只是在语言层面上，对代码的拆分；而组件化是基于模块化，在设计层面上，对UI（用户界面）的拆分。

从UI拆分下来的 每一个包含模板(HTML)+样式(CSS)+逻辑(JS)功能完备的结构单元，咱们称之为组件。

其实，组件化更重要的是一种 分治思想。

Keep Simple. Everything can be a component.

这句话就是说页面上全部的东西都是组件。页面是个大型组件，能够拆成若干个中型组件，而后中型组件还能够再拆，拆成若干个小型组件，小型组件也能够再拆，直到拆成DOM元素为止。DOM元素能够当作是浏览器自身的组件，做为组件的基本单元。

传统前端框架/类库的思想是先组织DOM，而后把某些可复用的逻辑封装成组件来操做DOM，是DOM优先；而组件化框架/类库的思想是先来构思组件，而后用DOM这种基本单元结合相应逻辑来实现组件，是组件优先。这是二者本质的区别。

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

因此咱们除了封装组件自己，还要合理处理组件之间的关系，好比 （逻辑） 继承、 （样式） 扩展、 （模板） 嵌套和 包含等，这些关系均可以归为 依赖。

其实组件化不是什么新鲜的东西，之前的客户端框架，像WinForm、WPF、Android等，它们从诞生的那天起就是组件化的。而前端领域发展曲折，是从展现页面为主的WebPage模式走过来的，近两年才从客户端框架经验中引入了组件化思想。其实咱们不少前端工程化的问题均可以从客户端那里寻求解决方案。

目前市面上的组件化框架不少，主要的有 Vue、 React、 Angular 2、咱们公司

@ 郑海波

的Regular、Avalon等。你感兴趣能够都研究一下，选择一套中意的。其实Vue文档中的对比其余框架一文已经讲得很详细了。

## 规范化

模块化和组件化肯定了开发模型，而这些东西的实现就须要规范去落实。
规范化实际上是工程化中很重要的一个部分，项目初期规范制定的好坏会直接影响到后期的开发质量。

我能想到的有如下一些内容：

• 目录结构的制定
• 编码规范
• 先后端接口规范
• 文档规范
• 组件管理
• Git分支管理
• Commit描述规范
• 按期CodeReview
• 视觉图标规范
• ...

其中编码规范最好采起ESLint和StyleLint等强制措施，由于人是靠不住的，好比能够Lint通不过不能提交代码等。
先后端接口管理能够了解一下咱们公司出的NEI - 接口管理平台。

## 自动化

做了这么多年程序猿的我，一直秉持的一个理念是：

任何简单机械的重复劳动都应该让机器去完成。

因此我也认为，前端工程化的不少脏活累活都应该交给自动化工具来完成。

### 图标合并

• 不要再用PS拼雪碧图了，有Gulp+SpriteSmith；
• 不要再用Icomoon了，这仍然是半自动的，有FontCustom。

### 持续集成
### 自动化构建
### 自动化部署
### 自动化测试

前端自动化测试可以提升代码质量、减小人肉测试等，这些优势是不言而喻的。
市面上前端测试框架有不少，选择哪一个都不会有太大问题，咱们用的是：
Karma + Mocha + Chai

### 构建工具

最后就是你的团队可能不仅一个项目，若是每一个项目都搭一套gulp+webpack+babel+...，维护成本比较高，并且不能保证统一性。

所以基于Gulp实现一套独立于项目的构建工具是最好的解决方案。

能够参考一下网易蜂巢的构建工具rainfore/pursuit-cli，开发者只要会用pursuit dev和pursuit online两句命令就行。