低劣的设计,会使你走向泥潭,难以自拔
我进这个公司一年多一点了.刚进公司没什么事做,所以经理就让做一个小系统,为公司以后的需求作准备.
为了快速的完成任务,我也就没有多考虑用最简单,传统的方式(jsp + javaBean)很快完成了项目.系统经过测试员测试通过 这样我才放心了.
现在公司准备上线系统,这下可把我害惨了.系统写了一年左右了,用户的需求我都不记得了.此时,用户又对系统提出了新的需求,要求修改.我没有办法,系统是我写的,那么更新维护自然也是我的事情了.我只有拿出原来的文档,重新整理思路,才把相关的需求回想起来.随着时间的推移,经验的积累,看到自己写的那些代码实在是难以忍受.现在要维护系统了,感觉是牵一发动全身,真是糟糕透了.当时写出系统时还沾沾自喜,自己又搞定一个系统,很有成就感的.现在我看你还牛到那去.
回头再审视自己做的设计,写的代码. 发现了不少问题.
1)层次混乱.我们经常说的表示层,业务逻辑层,持久层相互高耦合,没有一个清晰的分层.系统的架构应当采用现在流行的框架.比如说
表示层用webwork,struts,spring mvs,jsf等等,
业务层(事务管理,,,)spring
持久层用hibernate,iBatis,,,,
2)没有面向接口编程.整个系统中没有见到一个接口.我还停留在面向类的编程.养成良好的编程习惯.
oop,aop让你的系统有好的维护性,扩展性
3)业务实现细节,性能上存在问题.比如说:对基本信息的修改实现方式真糟糕.因为基本信息的属性有40多个,它和另一个表是一对多的
关联关系. 当时觉得那么多属性,懒得用update一个一个得来更新,干脆把相关得信息(包括它关联的另一个表的信息)删除掉.这样造成了很多不
必要的操作麻烦.你修改基本信息,为什么要去删除它关联表的信息,然后又要把它的信息添加进来.这不就是画蛇添足吗?先删除,然后又添加,
一些不必要的操作,造成了性能的下降.系统的开发遵循简单的设计.
4)业务操作混淆.添加新的基本信息与更新基本信息都放在同一个方法中.每一个业务方法对应一个操作.
5)系统不稳定.对系统要有好的单元测试,集成测试.
6)用户操作不方便.要站在用户的角度多考虑,那样的操作是他们习惯的,他们想要的.
这样的系统真是糟糕,难以维护,难以扩展,很难有好的性能.
我们开发的系统不能满足于够用,做出的系统要有好的可维护,可重用,可扩展性.