谈谈个人对插件及框架设计的一些心得

最近没有怎么更新博客，因为坑爹的期末考试到了。但是在复习空闲之余，我还是有写一些小作品聊以自慰的。

今天在这里谈一谈自己的JS插件及框架设计的一点心得。

文章背景

前两个月我写了一个HTML5的游戏框架。个人感觉其实还不算太烂，不过一些架构的设计自己纠结了好久，感觉还是不怎么合理。而且项目用的是sea.js的包管理，踩了一下sea.js的坑（不支持动态依赖），所以打算考完试对框架的构架进行一些新的调整，也希望能有志同道合的朋友一起合作，共同促进学习。

前几天设计了一个前端CRUD的插件，简单点说就是实现了客户端实现增删查改的单页面插件（对后台暴露了AJAX接口同步数据）。起初认为借助Backbone这类MVC框架会没啥难度，结果愣是拖到要开始复习期末考试了都没有完成。主要的原因我将在下面阐述（也就是自己的一些心得）。

心得

其实个人觉得，学习一下设计模式十分重要，它起码能够让你有统筹全局的一些选择，同时软件工程、软件体系的那一套理论肯定也有它存在的价值。但是一味地照本宣科就不是一个好的程序员了。比如说我这次设计的CRUD的插件。

因为这个插件是自己忽然心血来潮想做的。所以说，如果按软件工程那一套，那么“实现增删查改”功能就是一个最基本的“项目需求”了。然后按需求分析，概要设计等等那一个套路，我很快就把架构搭建起来了。可是后来，把这个插件完成后发现，使用插件实现的CRUD，相比于不要插件实现的CRUD，只是代码量减少了。一些繁琐且复杂的功能实现（视图与数据的绑定）仍然需要使用者去管理。于是乎，我很苦恼，所有的工作并没有收到理想中的回报。

导致收效甚微的原因是什么呢？针对这个插件，我的总结如下：1.封装程度太低——对Backbone的一些基础的API只是简单地进行了简化，却没有实质的功能封装。2.没有对症下药——插件和框架的核心在于减少开发时间，提高开发效率，可如果把开发插件和开发框架当作一个“项目开发”来做，生搬硬套软件工程那一套理论，肯定是行不通的。

所以，我总结了一下插件和框架的开发流程：

1.先设计暴露的API（只有简洁高效的API，才能体现你的插件和框架的价值所在）

2.针对设计的API进行模块化分割（这里注意，模块化分割不等于JS里的模块化开发，也许你不需要用到require.js或sea.js这类库，但是你需要的是松耦合的体系结构，这样有助于后期的维护）

3.然后再对具体的各个分割模块进行具体化的设计

以上纯属一些个人见解，如果您有异议，欢迎提出，谢谢支持！