iMIS为什么会失败?

今天在和同事讨论系统的表结构设计,在回家的路上,我突然“顿悟”了。

大约在三年前,我在上一家公司里干得相当的不错,如鱼得水。我们开发了不少的Web项目,无论是速度还是质量,都能令人大家满意。我们在项目开发中不断地总结经验,打算将一直一来项目中采用的技术产品化、平台化。我踌躇满志地计划着下一个版本的设计,在过去PHP的基础上,我打算采用java进行开发,虽然我在此之前没有用java开发过软件或者网站,但是我当时的态度是:语言不过是工具,采用任何语言来实现我的这个框架都只有细节的区别。这个新的框架,我给它起了一个不错的名字:“iMIS——集成管理信息系统”。

当然,如果有PHP和java开发经验的朋友应该能够预感到,这个iMIS只怕前景不妙,因为PHP中的面向对象相比java的面向对象实在是太简陋了,而我当时的面向对象的基础实在是差得羞于见人。而在当时我是不这么认为的。

但是,不要误会,我的iMIS不是倒在实际的项目上,而是倒在了公司的决策会议上了。当时公司另外还有一个开发框架,名字也不错,叫做“carmot”。这个框架的设计者可不像我这么“外行”,他是正牌的java程序员,而且在来我们公司之前,是教java编程的教师。两个系统作为公司将来可能采用的备选开发平台竞争,我们公司的CTO的选择是显而易见的——现在回想起他当时跟我的数次长谈,我想他当时应该已经做到足够委婉了。

后来,我并不死心,还是在一个中等大小的房地产网站上开始了iMIS的试验,后来有将这个平台使用到了三四个项目之中。这三四个项目,并不失败,开发效率依然很高,而且都基本圆满的实现了用户的需求。因此我也从来没有真正想通过,为什么当初他们不同意采用我的iMIS?

后来我一怒之下,打算将iMIS开源,重新命名为“OpenIS”,还写了两个文档,打算找人帮我一起继续开发这个框架。

openis系统的历史、目标与方案的选择 openis 系统的特性 保存在ITEye上的版本

找帮手需要名气的,我打算到各大java论坛去打打名气,最先去的是CSDN,然后到了jdon,最后落户在了javaeye。名气渐渐是有了,帮手却始终没有找到,认识了很多真正的java高手(我在1年以前是不能算的),也学到了很多java的知识(之前的java代码现在看了都觉得脸红),唯独没有任何长进的是Hibernate的知识,我故意不去学习任何已有的O/R Mapping知识,因为我打算自己做的框架中自然包含着我自己的O/R Mapping。

暂时打住一下,各位可能会认为我这篇blog是篇“OO迷途羔羊”的忏悔吧,其实不是,我还是一点都没有觉得自己的思路有什么问题,只是逐渐地理解了自己为什么会失败而已。 思考软件开发(1)——面向对象的前前后后 我也来发邮件

接着说,上面的两篇文章,是我最早发在javaeye的两篇讨论面向对象的文章。在经过这么长时间的与人讨论之后,我已经越来越意识到,我对于面向对象编程(OOP)的开发从来就不能算是主流的观点,当然随着后来AOP之类思想的兴起,我逐渐感到有了知音。这是我当年的iMIS失败的原因之一。

另外一方面,我对于数据库主流的看法也不是主流的数据库设计的思路,在我看来,经典的数据库设计理论,根本就未曾考虑过像我们现在这样的“必需要拥抱变化”的极限开发境况。数据库范式的设计者,几乎不考虑库结构需要不断变动的情况。而且为了尽可能的减少冗余数据,宁可多写代码,也不准多占磁盘空间。在经典的对象(Object)与经典的关系数据库(Relation)之间,有一条巨大的鸿沟,这就导致一个好的O/R Mapping工具,必须在“面向对象成为绝对主流”之后出现,来填平这一鸿沟。可以预料到的是:“Object与Relation之间的差距越大,Mapping工具就会越复杂。”

现在的Hibernate,正在越来越复杂,可以预见的是,要用好Hibernate,绝非一般程序员想象的那样:“不用再想数据库设计的问题了”,而是必须对面向对象和数据库都有非常深入的了解,才可能用好Hibernate。

回到我的iMIS上来,当初我的iMIS的设计之所以会遭遇不信任,并不是因为他不可行,而是因为没有人相信它可行,无论是一个java好手,还是一个数据库好手,都会很自然的将iMIS的设计理解为“不走正道”,“肯定没有好下场”。唉,关键在于观念的转变呀!

原文写于:2005年05月12日

后记:补充两个事情,OpenIS这个名字,后来被人支持,可以读作:O’Penis,果然是扑街的命啊。

再者,多年以后,与老同事聊天,才了解到一些技术之外的事情,我的那个iMIS,在部门经理嘴里,被说得一钱不值,因为当时的年轻气盛,对部门经理多有轻蔑与批评,难免被人在身后打了小报告。

这些非技术的事情,我一直都不太擅长的(这么说来,好像我的技术有多擅长似的)。