JavaScript模块化开发&&模块规范

在做项目的过程中通常会有一些可复用的通用性功能，之前的做法是把这个功能抽取出来独立为一个函数统一放到commonFunctions.js里面(捂脸),实现类似于snippets的代码片段收集。

　　function sub(){
　　　　//...
　　}
　　function sum(){
　　　　//...
　　}
　　

在理想情况下，开发者只需要实现核心的业务逻辑，其他通用功能可以加载已经实现的模块。

然而，这样的做法并不是最佳实践，在实际的运用中。业务代码时常会与应用的通用代码中的命名出现冲突。这让我想起了cSharp，当初学习cSharp的时候，一些有经验的学长就指点说，做.Net方向的一定要有自己的类库，这样在以后的开发中直接应用对应的命名空间，调用相关函数即可。于是乎琢磨起在目前尚没有命名空间的Javascript中，是不是可以用对象模拟命名空间作为替代方案呢？恰好与前辈想法暗合Why SeaJS

var FocusTech = {};
FocusTech.print = function(str){
// code！
}

然而其中的弊端文中也已给出。即通过命名空间，也只是降低函数命名冲突的概率。

命名冲突和文件依赖，面对前端开发过程中的这两个经典问题。或许前端模块化开发是一个解决方案。

模块规范

异步模块定义AMD：（Asynchronous Module Definition）是 RequireJS 在推广过程中对模块定义的规范化产出。通用模块定义CMD：（Common Module Definition）是Sea.js在推广过程中对模块定义的规范化产出的。

AMD 运行时核心思想是「Early Executing」，也就是提前执行依赖。EX：

define(['a', 'b'], function(A, B) {
//运行至此，a.js 和 b.js 已下载完成（运行于浏览器的 Loader 必须如此）；
//A、B 两个模块已经执行完，直接可用（这是 AMD 的特性）；

return function () {};
});

CMD 推崇 as lazy as possible.

在 CMD 规范中，一个模块就是一个文件。代码的书写格式如下：

define(factory);

AMD 是提前执行，CMD 是延迟执行。

CMD 推崇依赖就近，AMD 推崇依赖前置。看代码：

```javascript

// CMD

define(function(require, exports, module) {

var a = require('./a')

a.doSomething()

// 此处略去 100 行

var b = require('./b') // 依赖可以就近书写

b.doSomething()

// ...

})

// AMD 默认推荐的是

define(['./a', './b'], function(a, b) { // 依赖必须一开始就写好

a.doSomething()

// 此处略去 100 行

b.doSomething()

...

})

```

对象模拟命名空间

Javascript模块化编程（二）：AMD规范

Javascript模块化编程（一）：模块的写法

SeaJS与RequireJS最大的区别

让我们再聊聊浏览器资源加载优化

SeaJS 和 RequireJS 的异同