什么是模块化？模块化开发的好处

模块化开发简述

什么是模块化：指文件的组织、管理、使用的方式。即把一个大的文件拆分红几个小的文件，他们之间相互引用、依赖。

都说模块化开发为前端发展带来了巨大的进步，然而不熟悉的人看着也是两眼一懵，那其实这究竟是什么？好处在哪？我来讲说本身的看法吧。

1. 模块化和传统开发的区别
实话讲，其实在我看来，二者的开发是同样的，除了方式不同，达到的效果并没两样。
看着扯淡，但实际能够想一下，现流行的模块化开发主要有两种方式：

依赖加载。这种方式是最普遍的，像requirejs，sea.js等，除了 编写规范 不同，实际都是经过相关require api把模块chunk文件拿回来，当加载完成以后再运行逻辑代码。
依赖打包。经典表明就是webpack，其实就是写代码的时候分开模块，但打包的时候按依赖关系找到各个模块，最后打包到同一个文件上，并给每一个chunk标识id，运行逻辑代码时将模块引用指向该id，从而实现模块化。

而传统的开发方式是在页面上经过脚本标签引入，等全部脚本资源加载完成后再运行逻辑代码。这样一对比，是否是发现效果实际上是同样的，我把不一样脚本分开写，也是能够作到相似模块化的效果？

那么重点来了，模块化的优点在哪？

别急着回答，先思考一下，而后带着你的想法继续看下去。

 

先回想一下，传统开发的痛点在哪。

首先，如上所述，传统的开发方式须要等待全部脚本资源加载完成。这个问题最大的弊端就是页面要等待，由于资源加载是同步的。你的页面会出现短暂的空白期，引入的脚本越多，时间越长，若是某一脚本加载失败，也可能直接挂掉。

模块化的代码则能够很好的处理这个问题。除了模块化支持的脚本必须加载进来之外，其余脚本均可以异步请求，不须要页面等待，能够加速渲染出页面。requirejs，sea.js等也会作好加载重试和模块缓存的处理，确保全部模块运行良好。

全部资源加载的时间不会由于模块化而加速，可是模块化能加速渲染，这是优点1。

固然webpack是特例，它和nodejs同样用 commonjs 规范，为了达到目的，所有脚本打包到一块儿再运行，看着和上面观点相悖，不过如今带宽足够，相对而言仍是足够快的，也能减小多脚本加载出错的风险。

接着上面的观点讲，抛开带宽速度来说，既然网速够快，那模块化还有什么？不妨回想一下，传统开发时最烦的是什么？无非3点

命名空间。早期为了不命名冲突，大众作法是用一个变量做为命名空间作隔离，长期开发过程当中没人能记住这个变量是否冲突，它的命名规范是什么，治标不治本。
而模块化的出现消除了这点。一个模块内的命名随本身起，和外界不会冲突，对外的永远是你exports出来的内容。若是模块内出现命名冲突，这说明了你的命名水平过低…..

好吧，是模块颗粒不够小，还能够继续分割出模块~

代码重用。其实这点和传统开发并没有两样，都是把可复用代码抽取出function（再通用点会抽象出类，也就是构造函数），独立文件。但模块化的好处一样能够规避命名空间的问题，没必要设置变量污染到全局。通常模块化都有缓存机制，在二次调用时无需再解析，直接获取到缓存模块内容。

按传统开发来处理，忽略以上问题，但也耐不住文件太多，引入和管理麻烦。除了amd规范须要依赖前置，咱们还能够用cmd规范来写模块依赖，想用什么require什么，不用再一个个引入js，看着也舒服。并且如今的模块化工具基本都实现了多规范混搭，想怎么写就怎么写，只要注意组内规范就行。

 

此外就是 管理问题。

小公司或我的开发，模块化能让本身思路更为清晰，下降代码耦合，优秀的模块能带来代码质量质的飞跃，标准的模块应该是 “分工明细，职责单一，不牵扯需求逻辑” ，它就应该是个万能的螺丝，不须要能够修改，哪里须要用哪里。

而中型企业和大团队则很常常会遇到团队协做开发，除了会用svn/git等工具管理，各类需求有不一样的人负责处理。模块化对团队开发会起到协同做用，公共模块除了避免重复造轮子的痛苦外，也避免了逻辑混淆。