前端模块化开发(前端模块化开发)

如何理解前端模块化

前端模块化

在JavaScript发展初期就是为了实现简单的页面交互逻辑，寥寥数语即可；如今CPU、浏览器性能得到了极大的提升，很多页面逻辑迁移到了客户端（表单验证等），随着web2.0时代的到来，Ajax技术得到广泛应用，jQuery等前端库层出不穷，前端代码日益膨胀

这时候JavaScript作为嵌入式的脚本语言的定位动摇了，JavaScript却没有为组织代码提供任何明显帮助，甚至没有类的概念，更不用说模块（module）了，JavaScript极其简单的代码组织规范不足以驾驭如此庞大规模的代码

既然JavaScript不能handle如此大规模的代码，我们可以借鉴一下其它语言是怎么处理大规模程序设计的，在Java中有一个重要带概念——package，逻辑上相关的代码组织到同一个包内，包内是一个相对独立的王国，不用担心命名冲突什么的，那么外部如果使用呢？直接import对应的package即可

importjava.util.ArrayList;

遗憾的是JavaScript在设计时定位原因，没有提供类似的功能，开发者需要模拟出类似的功能，来隔离、组织复杂的JavaScript代码，我们称为模块化。

一个模块就是实现特定功能的文件，有了模块，我们就可以更方便地使用别人的代码，想要什么功能，就加载什么模块。模块开发需要遵循一定的规范，各行其是就都乱套了

规范形成的过程是痛苦的，前端的先驱在刀耕火种、茹毛饮血的阶段开始，发展到现在初具规模，简单了解一下这段不凡的历程

我们在讲函数的时候提到，函数一个功能就是实现特定逻辑的一组语句打包，而且JavaScript的作用域就是基于函数的，所以把函数作为模块化的第一步是很自然的事情，在一个文件里面编写几个相关函数就是最开始的模块了

functionfn1(){

statement

functionfn2(){

statement

这样在需要的以后夹在函数所在文件，调用函数就可以了

这种做法的缺点很明显：污染了全局变量，无法保证不与其他模块发生变量名冲突，而且模块成员之间没什么关系。

为了解决上面问题，对象的写法应运而生，可以把所有的模块成员封装在一个对象中

varmyModule={

var1:1,

var2:2,

fn1:function(){

fn2:function(){

这样我们在希望调用模块的时候引用对应文件，然后

myModule.fn2();

这样避免了变量污染，只要保证模块名唯一即可，同时同一模块内的成员也有了关系

看似不错的解决方案，但是也有缺陷，外部可以随意修改内部成员

myModel.var1=100;

这样就会产生意外的安全问题

立即执行函数

可以通过立即执行函数，来达到隐藏细节的目的

varmyModule=(function(){

varvar1=1;

varvar2=2;

functionfn1(){

functionfn2(){

return{

fn1:fn1,

fn2:fn2

})();

这样在模块外部无法修改我们没有暴露出来的变量、函数

上述做法就是我们模块化的基础，目前，通行的JavaScript模块规范主要有两种：CommonJS和AMD

CommonJS

我们先从CommonJS谈起，因为在网页端没有模块化编程只是页面JavaScript逻辑复杂，但也可以工作下去，在服务器端却一定要有模块，所以虽然JavaScript在web端发展这么多年，第一个流行的模块化规范却由服务器端的JavaScript应用带来，CommonJS规范是由NodeJS发扬光大，这标志着JavaScript模块化编程正式登上舞台。

根据CommonJS规范，一个单独的文件就是一个模块。每一个模块都是一个单独的作用域，也就是说，在该模块内部定义的变量，无法被其他模块读取，除非定义为global对象的属性

模块输出：

模块只有一个出口，module.exports对象，我们需要把模块希望输出的内容放入该对象

加载模块：

加载模块使用require方法，该方法读取一个文件并执行，返回文件内部的module.exports对象

如何实现前端模块化开发

前端如果想做模块化开发，首先需要针对每一种资源（

JavaScript

、模板等）寻找

一种模块与集成方案，然后需要根据情况的不同选用不同的工具框架拼凑出来。

SeaJS

是一个适用于

浏览器端的模块加载器。使用

SeaJS

，可以更好地组织

JavaScript

不知道别人怎么做的，我自己现在的做法是，基本通用的功能做成一个

style

样式，只需要一个

调用一下就

了，比如图片上传。而一

些常用但不通用的功能做成一组文件，包括

结构还有一个

文件，也可

能还有图片什么的，有时候甚至做成不用调用，直接加载就能用。

至于具体的调用方法，

window

定义一个变量，

放入调用的这个功能的

function

初始化一个模块，

并返回这个模块闭包中的一些方法用来操作或者获取和设置一些模块闭包

内的变量。

JavaScript

目前比较拿的出手的，也就是

JavaScript

的模块化，比如

等等，分别可以使

RequireJS

SeaJS

去年在研究基于

Backbone

Marionette

Sea.js

结合使用。现在来看这种组合

是完全没有必要的。

Marionette

提供了模块化的组织方案，反而生拉硬扯在一起，冲突得很

难受。其实把

JavaScript

文件一列放在

中也没什么问题。

究竟使用什么来实现

JavaScript

往往与选择的

JavaScript

框架有关，

Backbone

AngularJS

直接引用就行。

模块化应该是两方面的问题——

一是模块必须有一套基础样式。与

JavaScript

冲突简直是家常便饭，

ShadowDOM

还没成熟，

样式隔离还在路上。

所以必须有一套基础样式来规定这一套模块化组

件的样式。我们可以选

Bootstrap

，如果闲它太重，也可以自己写。

其次，每个组件必须有命名空间，避免组件间样式冲突。如果选择使用

就比较好办，它们的缩进语法避免写很多重复的

AngularJS

AngularJS

已经帮您解决了模板模块化的问题，

AngularJS

可以根据模

块代码中的引用加载对应的

。如果使用

Backbone

，可以选择各种各样的模板引擎，

Mustache

？不过比起

AngularJS

就低端些，我们必须自己处理模板文件，要么通过模块加载

请求，然后动态编译；或者将

Mustache

，在当做模块加载。

图片旅游网站模板、字体？

放在使用他们的模块中，该怎么引用就怎么引用。

国际化文件？这些就不多说了，总之，每种文件需要选定一种开发的组织方式。

模块采用统一的模式来开发之后，只需选定一种包的分发方式就行了——

Bower

合这样的场景，

的版本管理太过细致了。如果同一个项目中允许出现同一模块的不同

版本，事情就做的太过复杂了。

发布上线必须一个以终为始的过程。

如果你不追求网站或者应用的速度，

那就把那些开发文

件直接丢到生产服务器上去吧。别说，我还真见过这样的商用的网站。

如果讲究一些方案，

资源合并成数个文件，

代码线上组合和运行方式完全可以与本地开发不

一样。只需要功能在就行。

JavaScript

代码打成一个文件，或者两个？都行。如果使用

RequireJS

RequireJS

包的工具，打包成几个文件，什么粒度，都行。如果是

Sea.js

也有对应的工具。就算文件都

是一个一个列出来，我们也总是可以打出来你想要的文件。

等等其他资源都是如此，就算开发时各自不同的结构模式，打包时都是可以打的。

，版本号缓存什么的并不在本文的讨论范围之内。

前端模块没有什么特效药。唯一要遵守的原则就是，

Node.js

来讲，每种资源必须要

有一种自己的开发和上线组织方式

Node.js

开发和上线都是一致的）

，开发和上线完全可

以是两种方式，

大可不必人云亦云，

只要适合可以随意组合；

CSSScopedStyle

用之前，应该有一套基础样式和沙盒（模块样式命名空间）

每个模块中的

如果我们使用的框架是

Backbone

注定我们要将

JavaScript

模块，或者使用模块加载器的插件来实现。如果我们使用

AngularJS

AngularJS

Backbone

中的模块使用

AngularJS

Grunt

内联到页面中。

模块也没有固定的模式，没有固定的

来解脱我们。我们只能组合现有的工具！

就更不用说了，分开写，使用

来组织？再一次没有固定的模式没有

软件开发中，什么是模块化开发？

软件产品可以被看作是由一系列具有特定功能的组件组成，作为一个完整的系统也可以被分解成一系列功能模块，这些模块之间的相互作用就形成了系统的所有功能。

所谓模块是指可组成系统的、具有某种确定独立功能的半自律性的子系统，可以通过标准的界面和其他同样的子系统按照一定的规则相互联系而构成的更加复杂的系统。每个模块的研发和改进都独立于其他模块的研发和改进，每个模块所特有的信息处理过程都被包含在模块的内部，如同一个“黑箱”，但是有一个或数个通用的标准界面与系统或其他模块相互连接。

在软件的模块化开发过程中，把一个源代码的结构分割成一个元系统和一系列的模块。

元系统指的是一个能够保持系统运转的最小的系统。

模块是一个较大系统的独特的部件，它能够由设计者独立设计出来，同时又可以作为一个整体在系统中运转。

把一个大系统切割成互相独立的不同的小系统，可以使一些并不是经常见面的开发者减少必要的交流次数。

另外，一个旧版本的模块可以被新版的模块所替换，同时却又不影响整个系统的运转。

这样，在新模块中所增加的功能就可以及时在现存的系统中体现出来，同时也不需要更改系统中的其他模块。

高度模块化的源代码结构给软件开发者和使用者均带来了极大的好处。

开发者可以对具有某种特定功能的模块进行独立开发而不需要花时间去协调与其他模块之间的关系。

并且模块化开发不仅允许模块之间的水平开发，而且可以通过对类似模块之间的创新和竞争(开发新的模块或者对原有的模块进行改进)充分改善系统的功能。

另外，作为最终的用户来说，在安装系统的时候可以就个人的需求与偏好选择适合自己的模块。

模块化是复杂系统的一个共同特征，模块化的代码结构是由松散的组件构成的，是对一个系统完全意义上的分割，而不像完全集成的代码，各个组件之间存在很强的依赖关系，并不是完全通过界面来交换信息。

第一， 把一个系统分解成各个不同的子模块，不同的开发者专注于对其中某一模块的开发，一方面实现了劳动的分工，另一方面也提高了自由软件开发的效率。基于模块化的性质，每个模块在开发出来以后都可以通过一个被称作是内核的原系统进行信息交流，发挥整个模块的功能，同时也并不会影响其他模块功能的发挥。而且在各个不同的模块整合在一起后，由于外部性的存在，会使整个系统增加的功能要超过该模块本身的功能。在此过程中实现了价值的分割与整合。

第二， 对于开发者而言，基于模块化的自由软件开发具有更大的吸引力，其在参与开发过程中可以得到更高的期望收益。

第三， 在非模块化的软件开发过程中，存在着严重的“搭便车”现象，当一个开发者选择参与开发，其余的开发者就会选择“搭便车”，最终会导致软件的供给不足；在基于模块化的开发过程中，所有的开发者都更倾向于参与开发不同的模块，从而实现整个系统的开发。

MIS软件开发中的组件模式开发比较复杂，主要的阻力不在代码的实现过程中，因为这个工作通常只应该占据软件开发工作量的30％，而对业务需求的深度剖析、业务子系统的划分和业务组件的规划会占据约40-50％的工作量。

这些工作体现在设计阶段主要是对业务的广度、深度分析，把业务领域的对象元素进行细化，将业务操作划分为原子性功能，以此为基础构成业务组件，进而形成模块和子系统，同时业务操作之间的约束则需要逻辑化（代码系统可识别的逻辑）；在此过程中，原系统也就形成了，它便是在业务领域中必须的组件、模块和子系统的集合；外延的组件在原系统上通过组合或热差拔即能够满足不同规模、深度、特性的业务模式运转。

软件开发中，什么是模块化开发？

软件产品可以被看作是由一系列具有特定功能的组件组成，作为一个完整的系统也可以被分解成一系列功能模块，这些模块之间的相互作用就形成了系统的所有功能。

所谓模块是指可组成系统的、具有某种确定独立功能的半自律性的子系统，可以通过标准的界面和其他同样的子系统按照一定的规则相互联系而构成的更加复杂的系统。每个模块的研发和改进都独立于其他模块的研发和改进，每个模块所特有的信息处理过程都被包含在模块的内部，如同一个“黑箱”，但是有一个或数个通用的标准界面与系统或其他模块相互连接。

在软件的模块化开发过程中，把一个源代码的结构分割成一个元系统和一系列的模块。

元系统指的是一个能够保持系统运转的最小的系统。

模块是一个较大系统的独特的部件，它能够由设计者独立设计出来，同时又可以作为一个整体在系统中运转。

把一个大系统切割成互相独立的不同的小系统，可以使一些并不是经常见面的开发者减少必要的交流次数。

另外，一个旧版本的模块可以被新版的模块所替换，同时却又不影响整个系统的运转。

这样，在新模块中所增加的功能就可以及时在现存的系统中体现出来，同时也不需要更改系统中的其他模块。

高度模块化的源代码结构给软件开发者和使用者均带来了极大的好处。

开发者可以对具有某种特定功能的模块进行独立开发而不需要花时间去协调与其他模块之间的关系。

并且模块化开发不仅允许模块之间的水平开发，而且可以通过对类似模块之间的创新和竞争(开发新的模块或者对原有的模块进行改进)充分改善系统的功能。

另外，作为最终的用户来说，在安装系统的时候可以就个人的需求与偏好选择适合自己的模块。

模块化是复杂系统的一个共同特征，模块化的代码结构是由松散的组件构成的，是对一个系统完全意义上的分割，而不像完全集成的代码，各个组件之间存在很强的依赖关系，并不是完全通过界面来交换信息。

第一， 把一个系统分解成各个不同的子模块，不同的开发者专注于对其中某一模块的开发，一方面实现了劳动的分工，另一方面也提高了自由软件开发的效率。基于模块化的性质，每个模块在开发出来以后都可以通过一个被称作是内核的原系统进行信息交流，发挥整个模块的功能，同时也并不会影响其他模块功能的发挥。而且在各个不同的模块整合在一起后，由于外部性的存在，会使整个系统增加的功能要超过该模块本身的功能。在此过程中实现了价值的分割与整合。

第二， 对于开发者而言，基于模块化的自由软件开发具有更大的吸引力，其在参与开发过程中可以得到更高的期望收益。

第三， 在非模块化的软件开发过程中，存在着严重的“搭便车”现象，当一个开发者选择参与开发，其余的开发者就会选择“搭便车”，最终会导致软件的供给不足；在基于模块化的开发过程中，所有的开发者都更倾向于参与开发不同的模块，从而实现整个系统的开发。

MIS软件开发中的组件模式开发比较复杂，主要的阻力不在代码的实现过程中，因为这个工作通常只应该占据软件开发工作量的30％，而对业务需求的深度剖析、业务子系统的划分和业务组件的规划会占据约40-50％的工作量。

这些工作体现在设计阶段主要是对业务的广度、深度分析，把业务领域的对象元素进行细化，将业务操作划分为原子性功能，以此为基础构成业务组件，进而形成模块和子系统，同时业务操作之间的约束则需要逻辑化（代码系统可识别的逻辑）；在此过程中，原系统也就形成了，它便是在业务领域中必须的组件、模块和子系统的集合；外延的组件在原系统上通过组合或热差拔即能够满足不同规模、深度、特性的业务模式运转。