按需加载，顾名思义就是在用户需要这个功能的时候就初始化这个功能，加载相关的脚本和样式文件等等。普通我们使用的方式，就是在需要的时候，就添加一个文件的url进行加载，并且用一个对象来记录已经加载过的文件。这种方式有些散乱，对于是随意加载的，那倒是不可避免，但是对于一个项目来说，页面的的功能和相应的文件是确定的，那么还是使用上面的方式的话，那么在后期的维护上会比较混乱，增加了成本。 对项目之外的文件加载，使用普通的方式散乱在代码中，也不太合适，那么就需要一个封装的加载器，统一加载文件的接口和调用方式。我下面将要讲的“加载器”，不是传说中的模块化中的加在方式，我更多的是从代码维护方面来考虑，使得一目了然的看到页面本身的功能需要按需加载一些什么文件列表，并且可以标记已经加载的文件，而不会使得url散乱在页面中。 //需要按需加载的内部文件列表映射 mis.classFiles = { ‘AjaxEvent’: ‘includes/ajax.lib.js’, ‘AjaxRequest’: ‘includes/request.lib.js’, ‘colorFade’: ‘includes/effects.lib.js’ } //标记已经include的内部文件 mis.includedFiles = {}; //对内的文件加载 mis.include = … 了解更多
在我所负责的产品项目中，在代码编码模式上，使用了函数式编程的方案。约定唯一的命名空间，提供namespace、mixin等基本的语言扩展功能。或者这并没有什么，重要的是一套编码模式。在linux中来说，就是将一个任务细化为一个细小、单一的功能。在我的方案中，基于目前公司开发流程上的约定和线上代码的发布方式，使用一个唯一的命名空间，之后通过这命名空间来维护代码的组织，将一个功能细化，尽量细化到功能单一，保持每一个函数都能够在20行代码以内，并且提供语义化清晰的命名，以及结构化的注释方式，这样代码看起来就整齐有道，极富特点，看起来愉悦，其中一个主要的是提高复用度和较少重复代码和重复功能。 在维护阶段，因为由于维护人员的不同，以前的做法是使用闭包的方式，来包含每一个人新增的代码，保持代码不影响其他的功能。这种方式是可取的，但是这样不容易形成统一的编码方式，在大方式上抓不住，特别在codereview的时候，不能形成统一的阅读方式；而且，使用闭包的方式，在代码复用度等方面基本是难以把握的，基本是代码堆砌，无视之前的实现代码中是否有能够复用的功能函数。使用函数式的方式，那么在维护方面，可以很方便的在原来的代码中复用功能，或者添加、删除功能，因为都在同一个context上下文中，同在一个命名空间下。 使用了函数式编程的方式之后，在我最近的一次项目中，得到了很好的实践，在频繁的需求更改中，由于将功能细化，实际上就是一个大功能，由一堆小功能函数根据不用的条件组织而成。那么在修改功能的时候，只是需要修改其中的小功能函数，或者是删除、增加某个小功能函数，都显得很方便，也很快速，在功能切换上也能够很快的过度。 尽量保持一个函数在20行以内，会让维护者看代码的时候很兴奋。
思路：使用一个储存器，将不同“职责”的处理函数储存起来，之后通过一个统一入口，来处理储存器中的的“职责”函数，将执行有效的结果，立即返回，到此，职责处理完毕。 应用： 在对于传递不同的参数来处理不同的功能； 将功能分“职责”，结构清晰，功能分明； 使用函数的方式，来代替了函数 内部的if逻辑过于负责的判断，可以无限的扩展，最重要的是，可以在不不动原来的函数的基础上，就可以添加其他的“职责”处理函数； /**职责链模式的思维*/ //储存器 var middleware = []; function turning(){ var ret; if(arguments.length > 0){ for(var … 了解更多
《重构–改善既有代码的设计》这本书是去年买的了，利用晚上空闲时间看了大部分的内容，包括一些重构的技巧、良好代码的特点、代码可读性和提高语义化等。这本书改变了很多我之前所持有的观念，包括代码性能、模块化设计、结构样式逻辑分离等的思维。下面粗略的罗列几点目前自己从这本书中所理解到的其中一些知识： 重构本来就不是一件应该特别拨出时间做的事情，重构应该随时随地进行。 第一次做某件事情时只管去做；第二次做类似的事情会产生反感，但无论如何还是可以去做；第三次再做类似的事，你就应该重构。 ——“事不过三，三则重构。”
今天下午终于有点空闲的时间了，以前基本都是时间安排都是单线程的，这些天突然进入了多线程的时代，很紧张的说。这些天进行了一个项目的改版，修改了整个页面的代码，包括HTML、CSS、Javascript。那么来说一点Javascript代码重构的一点点体会。 我非常喜欢在编写完初步的代码之后，就开始对代码进行重构，这虽然说不是专业的代码重构的工作或者提倡的行为，纯属个人爱好，趁热打铁，为的就是在code review的时候不被批的很惨。 代码重构，很大的程度上是从代码的可读性、可维护性、可扩展性、精简代码结构、提高性能、去除重复性代码、提高代码的复用度等方面入手，把糟糕的代码整理的顺顺当当的，一目了然。就像是一团打卷的面粉，用热水泡过之后，用手撂一撂，顺当的富有弹性，有些人看到会流口水的说。 首先，有一点得说明，代码重构不是为了解决项目难题而开展的工作，它的主要目的是为了代码的可读性和后期的可维护性、可扩展性等这些方面的考虑，而对当前的代码进行小范围的修改，而且是不影响目前界面UI的显示以及交互逻辑功能。说来简单，不影响界面UI以及交互逻辑功能，仅通过这些就开展重构工作，肉眼有时候很难发现代码层面的修改对界面和逻辑造成的整体的影响，所以一个可视化的测试系统，就显得重要了。这个是题外话，还在探究中……
对于前端来说，协同开发同一个页面的情况是比较少见的，就算是一个模块，也都有可能都是由专人负责维护和更新的。但是对于一个公司内部所通用的库、框架、工具箱来说，协同开发可能就会经常遇到了，因为这个可能是有多个人一起维护更新的。那么怎么去避免因为协同开发所导致的冲突呢。 一个最简单且合理的方案是：永远不要删除、修改不是由你负责的类和对象的接口。要是现有的类、对象不能实现你的需求，那么就在原有对象的基础上添加方法。可以通过代理类或者委托来声明新的接口，并调用原对象的接口；或者使用外加函数的方式，独立声明一个函数，并把类的实例或者对象通过参数的形式传递给外加函数。要是外加函数过多了呢？那么就独立声明一个类或者字面量对象吧，统一管理这些外加函数，并提供统一的参数接口。复杂的还可以添加一些工厂的方法。