在我所负责的产品项目中，在代码编码模式上，使用了函数式编程的方案。约定唯一的命名空间，提供namespace、mixin等基本的语言扩展功能。或者这并没有什么，重要的是一套编码模式。在linux中来说，就是将一个任务细化为一个细小、单一的功能。在我的方案中，基于目前公司开发流程上的约定和线上代码的发布方式，使用一个唯一的命名空间，之后通过这命名空间来维护代码的组织，将一个功能细化，尽量细化到功能单一，保持每一个函数都能够在20行代码以内，并且提供语义化清晰的命名，以及结构化的注释方式，这样代码看起来就整齐有道，极富特点，看起来愉悦，其中一个主要的是提高复用度和较少重复代码和重复功能。 在维护阶段，因为由于维护人员的不同，以前的做法是使用闭包的方式，来包含每一个人新增的代码，保持代码不影响其他的功能。这种方式是可取的，但是这样不容易形成统一的编码方式，在大方式上抓不住，特别在codereview的时候，不能形成统一的阅读方式；而且，使用闭包的方式，在代码复用度等方面基本是难以把握的，基本是代码堆砌，无视之前的实现代码中是否有能够复用的功能函数。使用函数式的方式，那么在维护方面，可以很方便的在原来的代码中复用功能，或者添加、删除功能，因为都在同一个context上下文中，同在一个命名空间下。 使用了函数式编程的方式之后，在我最近的一次项目中，得到了很好的实践，在频繁的需求更改中，由于将功能细化，实际上就是一个大功能，由一堆小功能函数根据不用的条件组织而成。那么在修改功能的时候，只是需要修改其中的小功能函数，或者是删除、增加某个小功能函数，都显得很方便，也很快速，在功能切换上也能够很快的过度。 尽量保持一个函数在20行以内，会让维护者看代码的时候很兴奋。
《重构–改善既有代码的设计》这本书是去年买的了，利用晚上空闲时间看了大部分的内容，包括一些重构的技巧、良好代码的特点、代码可读性和提高语义化等。这本书改变了很多我之前所持有的观念，包括代码性能、模块化设计、结构样式逻辑分离等的思维。下面粗略的罗列几点目前自己从这本书中所理解到的其中一些知识： 重构本来就不是一件应该特别拨出时间做的事情，重构应该随时随地进行。 第一次做某件事情时只管去做；第二次做类似的事情会产生反感，但无论如何还是可以去做；第三次再做类似的事，你就应该重构。 ——“事不过三，三则重构。”
今天下午终于有点空闲的时间了，以前基本都是时间安排都是单线程的，这些天突然进入了多线程的时代，很紧张的说。这些天进行了一个项目的改版，修改了整个页面的代码，包括HTML、CSS、Javascript。那么来说一点Javascript代码重构的一点点体会。 我非常喜欢在编写完初步的代码之后，就开始对代码进行重构，这虽然说不是专业的代码重构的工作或者提倡的行为，纯属个人爱好，趁热打铁，为的就是在code review的时候不被批的很惨。 代码重构，很大的程度上是从代码的可读性、可维护性、可扩展性、精简代码结构、提高性能、去除重复性代码、提高代码的复用度等方面入手，把糟糕的代码整理的顺顺当当的，一目了然。就像是一团打卷的面粉，用热水泡过之后，用手撂一撂，顺当的富有弹性，有些人看到会流口水的说。 首先，有一点得说明，代码重构不是为了解决项目难题而开展的工作，它的主要目的是为了代码的可读性和后期的可维护性、可扩展性等这些方面的考虑，而对当前的代码进行小范围的修改，而且是不影响目前界面UI的显示以及交互逻辑功能。说来简单，不影响界面UI以及交互逻辑功能，仅通过这些就开展重构工作，肉眼有时候很难发现代码层面的修改对界面和逻辑造成的整体的影响，所以一个可视化的测试系统，就显得重要了。这个是题外话，还在探究中……
2010-10-21 updates: 根据Wait在评论中提出的对于初始化以及触发事件等的扩展，改写了一下代码。当初是注重了功能完好的实现，没有在意后期的扩展和维护，这两方面得结合起来思考。对此，先不说代码编写以及接口提供的好与否。当然了，因为这个相当于是一个模块，就涉及到独立的HTML，JS，CSS等，特别是CSS可能就需要使用JS脚本来动态插入到页面中，这个先不提供，先从简单的开始吧。一切源于简单，也终于简单，过程会很负责…… 下面还是使用给每一个li添加事件的方式，而并没有使用事件委托的方式，当然了，改成事件委托，也都还是可以，不过也得使用循环来初始化。 [javascript] init: function(props){ //使用对象字面量的方式作为参数 props = props || { "id":null, //handler id "trigger":"click" //事件类型 } if(!props.id){ … 了解更多