如何构建自己的Framework（银弹）,适应用户多变的需求 (2)

1) 关于重新发明“轮子”的 “惑”与“祸”

 

   我大学毕业的时候，开发语言从毕业设计用到的Foxbase换到了Visual Basic,从Visual Basic版本3.0一直用到了Visual Basic6.0,2000年的时候，工作换到了一家网络公司，开始了基于Java和J2EE的开发，一直使用Java和J2EE开发至今，期间一直没有使用过C语言的机会，所以一直不能算作真正的程序员，也没用过Delphi，所以也不能算作聪明的程序员。

 

    我觉得使用微软技术的困惑就是你所用到的80%-90%的控件，Microsoft都给你做好了，核心思想是Data Binding,开始使用的时候，的确是非常的易用和好用。随着产品、项目的深入，当现有技术不能满足你要求的时候，你可能就非常难受了，自己真的深入下去的话，发现也是一个无底洞，加上Microsoft的技术不开源，要想深入了解，还是蛮难的，最后的结果就是从网上疯狂的寻找第3方控件，找来找去，就会发现免费的的确不好用，好用的的确不免费，自己去开发一个满足自己功能的控件，几乎是不可能。

 

而基于java和J2EE的解决方案，幸福的是，你所有的困惑，几乎都可以从网上找到答案，而且源代码基本都是开源的，要想深入下去，还是蛮容易的。而它的坏处也是致命的，就是解决方案太多了，不仅另初学者难以下手，不知道该看什么好，该听哪个误人子弟的大侠的高谈阔论。即使已经深入到某个领域的老手，如果自己公司产品的核心应用，基于到某个 开源的解决方案，虽然问题当时可能“完美”的解决了，以后最大的问题可能就是这个开源的项目不更新了。比如：对于工作流，几年前基于Shark和OSWorkflow开发的公司，可能并不在少数，OSWorkflow好几年不更新了，Shark好几年前开源协议也变更改了。再比如著名的Spring和ExtJS，也是中途更换了开源协议，另基于它上面的开发者就会骑虎难下，不知道这个产品和项目是购买它的商业License,继续下去，还是不做了。

 

所以，对于“轮子”，我的态度是坚决要重新发明的，这种发明，是基于对原有轮子的理解上，可以使用这些本来很好用的轮子，但不要把它放到自己的核心应用上，先解决自己不能解决的问题。比如，我只用了Spring的transaction,对于transaction，我发现唯一的开源项目"JOTM" 也是好几年不更新了。而对于O/R Mapping，我自己就重新发明了一个轮子，倒不是嫌弃Hibernate的性能或者啰嗦，而是我自己做的这个框架，要能做到与数据库表结构无关，而Hibernate要求与表结构一一对应，SaaS应用嘛，跟数据库表结构绑定太紧，就无法做到个性化定制了，Hibernate无法满足我的功能，而且这是我的核心功能，所以我肯定会重新发明一个轮子。