2.5.1 模块化简介

最早前端JavaScript代码量不大，统一放在一个文件内，如下面一段代码：

    var name = 'weixin'，
        age = 12;
    function getName() {
        // 实现代码
    }
    function getAge() {
        // 实现代码
    }

后来前端代码越来越多，为了便于管理和工作拆分，我们不得不把代码拆分为多个文件，这时将上述代码封装到user.js文件中，需要用时引入页面（或打包到一个文件）就行。初期团队成员少，一切都运行正常，直到团队越来越大，开始有人抱怨：我想定义一个name变量但user.js中已经存在，我不得不定义为myName；为什么我在自己代码中定了getAge方法就导致别人代码出问题了呢？通过这种文件拆分的工作我们只是对代码做了物理上的分离，能初步实现多人开发和简单的代码管理，但并没有真正做到作用域的隔离，由于不知道其他文件内已存在的变量名，甚至让全局冲突问题变得更容易、更严重。

再后来为了避免这种全局冲突，大家决定参考Java的方式，引入命名空间和闭包来解决变量冲突问题。于是user.js里的代码变成了如下这样：

    ( function() {
      myProject = myProject || {}; // 定义全局命名空间
      myProject.user = {};
      myProject.user.name = 'weixin';
      var age = 12; // 闭包内变量，外部不能访问
      myProjecct.user.getName = function() {
        // 实现代码
      }
      myProject.user.getAge = function() {
        // 实现代码
      }
    } )();

这样别的同事可以通过myProject.user获取name，调用getName和getAge方法，通过命名空间，的确能缓解大部分冲突，但是为此我们不得不记住很长一串命名空间，同时当我使用user这个空间后，别人就不能使用，这也不能完美地解决问题。同时更可怕的是如果user.js依赖另外一个utils.js，别的同事必须通过阅读user.js源码搞懂这层依赖关系，按顺序引入utils.js、user.js，直接引入user.js将会导致他代码出错，如果utils还依赖别的资源他还得必须搞懂相关的所有依赖，而他仅仅是想调用我的getName方法，这对调用的同事来说无疑是个噩梦。这时我们需要一种新的组织方式，于是诞生了模块化：

□模块是一段JavaScript代码，具有统一的基本书写格式。

□模块之间通过基本交互规则，能彼此引用，协同工作。

目前模块化的规范不统一，大致可分为CommonJS和ES6两种规范，大家有兴趣可以参考网上相关资料，小程序模块化机制比较接近CommonJS规范，无论哪种规范，学习起来都十分简单。