• 基本类型的常见扩展：原生的javascript对象API往往在现实中不够用，比如常见的Array.indexOf/remove/each，Date.parse/format，不管是怎么封装都需要这类方法
• DOM操作常见方法：DOM节点增删改查，CSS selector，DOMReady，contains，add/remove/toggleClass，屏蔽浏览器之间的操作差异。不多说，人人都熟。
• 一套浏览器检测机制：以前大家都倾向于做浏览器类型和版本的检测，现在倾向于做浏览器的特性检测，这样更有实际用处。
• Ajax的封装，对于组件库来讲可无。毕竟组件库本身的实现不太会用得上Ajax。

• 事件机制都无一例外的是基于第三方观察者或者叫做沙箱(Sandbox)实现。
• 事件机制更深的功能是提供一个模块的通信机制。
• 对于组件库，组件实例之间的通信更加重要，组件实例之间最好不要存在相互引用的关系，互相不能感知对方的存在，有了事件机制，可以通过第三方有效的通知组件实例，减少组件实例间的耦合。

• 该组件继承自哪些组件或者基础类，或者依赖于那些类？
• 组件实例的管理方式，因为每个组件实例都需要在一个容器中统一存放，理想的的存放模型应该是树形的，在内存中存在类似DOM树一样的组件对象树，是否可以通过类名找到相关实例，根据ID获取实例，获取子实例，父实例，父/子实例之间的通信父实例的resize是否能通知容器内的实例resize。
• 插件机制：作为一个非常重要的扩展机制，插件能有效的解决组件间的复用部分，通常这部分会叫做行为(behavior)，对于组件不能提供的甚至是个性化的功能，有没有提供有效的，足够多的扩展点。
• 提供怎样的实例化方式？ new XXX() ?? 还是类似DOM的操作方式appendInstance??甚至有类似jq这种链式。我更觉得应该使用appendInstance的方式，这样能更加有效的体现组件示例间的父/子关系。就像DOM操作一样，最终组件实例也是树形结构，如果我们直接new XXX() 这种方式，其实相当于声明了一个游离态的 DOM节点。实际我写代码的时候发现要管理这些组件实例也是比较麻烦的地方，试想一个页面如果有多个组件实例，需要声明多少个实例变量，或者申明多少个对象去存放这些实例。
• 组件提供的API，一个组件对外暴露的API会包括初始构造方法，公共方法(method)，事件(event)，对于event，提供怎样的eventData也非常重要。

• 模块本身的定义，注册，直接影响一个组件的代码模型，一个组件是一个模块。
• 模块的依赖申明以及追朔机制：就像前面提到的，依赖于那些类，css文件，资源，数据。不仅仅需要声明，还应该可追朔，依赖的父类，也能找到父类本身所依赖的资源，这样为按需部署打包，在线调试提供居多方便。
• 加载机制：因为在开发阶段要么放一个整个组件库代码，要么是通过一个加载器按需加载，到了线上希望只部署引用到了模块组件，这样可以减少实际部署的文件大小。加载机制会涉及到浏览器的javascript/css文件的加载，尤其是需要尽可能的并行下载而且按照依赖关系先后执行。包括应用模块，可以方便的通过这种加载机制延迟，按需，按时的加载到页面中。
• 打包部署机制：由于依赖可追朔，这样实际项目中用到的那些组件可以分析出来，最终可以根据实际使用到的情况打包出适合大小的组件库，减小冗余包的存在。
• 模块间的通信机制，由于模块减轻耦合甚至是独自孤立存在，组件之间的通信就非常重要，比如通常一个页面上面的菜单组件实例点击需要触发下面组件的更新。如果直接监听菜单事件去更新下面的组件，也许菜单是每个页面都有。但是下面的组件不是每个页面都有，这样的事件监听就显然耦合较重，互相依赖对方的存在。如果菜单点击这是告诉第三方我被点击了。下面的组件只去监听第三方的事件，这样的代码思路明显要好过很多。

• css Expression:不仅IE only，更重要是CSS中写javascript这个风格不对，难以维护。
• javascript直接修改style.xxx='xx'。能写成css class的最好都写成css class。
• html中直接写onxxx="foo()"，没有人能保证foo方法存在不被修改。

• 测试用例：通用组件库是一个庞大的工程，也许牵一发动全身，不知道哪个API的变动会影响多少调用者，有充足的单侧用例，一定程度上能保证整个组件库的稳定性。
• 粒度：粒度是一个很值得思考的问题，其实html的标签可以当做是一个小的组件，只是因为粒度很小，要完成一个复杂的应用，有很多的可复用组件都需要用到大片大片的重复html片段。另外一个极端，我们我们把整个页面都写成一个组件，显然没有复用性，跟没封装一样。所以选择一个合适的组件粒度，一个组件完成特定的功能，有利于搭建出有想象力的应用。
• 一致性：需要有很好的代码规范和约定。才能保证API的一致性，用户也会理所当然的想到怎样用API，降低学习成本，一个最常见的例子就事件监听的参数，建议统一为(eventObject,eventData)。
• 文档&Demo:这个不用多说，没有文档和demo的东西没有人去看代码怎么使用。
• 性能：DOM操作是组件库的性能杀手，高效的DOM操作尤其重要，事件监听也是非常耗时的，建议能采用代理的都用父节点来代理。
• 资源释放：组件的资源，引用是否能完全释放？尤其是开发SPA，组件的资源内存释放就非常重要了。

我估计很多人看了这些属性后笑了，的确，很多人这么做过。后来发现这样做很不灵活，无法满足需要，其实这个问题很简单，为什么不应用一种表达式，ognl,el之类的表达式放在配置项里，这些属性就灵活很多。siebel这样的产品，不也有一些地方需要些一个脚本，比如escript之类的东西么。想想我们天天琢磨的业务，不就是这些东西么。把它配置到数据库里面，接下来就是怎么生成页面的么。我看到的目前大多数的做法是做一个代码生成器，我认为这种做法很不好，代码生成器本身是解决了很多机械活，但是关键还是你生成的代码本身的质量。没错，你可以用代码生成器去免去上万行代码要手写的尴尬，我不仅要问，为什么会弄成上万行的代码？有的人还喜欢吹嘘我写过上万行的Java代码，我更是嗤之以鼻，这不是你的骄傲，这恰是你的悲哀。上万行的代码，我见过的有两种可能性，一个是java/jsp代码没有重构，没有封装。二是数据库的设计有问题，一个表200个字段，页面能不复杂么。第一种是架构师要解决的问题，第二种那据是设计时要注意的事情了。扯远了。界面是怎么出来的。至少不是用代码生成器跑出来的。接触过ruby on rails 或者grails的朋友肯定知道里面的activerecord/scanffold组合快速实现crud。不过他说白了也是在生成页面+改代码，我还是不喜欢。因为界面确实是太灵活。我的思路分两个个方面入手:1.封装字段，根据上述字段属性封装成jsp的tag。这个tag通过字段名读取元数据属性，生成浏览器执行的html,javascript。2:所谓页面不久是指定这个页面有哪几个字段不就得了。查询页面，那几个字段是查询条件，读取字段的查询属性。编辑页面，无非是指定编辑哪些字段就行，在这个基础上做一个小工具，页面就很容易出来。当然，好的框架还要解决一个问题，就是变更。怎样能以最少的代价做变更。这个我是这么想的。比如说，某个表删除一个字段，我们可以提供一个工具查询哪些页面引用了这个字段，然后用程序一并删除，其实这个实现也不难，因为每个字段无非就是jsp页面的一个tag么。大不了用个全文搜索。用正则一替换就完了。

上面是我总结的快速实现crud的一些想法。这部分其实是很多重复性劳动的根源，把这些工夫省下来了。开发效率高很多。

我这里说的业务可能是一个有别于技术的东西，有些东西纯粹是靠技术来实现的，用户没有概念，跟他说也没有用，比如做接口，你可能用web service 。用TCP通信等等。这些很多是用户是看不见的。

我认为一个比较理想的业务系统应该是业务驾临在技术之上，二者相得益彰。技术需要解决的问题是他有一个平台，能让业务方便的在这个平台上实现。所以我们在做架构的时候要分清楚哪些是业务需要解决的问题，哪些是技术需要解决的问题。

从业务的角度看技术，我希望业务能够非常方便的在这个平台上实现，不仅如此，我还希望我的业务变更了。能够以最少的改动或者不改动就能够实现变更。理想的做法我希望业务都是配置进去的，我在变更的时候只需要修改相应的配置就可以了。当然100%的配置出来也不太现实，据我所知，在sap,siebel里面的报表是必须开发的。因为报表主要是查询，查询就非常灵活，单靠配置能难达到目的。

从技术的角度去看业务，再好的技术加上一个不入流的设计，都为成为教科书上一个很好的反面教材。业务人员需要在对业务的把握上设计软件。

既然要复用，要能够用配置实现业务，那配置些什么东西了?那些地方可以配置。这个就是框架要做的事情了。说到框架大家最喜欢议论的就是怎么快速实现crud了。毕竟，一个系统的很大部分都是在做这个事情。

背景

应该说我从事的是企业管理软件开发，blog标题也说了。做销售领域，怎么说现在的客户也是在国内很有名气的。现在的公司也专注的在的企业信息化的工作。我们面对的业务主要是销售领域，我们部门也曾经做过一些不太成功的crm。售前/售后的领域，想想我们天天说的是企业级应用我认为也算得上了。在我的理解里面，企业级的应用在业务上是一个很专业的领域，需要对软件开发商具有相当的业务能力，公司喜欢把我们的业务人员叫业务顾问，大抵的意思就是我们能提供一个行之有效的解决方案吧。这更说明我们对业务要有相当的了解。所以我们可以专注的做一个行业，做一个领域，把这个领域做精做强了，才能主导市场。说大了。这些当然不是我现在考虑的问题。我只是介绍一下我的业务背景。技术方面，用的是j2ee环境。

我们面临的问题

主要还是两个方面吧。一个是业务方面的，需求不确定啦，永远不停止的变更啦，客户的抱怨啦，迟迟不能上线啦。一个方面是技术方面，代码都是copy/paste啦，大量的无聊的重复性劳动，写代码慢慢的成了体力活。其实这些都是大家经常遇到的问题。

我的看法

这些问题都很宽泛，不是我一个在叽叽喳喳几天就能够全部解决的。我想解决的问题是怎样通过技术手段实现业务的实现，从而形成一个高效的复用的解决方案。领导也想把我们的这个领域做成一个解决方案，形成一个产品，可以拿来实施。其实这个与我最自己的目标还是蛮相近的，我也希望我能从0开始做出一个产品，从技术走向市场，这是公司为用户创造价值的更好的体现，也是我个人的能力的体现。

写作计划

这个话题我想说的很多，都是自己在实践中的思考，我的想法是从技术的角度切入，然后到设计，最终我想形成一个我认为比较理想的业务实现框架。下面是这个系列的索引。