摘要：前兩天有朋友拿了這樣一段代碼來問我，我想把一段代碼寫成模塊化的樣子，你幫我看看是不是這樣的。的一個好處在與依賴前置，所有被使用到的模塊都會被提前加載好，從而加快運行速度。

前兩天有朋友拿了這樣一段代碼來問我，“我想把一段代碼寫成模塊化的樣子，你幫我看看是不是這樣的。”，代碼大概是這樣的：

(function(global) {
    var myModules = {
        name: "xxx",
        location: "chengdu",
        intro: function() {
                return `his name is ${myModules.name} and come from ${myModules.location}`
            },
        }
        // some other code...
        if(typeof module === "undefined")
            global.myModules = myModules
        else
            module.exports = myModules
})(this)

“可是我這段代碼在全局還是能myModules這個屬性啊？”
我一臉懵，還有這種操作，為什么你的立即執行函數要把this傳進去呢，這樣不久將里面的內容掛在到了window上了嗎，他似懂非懂，我只好說，你可能需要回頭去看看AMD和CMD規范了，我大概能夠理解這其中的緣由，畢竟這段時間前端發展的速度飛快，加上webpack也不需要自己配，包括vue，react，angular在內的框架類庫都有一鍵生成項目的工具，從而只需要使用下import * from "*"和export default {}，而這種便利會讓新人不再需要去學習基本原理就能快速上手，畢竟現在都ES2018了呀。

對象形式

最開始的時候，為了減少全局變量，一般會使用一個對象的方式來對所有的變量方法進行一個包裝：

    var obj = {
        a: 1,
        b: 2,
        sum: function(val) {
           return obj.a + obj.b + val
        },
        rest: function(val) {
           return val - obj.a - obj.b
        }
   }

以上代碼似乎解決了全局變量的問題，但是其中的a和b兩個變量還是可能被修改，其中包含的進化有限。

立即執行函數

回過頭來看文章開頭的代碼，姑且不論以上代碼的錯誤之處，稍作修改，這算是最初的一種關于JavaScript模塊化的開端，立即執行函數：

var add = (function(){
    var a = 1
    var b = 2
    function sum(count){
        return a + b + count
    }
    function rest(count){
        return count - a - b
    }
    return {
        rest: rest,
        sum: sum
    }
})()

這就是一種最簡單的模塊化的方式，利用閉包的特性，設置了兩個只有在被暴露出來的add和reduce方法內部才能訪問到的兩個變量，從而保證了函數的局部變量不可被修改的特性，這次的進化用到了閉包，從而實現了部分有效的目的。

放大模式

其實開頭的代碼更符合另外一種叫做放大模式的方法，不過一般來說不會講window作為放大模式中被傳入的對象

    var globalObject = {
      fn1: function() {
        // todo...
      },
      // ...
    }
    globalObject = (function(obj) {
      var name = "xxx"
      var location = "xxx"
      function sum(val) { /* todo... */ }
      function rest(val) { /* todo... */ }
      obj.sum = sum
      obj.rest = rest
      return obj
    })(globalObject)

以這種形式來寫，可以讓全局變量盡量的減少，同時讓一個立即執行函數中的代碼盡量做到精簡。

但是這種放大模式也存在著問題，比如當globalObject內容足夠多的時候，很可能會造成命名重復的情況，并且以上所有的方式都不可以減少script標簽的數量，所以，我們還是會被模塊的加載順序，命名空間沖突等問題所困擾，這時候，我們應該跨入新時代了。

CMD規范

CMD規范來自阿里的框架seajs，當初確實有挺多人使用，不過現階段已經不再維護了，我也不會，就暫時不說了，只列出來。

commonjs

同時，從2009年開始，JavaScript就不再只是一種瀏覽器端的腳本語言了，nodejs的出現讓使用js開發服務端變成了可能，隨著node出現的東西還有一個叫做commonjs的規范，在這個規范中，每個文件都是一個模塊，有著自己的作用域。

譬如，如下代碼

    // 文件a.js
    var a = 1
    // 文件b.js
    console.log(a) // a is not defined.

在這樣的特性下，a.js和b.js都有著自己獨有的作用域，要在b中對a進行訪問，就需要一種加載機制，一般來說，有兩種方法能夠做到：

方法1

    // 文件a.js
    global.a = 1
    // 文件b.js
    console.log(a) // 1

這種方法掛載在global上，當然是不可取的。

方法2

    // 文件a.js
    exports.a = 1
    // 文件b.js
    var moduleA = require("./a")
    console.log(moduleA.a)

AMD規范

requirejs的出現讓script標簽的減少變成了可能，在requirejs的時代，我們一般會使用jQuery，underscore這類的類庫，如果按照往常的樣子我們會將代碼寫成下面這副模樣：

這樣的代碼乍一看似乎沒什么問題，但是當一個項目的代碼量上了一個量級，一切就變得不是這么回事兒了，你會被困在加載順序，加載時間的問題上，這也就是requirejs能夠出現的原因了。

在requirejs中，你可以如此改寫以上代碼：

    // `index.js`
   require(["js/lib/jquery.min", "js/lib/underscore.min", "js/app/app"], function($, _, app) {  /*  todo...  */  })
    // `app.js`
   define(["js/lib/jquery.min", "js/lib/underscore.min"], function($, _) {  /*  todo...  */  })

這里當然顯得更加優雅了，在requirejs的推廣過程中，AMD規范也就應運而生了，那么，requirejs或者說AMD規范到底解決了什么樣的問題呢，主要有幾點：

AMD是“異步模塊定義”的縮寫，也就是說，其中內容是異步加載的，從而讓頁面不被js的加載阻塞，最大程度上的避免了頁面假死等情況的產生。

AMD的一個好處在與依賴前置，所有被使用到的模塊都會被提前加載好，從而加快運行速度。

那么，commonjs規范和AMD規范有什么區別呢

運行環境不同，commonjs規范只能運行在node端，而AMD規范則被用到瀏覽器端
由于運行環境的不同，二者的加載機制也不同，commonjs中的require是同步執行的，而AMD中則是異步的。

ES2015模塊化

在ES2015中，可以使用export, export default, import import * as 等操作符來作模塊化的功能，但是這個規范現在尚未被任何瀏覽器加入規范中，我目前的Chrome版本為63.0.3239.132，也無法原生支持，不過現階段我們幾乎都用上了這個規范，這一切都只能歸功于babel,webpack和rollup等新工具的出現，既然如此，那就擁抱未來吧，不過有一點，需要在了解原理的前提下，不然，倘若有一天，真的需要我們來封裝一個小小的模塊的時候，沒有了那些工具，我們該從何下手呢。