从 jQuery 到模块化：一次前端工程意识的转变
目录
背景
在较早阶段的前端开发中，常见技术栈以 jQuery + 传统页面结构 为主。
这种模式在页面数量有限、业务逻辑简单时，具备实现成本低、交付速度快的优势。
但随着功能逐步增多、页面之间产生联动，代码结构问题开始显现，对可维护性提出了更高要求。
传统写法暴露的问题
1. 全局作用域污染
var list = [];
function init() {}
function render() {}
常见问题包括：
- 变量与函数暴露在全局作用域
- 多页面脚本容易互相覆盖
- 问题定位与调试成本逐渐升高
2. 文件职责混乱
在缺乏结构约束的情况下：
- 单个 JS 文件体积不断膨胀
- DOM 操作、业务逻辑、接口请求混杂
- 修改局部逻辑时容易产生连锁影响
3. 代码复用能力弱
相似功能在不同页面中往往通过复制实现：
- 复制后再做细微修改
- 长期来看难以统一维护
- Bug 修复成本被成倍放大
引入模块化思路
为缓解上述问题，开始尝试在不依赖复杂工具链的前提下，引入基础的模块化设计思想。
1. 按职责拆分代码结构
js/
├── api.js
├── render.js
├── event.js
└── main.js
通过人为约定实现基础分层：
- 接口请求集中管理
- 渲染逻辑独立拆分
- 事件绑定避免分散在各处
即使不依赖构建工具，也能显著提升代码可读性。
2. 使用 IIFE 隔离作用域
(function () {
var state = {};
function init() {}
window.pageInit = init;
})();
这种方式在早期用于：
- 控制变量可见范围
- 避免无意污染全局对象
- 明确对外暴露的接口
虽然实现方式相对原始，但有助于建立作用域管理意识。
3. 明确入口文件概念
逐步形成以下约定：
- 每个页面只有一个入口文件
- 入口文件负责组织模块调用
- 具体业务逻辑分散在独立模块中
这一做法为后续引入构建工具与框架奠定了基础。
工程意识带来的变化
模块化并未立即带来直观的性能提升，但在工程层面产生了明显收益：
- 功能扩展更容易
- 代码修改风险降低
- 项目整体结构更加清晰
更重要的是，开发视角从“完成页面”转向“维护一个可长期演进的系统”。
总结
这次转变并非技术升级，而是工程认知的变化。
从代码拆分、作用域控制到入口管理，这些实践在当时并不复杂，却成为后续：
- 框架化开发
- 组件设计
- 工程化体系建设
的重要起点。
前端工程能力的成长，往往正是从这些看似朴素的调整开始的。