JavaScript重构深入剖析(1)


通常我们的团队中,开发人员在Java语言层面具备相当的技术素养,经验丰富,而且有许多成熟的、合理的规约,类型繁多的代码隐患检查工具,甚至在团队间还有计划内的评审和飞检。但是前端的代码不似后台,就像一个没人疼的孩子,不仅仅容易被低估、被轻视,导致质量低劣、可维护性差,技能上,更缺少优秀的前端开发人员。


JavaScript是前台代码中重要组成部分,随着版本的延续,产品越做越大,JavaScript层面的重构,需要在整个过程中逐步强化起来。


当代码量达到一定程度,JavaScript最好能够与页面模块组件(例如自定义的FreeMarker标签)一起被模块化。


模块化带来的最大好处就是独立性和可维护性,不用在海量的js中定位问题位置,简单了,也就更容易被理解和接受,更容易被定制。


模块之间的依赖关系最好能够保持简单,例如有一个common.js,成为最通用的函数型代码,不包含或者包含统一管理的全局变量,要求其可以独立发布,其他组件js可以轻松地依赖于它。举个例子,我们经常需要对字符串实现一个trim方法,可是js本身是不具备的,那么就可以在这个common.js中扩展string的prototype来实现,这对外部的使用者是透明的。


模块划分和命名空间


使用命名空间是保持js互不干扰的一个好办法,js讲究起面向对象,就必须遵循封装、继承和多态的原则。


参照Java import的用法,我希望命名空间能带来这样的效果,看一个最简单的实例吧:


我有一个模块play,其中包含了一个方法webOnlinePlay,那么在没有import这个模块的时候,我希望是js的执行是错误的:

  1. webOnlinePlay(); //Error! 无法找到方法 

但是如果我引入了这个模块:

  1. import("play");  
  2. webOnlinePlay(); //正确,能够找到方法  

其实实现这样的效果也很简单,因为默认调用一个方法webOnlinePlay()的实质是:window.webOnlinePlay(),对吗?


所以在import("play")的时候,内部实现机制如下:

  1. var module = new playModule(); 

对于这个模块中的每一个方法,都导入到window对象上面,以直接使用:

  1. window[methodName] = module[methodName]; 

其实这里并没有什么玄机,但是这种即需即取的思想却给前端重构带来了一个思路,一个封装带来的可维护性增强的思路,不是吗?


聪明的你也许还会提到一个问题:


如果我没有import这个play模块,这个页面都不需要,那我能否连这个play.js都不加载呢?


当然可以,请关注下一页———关于js的动态加载的部分。





标签:

友情链接
轻松育儿世界奇观
苏ICP备16066217号-2