更比如 ，一个页面 分好多个功能， 这时候你要是都写在一个js 中 会越来越大，
而你把他分成不同的模块，
比如评论是一块
分页又是一块，
已经上线，或你不做了，后期别人拉手，或你接手别人的项目， 这时候来个需求让你把分页去掉，或修改 你可以清楚的找到对应模块文件 进行修改 或去掉
模块是自定义的，
组件，更想当于一个通用的东西，有的分功能组件，有的分业务组件
大图切换，这种就是单纯的一个效果展示，只要调用就ok
一个分页，也是只单纯的调用，
组件更是一个多处都可以使用 ，不需要再单独开发的
模块化的优缺点：a>优点：
可维护性
1.灵活架构，焦点分离
2.方便模块间组合、分解
3.方便单个模块功能调试、升级
4.多人协作互不干扰
可测试性
1.可分单元测试
b>缺点：
性能损耗
1.系统分层，调用链会很长
2.模块间通信,模块间发送消息会很耗性能
3)最近的项目中也有用到模块化，
使用的是seajs,但是当引用到jquery,jquery easyui/或者jquery
UI组件时,有可能会用到很多jquery插件，那这样要是实现一个很复杂的交互时，模块间的依赖会很多，使用define（）方法引入模块会很多，不知
有么有什么好的方法
软件产品可以被看作是由一系列具有特定功能的组件组成，作为一个完整的系统也可以被分解成一系列功能模块，这些模块之间的相互作用就形成了系统的所有功能。所谓模块是指可组成系统的、具有某种确定独立功能的半自律性的子系统，可以通过标准的界面和其他同样的子系统按照一定的规则相互联系而构成的更加复杂的系统。每个模块的研发和改进都独立于其他模块的研发和改进，每个模块所特有的信息处理过程都被包含在模块的内部，如同一个“黑箱”，但是有一个或数个通用的标准界面与系统或其他模块相互连接。
在软件的模块化开发过程中，把一个源代码的结构分割成一个元系统和一系列的模块。
元系统指的是一个能够保持系统运转的最小的系统。
模块是一个较大系统的独特的部件，它能够由设计者独立设计出来，同时又可以作为一个整体在系统中运转。
把一个大系统切割成互相独立的不同的小系统，可以使一些并不是经常见面的开发者减少必要的交流次数。
另外，一个旧版本的模块可以被新版的模块所替换，同时却又不影响整个系统的运转。
这样，在新模块中所增加的功能就可以及时在现存的系统中体现出来，同时也不需要更改系统中的其他模块。
高度模块化的源代码结构给软件开发者和使用者均带来了极大的好处。
开发者可以对具有某种特定功能的模块进行独立开发而不需要花时间去协调与其他模块之间的关系。
并且模块化开发不仅允许模块之间的水平开发，而且可以通过对类似模块之间的创新和竞争(开发新的模块或者对原有的模块进行改进)充分改善系统的功能。
另外，作为最终的用户来说，在安装系统的时候可以就个人的需求与偏好选择适合自己的模块。
模块化是复杂系统的一个共同特征，模块化的代码结构是由松散的组件构成的，是对一个系统完全意义上的分割，而不像完全集成的代码，各个组件之间存在很强的依赖关系，并不是完全通过界面来交换信息。
总结：
第一， 把一个系统分解成各个不同的子模块，不同的开发者专注于对其中某一模块的开发，一方面实现了劳动的分工，另一方面也提高了自由软件开发的效率。基于模块化的性质，每个模块在开发出来以后都可以通过一个被称作是内核的原系统进行信息交流，发挥整个模块的功能，同时也并不会影响其他模块功能的发挥。而且在各个不同的模块整合在一起后，由于外部性的存在，会使整个系统增加的功能要超过该模块本身的功能。在此过程中实现了价值的分割与整合。
第二， 对于开发者而言，基于模块化的自由软件开发具有更大的吸引力，其在参与开发过程中可以得到更高的期望收益。
第三， 在非模块化的软件开发过程中，存在着严重的“搭便车”现象，当一个开发者选择参与开发，其余的开发者就会选择“搭便车”，最终会导致软件的供给不足；在基于模块化的开发过程中，所有的开发者都更倾向于参与开发不同的模块，从而实现整个系统的开发。
MIS软件开发中的组件模式开发比较复杂，主要的阻力不在代码的实现过程中，因为这个工作通常只应该占据软件开发工作量的30％，而对业务需求的深度剖析、业务子系统的划分和业务组件的规划会占据约40-50％的工作量。
这些工作体现在设计阶段主要是对业务的广度、深度分析，把业务领域的对象元素进行细化，将业务操作划分为原子性功能，以此为基础构成业务组件，进而形成模块和子系统，同时业务操作之间的约束则需要逻辑化（代码系统可识别的逻辑）；在此过程中，原系统也就形成了，它便是在业务领域中必须的组件、模块和子系统的集合；外延的组件在原系统上通过组合或热差拔即能够满足不同规模、深度、特性的业务模式运转。
