前不久以系统设计的角色参与了一个小型项目,下面总结一下项目开发过程中的感受.
作者:jazzy 时间:2005-08-01 版本:1.0
中小型项目,复杂度不高,开发进度紧迫.
在这样的项目特点和时间节点的要求下,项目组为了加快开发进度,采取了通过对以前一个有一定类似度的项目二次改造的方法来构建新系统.这样的开发方式在项目开发中很常见,实际就是对项目级别的软件复用.它是技术部知识积累的价值体现,无论从节约成本和提高工作效率来说都是大有裨益的.这样的开发方式,至少从现象上来说,是很令人振奋的:一个中小型应用,通过对其他项目的复用,在两三天之内就可以完成项目原型.十几天后整个系统就可以上线试运行.
但是,在看似光鲜的表象背后却隐藏着难以被人察觉的污垢.
对于设计人员,在这样的情况下做进一步的设计必需要充分了解前一个项目的结构.他会这样说:前一个项目的说明文档在哪里?数据结构说明在哪里?天那!竟然什么文档都没有,我还是通过代码走查来猜测原有系统的设计意图吧!oh!my god!
对于开发人员,进行开发需要阅读原开发人员的代码.他会这样说:为什么没有注释?这个变量命名代表什么意义?这个问题原系统没办法实现,我还是用自己的方式来解决吧!oh!my god!
对于领导来说,不必关心开发过程,只要关心在规定的时间节点有没有达成任务目标.这样一来,工作压力被堆砌在设计和开发人员身上,尤以编写最终代码的开发人员为重.
在以往的工作经验中,我也以开发人员的角色参加过这样的项目.切身体会过这样开发的难处.当时我的项目原有开发人员离职.我为了实现一点小小的改动,不得不跟踪查阅整个系统的代码.这时的开发人员会十分抱怨原系统代码的丑陋,而且原系统中原有的一些优秀设计思想和闪光点也在这样的修改过程中被埋没甚至消逝了.
当然了,A项目被修改成B项目,B项目将来也可能会被修改成C项目,C项目又修改成D项目.新的设计开发人员,又会产生新的,类似的抱怨.在一次次的修改和抱怨声中,系统的质量越来越差,效率越来越低,bug越来越多,代码中到处充斥着坏味道.重构吧?是时候了.可是谁又愿意接手这样无序混乱,高熵的代码呢?
问题的本质在哪里?
问题的本质似乎是显而易见的.原有系统的文档不齐全,不规范,不一致,给后续的复用带来了理解上的困难.进而这种困难会映射到后续的每一个项目.但是解决这样的问题是件棘手的事情,每个人都知道文档的重要性,但是介于项目的开发进度的要求,大多数时候,根本没有时间去写详尽的文档.
换个角度,假设有一个项目的文档齐全甚至是完美,任何人看一眼就能立刻理解系统的计划的架构层次,功能结构那么这样的项目又能为软件的复用提供多大帮助呢?项目仅仅是项目,从软件复用的角度去看,做项目级别的软件复用本身就是不妥当的.项目中包含了太多和业务需求的耦合.这种耦合在复用过程中会侵蚀到系统的每一个角落.
可见,问题的本质在于软件重用的粒度和方法.
基于以上对问题的分析,我们发现我们似乎是需要一个类似普元EOS的面向构件开发平台,任何复用都面向构件.但是相信包括我在内的大多数热爱技术的开发人员都不会喜欢这样封装了太多底层细节的开发平台.而且从技术细节来说EOS采用XML总线而带来的性能损耗也被牛人们所不齿.可是自行开发一个这样类似平台的成本又巨大,技术复杂度也极高.显然是不能接受的.
所以改进建议只能从如下几个方面提出
1,加强知识积累
2,提高文档质量
3,提供开发库
提供工具级别的复用.开发库中提供细微粒度的工具包,例如链接池,mail工具包,报表工具包,ftp工具包,excel文件操作工具包,图表生成工具包,常用javascript组件等等.通过平时项目的经验积累来更新开发库,也可以有专人开发/维护和推广.
文章写到这里就结束了,可是又觉得仅仅采用工具级别的复用并不能针对问题的本质,有点指标不治本的感觉.真正合适的复用粒度到底应该如何把握?这仍然是一个需要认真考虑的问题......