前段时间（前2个礼拜），忙着给一个基于Web的绩效管理项目作Close，这个项目其实是一套管理类的软件，而Close的工作实际上就是给做那个项目的二期。在项目现有的代码上增加一些功能，比如很简单的一个例子，以前有一个月度的考核，现在需要一个年度的考核，年度的考核基本上跟月度考核一致，如果熟悉面向对象开发的或者了解设计模式，一定会很自然的想到一个叫“模板”的概念，通过抽象来重用、重构软件。问题来了，年度的成绩有很大一部分来自月度考核的结果，好吧，再抽象出一个成绩的接口，由这个接口去负责取考核结果，想法很好，可是你行不通（当然这些更应该在设计之初就考虑的问题）。

这个项目是构建在一个自定义的框架上，为了提高开发效率，框架作了很多工作，开发者只需要调用指定的方法就能完成诸如控件绑定、数据库访问等一些内容，为了进一步减少工作量，有一个小的工具软件专门负责生成数据库访问相关代码，当然有的必有所失，这框架最大的不足就是对类、接口等有很多的限制。实际开发过程中，只需很简单的写一些业务逻辑上的代码，看似一个很完美的构想，如果开发一套系统只需简单的设计一些业务逻辑，真是太美妙了，（微软就是这样设计的MOSS的，微软每次Release产品几乎都会展示一些拖拖拽拽的动作来完成很多功能的Demo，捎带提一下博客园的一篇文章http://www.cnblogs.com/JeffreyZhao/archive/2008/12/10/i-cannot-bear-any-more.html）工业化代码将由此产生。可如果真的细想一下，发现会有很多问题，由于框架对类、接口上的限制比较多，像前面举例说到的项目的二期，几乎似乎无法通过现有代码重构来实现的。在实际操作中我是沿用了分与合 里提及的 CV大法，而这中方法的弊端显而易见，如果需求稍有变动，Nightmare is comming。

从维护这个角度看，并不见得会提高开发速度；从参与开发的人员特别是没参与业务逻辑设计的开发人员角度看，涉及到的业务逻辑本身相对简单，几乎是全部的面向过程编成的思想在做Code，每天陷入一些很无聊的重复逻辑调试中，对开发者本身很不利（并不是说面向过程有多么的不好，可大家都海还面临着衣食住行的问题，开发者本身的身价肯定跟自己的技能挂钩的）；从公司角度来看这个问题就更严重了，公司的产品本身有“质量隐患”，容易把市场做烂，参与制作产品的员工又有“后顾之忧”，担心在这里做了一段后，相对业内其他人员毫无竞争力，有些人财两空的感觉。

需要申明的是，这里没有任何对这个框架的不满的意思，更不是发牢骚，只是明明已经发现这个问题，该好好想想如何改进现有的框架，还是跟其他一些公司一样，沿用一些开源的框架。

• «Previous Post
• Next Post »

---