一，为什么要进行模块化开发（传统开发的弊端）
1，命名冲突
在实际工作中，相信大家都遇见这样的问题，我自己测试好的代码和大家合并后怎么起冲突了？
明明项目需要引入的包都引进来了怎么还报缺少包？这些问题总结起来就是命名空间冲突及文件依赖加载顺序问题。举个简单的列子来解释一下命名空间冲突问题，看下面这段代码：
test html
<!DOCTYPE html> <html> <head lang="en"> <meta charset="UTF-8"> <title></title> <script src="js/module1.js"></script> <script src="js/module2.js"></script> </head> <body> </body> </html> <script> var module=function(){ console.log('I am module3'); }; module(); </script>
module1.js
/**
* Created by user on 2016/5/14.
*/
var module=function(){
cosonle.log('I am module1.js');
}
module2.js
/**
* Created by user on 2016/5/14.
*/
var module=function(){
console.log("I am module2.js");
}
当运行test.html时结果输出：
显然是因为前两个JS文件里的函数名与html里面的一致而导致冲突，所以只会执行最后一个module()函数，在团队合作中你不会知道自己写的函数或变量等是否会与别人起冲突，这时候模块化开发就能解决这些问题。
2，文件依赖
开发最基本的原则就是不要重复，当项目中有多处地方运用同一个功能时，我们就该想办法把它抽离出来做成util，当需要时直接调用它即可，但是如果你之后的代码依赖于util.js而你又忘了调用或者调用顺序出错，代码变报各种错误，举个最简单的列子，大家都知道Bootstrap依赖jquery,每次引入时都需要jquery放在Bootstrap前面，一两个类似于这样的依赖你或许还记得，但如果在庞大的项目中有许多这样的依赖关系，你还能清晰的记得吗？当项目越来越复杂，众多文件之间的依赖经常会让人抓狂。下面这些问题，我相信每天都在真实地发生着。
1.通用组更新了前端基础类库，却很难推动全站升级。
2.业务组想用某个新的通用组件，但发现无法简单通过几行代码搞定。
3.一个老产品要上新功能，最后评估只能基于老的类库继续开发。
4.公司整合业务，某两个产品线要合并。结果发现前端代码冲突。
5.……
以上很多问题都是因为文件依赖没有很好的管理起来。在前端页面里，大部分脚本的依赖目前依旧是通过人肉的方式保证。当团队比较小时，这不会有什么问题。当团队越来越大，公司业务越来越复杂后，依赖问题如果不解决，就会成为大问题。
二，什么是模块化开发
模块化开发使代码耦合度降低，模块化的意义在于最大化的设计重用，以最少的模块、零部件，更快速的满足更多的个性化需求。因为有了模块，我们就可以更方便地使用别人的代码，想要什么功能，就加载什么模块。但是也不能随便写哦。
三，什么是模块化？
Node自带的规范 commonjs规范
Commonjs是node的规范，运行在服务端，不是浏览器端，如果使用在了浏览器端，需要使用对该文件进行打包翻译（借鉴工具browserify,webpack,gulp等）
书写模块的时候对外暴露接口module.exports={},exports.xxx=
引入模块 require（路径）
commonjs暴露的本质是一个叫exports的对象
Module.export={}和exports.xxx=
二者暴露的本质是一样的，都是exports的对象
二者暴露的本质是一样的，都是暴露一个exports对象
Commonjs是node的规范，但他是同步加载的，同步加载在浏览器端是一个坑，只要一个环节卡住了，后面的就没法执行。所以不建议使用，如果非要使用就需要编辑打包。
Web端
每个js都是一个模块，每个模块都必须有一个暴露接口，每个js文件有一个全局的方法叫require()用于引入模块。