今天在和同事讨论系统的表结构设计，在回家的路上，我突然“顿悟”了。
大约在三年前，我在上一家公司里干得相当的不错，如鱼得水。我们开发了不少的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，在部门经理嘴里，被说得一钱不值，因为当时的年轻气盛，对部门经理多有轻蔑与批评，难免被人在身后打了小报告。
这些非技术的事情，我一直都不太擅长的（这么说来，好像我的技术有多擅长似的）。
