关于轮子

1. 发明or不发明轮子实际上算不上一个问题，在一个连免费卡迪拉克都能找到的年代里，发明轮子这种有闲阶级的勾当在第三世界国家的名声实在是很差。但常见情况如下：
   1. 偶设计了一小破三轮，虽说飞机轮胎是免费的，咱伺候的起吗。
   2. 偶好歹是一小型吉普，自行车轮满大街都是，安不上去也是枉然
   3. 隔壁的轮子挺好的，就是比咱整车还贵
   4. 备选轮子太多了，而且都没有使用说明书，质量鉴定书，考察的时间耗不起
   5. 瞧见了没，上次捡回来的轮子大小正合适，但中途爆胎之后没人会修理，培养一个修理工的费用和发明一个也差不多了。
   ...
   言归正传，从功能上说，一般你希望具有的功能实现，确实能够在某个地方能够找到，但能否为我所用是另一个问题。
   1。经常是只用到软件包的部分功能，出了问题却要了解整个开发包，维护成本过高。特别是外部软件包的发展方向往往你无法控制，如果自己开发一些增值功能，又怕在后继版本中出现冲突。
   2。方言也是一个很大问题。面向对象虽说能够在程序中引入语义概念，但没人保证该概念的外延和内涵是能够得到一致公认的（一个ontology的问题），具体实现的语法层面上的争议就会更大。当然，目前这一方面的问题正处在收敛的过程中
   3。context是最严重的问题。很多软件包严重依赖于封闭的context环境，存在一种整体性，无法剥离出可以独立使用的合适大小的模块。AOP思想提供了较理想的解决方案，只是广泛应用可能还需要一段时间。

   无论是使用别人的轮子还是发明自己的轮子，在目前的环境下，至少要发明一个轮子的标准，统一交互的规范，但接口一定要小。尽量将配置和管理函数剥离到IoC容器和JMX管理模块，以压缩功能接口的大小。例如spring提供的factory函数很多，我们实际调用的时候一般只需要
    interface IBeanFactory{
       Object getBean(String name);
    }

   自己发明轮子最大的风险在于屁股擦不干净，最难擦的就是操作系统的屁股，浏览器的屁股等等系统级屁股。系统级的bug已经超出了一般开发者的控制范围，唯一的解决方案就是在使用中修正，对这种应用选择一个现成的轮子无疑是最佳的选择。好在java平台还比较干净，加上一般有源码，可以动态装载，局部修正。