模块化开发简述

模块化开发简述

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

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等工具管理，各种需求有不同的人负责处理。模块化对团队开发会起到协同作用，公共模块除了避免重复造轮子的痛苦外，也避免了逻辑混淆。

好了，大概就上面这些，我现阶段的水平限制了我的眼界和理解，后面有不一样的看法时再修正补充吧。