对模块化编程的理解

问题的出现：

1、冲突

      在我们编程的时候，随着项目越来越庞大，越来越复杂，参与的人员越来越多的时候，对于函数的命名就非常容易产生冲突。

      比如领导交给我们一个任务，去开发一个组件库，可以拿来公用的库类型。那么A同事可能就去写一个外部的common.js,里面构造一些函数，如：

function a(){}
function b(){}
function c(){}

写完之后，就可以交给别的同事去用了。拿到后调用

<script src="common.js"></script>
<script>
    a();
    b();
</script>
但是当项目越来越复杂的时候，别的同事又加入进来，有可能新同事也写了一个函数
function a(){}
的函数，就会和之前的函数发生冲突出错。

一般情况下我们可以给每个人构建的函数加命名空间，比如：

var show = {};
show.a = function () {};
show.b = function () {}
     另一个同事构建的时候就加不同的命名空间。但是其弊端也是显而易见的，首先是命名空间有可能会很长，对于开发和提高性能都很不利；再者虽然产生冲突的可能性只是被降低了，理论上还是存在冲突的可能，谁又能百分之百保证这么多命名空间当中没有一两个巧合呢？

2、依赖

    我们开发网站的时候不可能把所有的东西都写到一起吧，最好是进行分离开发，一层层的往下开发。比如说公用的部分，以及公用的组件等，不同类型的分出一个层次来。那么一个页面中就会出现引用很多个js文件的情况：

<script src="a.js"></script>
<script src="s.js"></script>
<script src="d.js"></script>
<script src="g.js"></script>
不同的js文件负责不同的功能等等，如果各个js文件没有相互依赖的关系的话，那么它们谁放前面后面都无所谓，但是如果有以下情况则不同了：

我写了一个日历组件

show.js
同事拿过去后首先引入

<script src="show.js"></script>
调用函数显示日历

show();
但实际上发现没有显示日历？？？

搞了好久才你才想起没有告诉他这个日历组件依赖于另一个b.js文件，这样才行：

<script src="b.js"></script>
<script src="show.js"></script>

这还是不是最抓狂的，最要命的是后期的维护和扩展，比如产品要求给日历增加一个查阴历的功能,那你就又去写一个c.js的文件，然后告诉你的同事，我这多了一个c.js文件需要依赖，那同事只能对他写的每一个页面都加一个c.js的引用才能完成功能的升级：

<script src="b.js"></script>
<script src="c.js"></script>
<script src="show.js"></script>

过了一段时间，产品又要求砍掉一些功能，那组件又不依赖b.js了，你又去告诉你的同事，那他又得把每个页面的b.js删掉，结果一看效果，出问题了，并不是简简单单把b.js已删了之的问题了，因为页面中还有其它的js文件依赖b.js，这样又必须得把b.js拿回来。这样折腾来折腾去，严重影响效率啊。

所以说前期的地基一定要打好，后期才不会不停地修改。

解决办法：模块化开发

形象来说，把一个大的项目比作一架飞机，飞机都是由很多块相对较小的部件构成，而这些部件又又很多的组件构成，就这样一直细分下去，直到最单一的标准件，它只实现一个单一的功能，这就是js当中的一个模块，整个项目都是由模块拼凑成组件，再由组件拼凑起来的。js中每一个js文件都可以看做是一个模块。

工具：sea.js或其它模块化开发工具。

用法：见sea.js官网API教程 http://seajs.org/docs/#docs