1.事出必有因
最近在看老项目的代码，一个富客户端的js代码，几千行的代码，全是function（）{} var...的垂直布局，真的是要感动的哭了。
一开始都是这样，想实现什么功能，不管三七二十一，function走起，最终堆起无数个变量和函数来完成一个画面的js。我也是，但过段时间自己去改代码bug或者加功能的时候，我的天，这是我写的吗，什么时候写的，怎么理不清思路了,而且，修改一个地方其他地方也得改，改完了还容易出新bug，偶尔都会忘了是自己写的，心里默念：这个傻X...恩，还好是默念。
慢慢的代码看多了点，了解了些js的模块封装的一些方式，面向对象的相关思想（单一职责、高内聚低耦合....再说就有点装了>.<），越来越觉得易读、易改的代码应该需要更好的组织形式，正好最近碰到了一个网友，看了他想优化的代码，真有看到自己一开始写的代码的感觉：各处填补想完美解决问题，可最后还是会有出乎意料的bug，于是用了他的代码做了次实践。
2.一睹为快
如下图，功能比较简易：
选择之后添加，展示区便陈列：
展示区点击‘X’的时候去除当前内容，选择区相应也取消对应的勾选：
3.初出茅庐
先上原版代码看看：
多选框问题 选择区
- 全选
- 1
- 2
- 3
- 4
- 5
展示区
代码拷下来，看着比我刚开始写的前台代码要好不少：注释到位、封装避免全局环境污染、事件功能明确。
放浏览器跑一遍，多点两下...bug就出来了，细看以下代码就知道，bug的出现与他定义的globalV有关，而这个值可以看到是两处在改动，而且是每次事件都会更新。一个数据多个地方多次更改，想知道怎么出问题了，肯定是要花点时间排查的。
bug就不提了，代码是以一种非常流程化的思路在行文，该干什么了就码代码去干什么，我们都在这么干。可当时自己爽了，以后就不爽了，别人也不爽...特别是当代码量开始增大的时候。
4.渐入佳境
多选框问题 选择区
- 全选
- 1
- 2
- 3
- 4
- 5
展示区
更改后的版本里的代码其实都是原来的代码，但组织后的效果是：事件统一绑定（bindEvent），画面统一更新（fun1、fun2、fun3），数据统一设定（updateData）。
区分的很清楚，哪儿出错找哪儿，几乎不会交叉。而且比较容易拓展，像事件可以继续bindEvent绑定，画面更新的函数可以相应与fun1、fun2、fun3并列添加，数据的额外处理可以添加到updateData里。
这仅仅是代码组织上的优化，其实代码本身也有很多可以改进的地方，像全选的判定、选择区联动删除等都有更好的思路和代码实现。
5.梦中初醒
渐渐发现，其实这里面已经有mvc的影子了，各司其职，分工明确，事件绑定那部分就算是一个弱controller，绑定事件,分发事件响应函数；更新画面状态部分相当于view了，更新画面；updateData更新数据部分更新的就是modle；
6.醍醐灌顶
这个组织基本够用了，但它并不是真正的MVC，也不是最优组织，需要你，一语道破天机，希望有人能醍醐灌顶....
顺便看看万金油的MVC模型：
就是看不懂，是不，哈哈。