我们要进行模块化开发呢？
模块化开发的好处主要有这么几点：
1.使用模块化开发能解决文件之间的依赖关系。
当你引入很多个JS文件的时候，很有可能会不清楚这些JS文件之间的依赖关系，从而导致加载顺序出错。使用模块化开发之后就能避免这个问题。
2.使用模块化开发可以避免命名的冲突。
JS本身是没有命名空间的，为了减少命名冲突，经常使用对象或者闭包来减少命名冲突。对象只能减少命名冲突的概率，闭包的过多使用会造成内存泄漏。模块化开发之后，在模块内任何形式的命名都不会和其他模块的命名产生冲突，有效的解决了命名冲突的问题。
3.使用模块化开发能进行代码的复用。
当我们想要实现某个功能的时候，如果某个模块正好有这个功能，我们就可以直接引用该模块，不必再写多余的代码，这样可以提高代码整体的效率，减少重复冗余的代码。
组件化开发和模块化开发概念辨析
网上有许多讲组件化开发、模块化开发的文章，但大家一般都是将这两个概念混为一谈的，并没有加以区分。而且实际上许多人对于组件、模块的区别也不甚明了，甚至于许多博客文章专门解说这几个概念都有些谬误。
想分清这两个概念我觉得结合一下软件的渐进式开发场景更容易理解。但是下面的篇幅会比较长，所以我先说结论，不耐烦的同学可以先看：
概念区别
说明
- 组件：最初的目的是代码重用，功能相对单一或者独立。在整个系统的代码层次上位于最底层，被其他代码所依赖，所以说组件化是纵向分层。
- 模块：最初的目的是将同一类型的代码整合在一起，所以模块的功能相对复杂，但都同属于一个业务。不同模块之间也会存在依赖关系，但大部分都是业务性的互相跳转，从地位上来说它们都是平级的。
因为从代码组织层面上来区分，组件化开发是纵向分层，模块化开发是横向分块，所以模块化并没有要求一定组件化。也就是说你可以只做模块化开发，而不做组件化开发。那这样的结果是什么样的呢？就是说你的代码完全不考虑代码重用，只是把相同业务的代码做内聚整合，不同模块之间还是存在大量的重复代码。这样的成果也算是做到了模块化，只不过我们一般不会这样而已。
和组件模块近似的一对概念是库和框架。库的概念偏近于代码的堆集，是分层的概念，所以对应组件化。框架是结构化的代码，所以应用于模块化。框架是骨，模块化是肉。
比如，ReactiveCocoa是库，只是提供了响应式编码能力，而基于此的MVVM具体实现成果才叫框架，因为框架本身就有架构思想在里面。
举例
下面我们举例来说明。
组件化就比如公共的alert框，最初在许多页面都有使用，后面提取出一份相同的代码，其实就是基于代码复用的目的。
模块化就比如一个资讯功能，它本身只在这一个地方使用，没有复用的需求，但系统启动的时候要初始化它的数据，首页显示的时候要展示它的数据，显示红点的时候要拉取它的未读数。这样一来应用中就有很多地方涉及到它的代码。如果我们将它看做一个整体，那么资讯模块和主应用的耦合性就非常高了。所以我们也要把它封装成模块，把相关的代码放到独立的单元文件里，并提供公共方法，这就是高内聚的要求。
渐进式开发过程
当然这几个概念在服务端开发和客户端开发领域有些微差别，我下面的例子就从移动端开发的角度上进行辨析。
首先我们定义一个虚拟的产品——一款知识类应用，包含咨询、问答、学院、直播等功能。
接下来我们逐步拆分这个产品。
如果开发时没有考虑任何组件化模块化开发，那么此应用的所有功能都是堆积在一起的，总结起来就是高耦合，低内聚，无重用。
1.组件
那么代码重构的第一步是什么呢？
将重复的代码合并成为一份，也就是重用。
我们来看组件化开发的定义，它的着重点就是重用，那这一步最后的结果就是提炼出一个个组件给不同的功能使用。
这里我们可以看一下依赖关系，是具体功能依赖提炼出来的组件，组件本身之间可能也有依赖关系，但一般不多。所以我们总结组件化开发的原则就是高重用，低依赖。当然这只是相对而言。
基于这样的认识，我们甚至于可以把资讯、问答、学院、直播等功能封装成组件，只不过这些组件比较大，依赖可能多些，不过本质上没有多少区别，而且实际上网上许多文章说所的模块化开发其实就是这种组件化的“模块”。
2.模块
下面再说模块，按照模块的定义，它是以关注点进行划分的，关注点说到底就是功能，也就是说根据我们上面的例子，资讯、问答、学院、直播可以分成不同的模块。
我们最开始定义这个虚拟产品的时候说，它有三个特点——高耦合、低内聚、无重用。而第一点组件化开发主要是解决了重用问题，提升了部分内聚，而耦合问题则没有涉及。
所以说我们上面可以将这个产品在逻辑上划分为资讯、问答、学院、直播四个模块，但在代码层面上它们却不是四个模块，因为它们的代码都是混杂在一起的。比如产品首页，可能推荐了部分资讯、显示了热门问答、推送了目前的直播，而这些功能的代码则是写在一起的；再比如程序启动的时候，这四个模块都需要初始化一些数据，而初始化数据的代码也是写在一起的；再比如程序需要显示未读消息数，而这几个模块都有自己的未读消息数逻辑。
如果未进行模块化开发的拆分，那么很多时候不同模块的同一类的代码都是直接写在一起的，比如系统启动的时候，我们会在启动方法里直接写多个模块的初始化代码。
而模块化开发就是为了解决这一问题，即提高内聚，将分属同一模块代码放到一起；降低耦合，将不同模块间的耦合程度弱化。
高内聚是目标，但是现状是有许多地方会用到多个模块，比如启动的时候会调用四个模块，首页会展示三个模块的界面。如果要高内聚，那么必然需要这些模块为不同的场景提供相同的方法，这就是说所有模块要实现同一套多个接口。这样主应用和模块之间的重耦合就变成了主应用和接口耦合，接口和模块耦合这样的松耦合。
但这样的简单模块只是轻模块，统一接口较少。而统一定义的接口越多，模块和统一接口的耦合就越高，也便是重模块。
而我们一般讲的路由问题其实只是解决模块间耦合的问题，并不是模块化开发的必然需求，更多时候是基于产品上的动态化要求，只不过我们一般都会在这个时间考虑这一事情而已，就像我们不会只做模块化开发同时不做组件化开发一样。
讲到这里，模块和组件的区别就已经很明显了。
