工作小记：WEB前端优化的实施有效性，VIEW的盲区。

最近对公司腾云2号计划所开发的产品中的店铺进行详细的检查，发现很多前端性能及交互体验性的问题。

记录后，着手进行逐一的优化，检查过程中核实了这些问题已经延伸到后端MVC的View层上，即smarty templetes页面。

这些也许是无法避免的，view层虽然代码分离，但却没有从工作职能上被很好的分离，原始的说，这些都由model和Controller层的开发人员完成。

而他们更多的并不关心关于前端的优化及交互功能体验，对于他们来说，数据处理性能和业务逻辑以及model和controller的耦合性才是他们关心的重点。

然而对于项目中的前端开发人员，他们并未涉足到view层，他们最关心则是在产品还是静态html页面的时候，所有页面的兼容性、可访问性、页面结构的合理性、重用性等等。

也许在页面还是html的时候，那些js的性能优化，页面结构的优化，请求数的优化看似已经做得比较成型。好像剩余的也就是对用户操作体验的分析并逐步细微的修改交互体验等等问题。

可是一旦这些东西经套上了smarty经过了view层这个职能盲区，很多很多的问题就出现了，重新查看生成后的页面源代码，我看到了：

一串串浪费流量的开发中的注释；页面底部的javascript突然变得多了起来甚至他们还有重复；充斥着整个页面的空格，但是他们不应该是缩进符么？

一些后端开发人员自己添加的一小串串的细小功能的JS代码，甚至那些代码根本没有过性能考虑；一些后期需求的修改后，根本没有可重用性的JS代码；这个页面根本没有引入某个JS文件的需要，但是它切实被引入了，因为他们都是includeing统一的foot.templetes或页面；后端开发人员不知道前端公共库的类型，自己写了一些重复的代码；

如上这些问题还是发生在前端与后端的职能衔接上面，最终问题到了PM和SEO以及UE那里，那些根本不应该存在的问题。最后SEO居然还找不到应该负责的人来解决这些问题。

今后如果我们要求前端开发人员都熟悉smarty，并且接手view层的工作，则对controller层的开发人员的文档编写能力提出了要求。

顺便一提，在新修改的店铺中，尝试抛弃原始javascript交互开发中常用的事件机制，而是采用类似windows的消息机制实现，在很多的游戏开发中，其实也用到类似的方式来处理。

不得不提，这样的模式突破了JS在事件和DOM元素之间处理的瓶颈。由此，不用再关心dom树的变化；更加不用关心页面到底有哪些dom元素；某个元素的事件是否处于监听状态；那些一片一片的事件绑定和处理的分离问题，代码结构的清晰问题，后期的可维护性，可扩展性都得到了良好的解决。个人觉得在某些功能的实现中性能也得到非常明显的提升。

总之，DOM元素都不用再关心事件了，很爽，店铺优化完成后，将把这种模式记录在博客中。