开启掘金成长之旅！这是我参与「掘金日新计划 · 12 月更文挑战」的第1天，点击查看活动详情
大家好，我是初心，本篇是我坚持原创文章的第01期文章,如有错误，欢迎指正👏🏻
什么是模块化
模块化是将复杂的程序按照一定的规则封装成不同文件，最后组合起来，模块化的内部需要私有化，只像外暴露一些方法使用或于其他模块进行交互。
模块化的优势
-
模块化的内部需要私有化
-
避免命名空间冲突，减少命名污染
-
代码分类更合理化，实现按需加载
-
提高了代码的复用性和维护性
青铜时代，文件划分
我很荣幸经历过青铜时代，那个时候还是jquery的统治，其实那个时候还没有模块化的概念，随着业务的不断扩大，能处理的就是只能通过文件的形式进行划分~
不同页面使用不同的xxx.html文件，分别引入对应xxx.css和xxx.js文件
文件划分的缺陷
- 容易引起全局命名空间冲突
-
- 比如 common.js 和 about.js都声明了 format 函数，重复变量等问题
- 代码复用性差
-
-
各模块页面使用都需要重复引入需要用到的js文件和css文件 例如jqeury
-
往往那个时候的开发，像现在的components，只能通过js进行维护~
-
黄金时代，全局namespace模式
全局namespace模式，通过对象封装模块，在深受环境变量污染全局的困扰之后，团队都开始约束起来，使用对象的形式将逻辑封装起来。
全局namespace的缺陷
- 外部能够修改模块内部数据
-
-
外部可以绕开aboutModule.getName方法
-
通过aboutModule.name进行操作，这违背了模块化的设计初衷
-
我们该如何解决这个问题？我们可以通过闭包的概念来解决外部修改内部数据的问题
铂金时代,IIFE模式
IIFE(ImmediateIy-invoked function expression)模式是通过自执行函数创建闭包,将逻辑进行封装
值得一提的是立即执行函数是存在作用域的，也就是说name不是挂载到window上，这样我们就可以完美的解决外部修改问题，但是这也带来了新的问题
IIFE的缺陷
- 无法解决模块间相互依赖问题
那么我们又应该怎么去解决模块之间的相互依赖问题呢？我们可以使用外部自定义传参作为依赖
传参虽然能解决问题，但是也有自己的缺陷
-
多依赖传入时，增加阅读成本
-
无法支持大规模的模块化开发，多依赖下，容易混乱~
总结
前端模块化是一个演化的过程，孕育出多个模块化方案，后续还将推出 CommonJS模块化、UMD模块化、ES模块化等等~
