程序结构改造,长远之计,但是困难重重,试问路在何方? (300分)

  • 主题发起人 主题发起人 小黄鱼
  • 开始时间 开始时间
对系统了解的员工继续对原系统进行维护,
其它的人重新开发
 
代码原来的不是都有了,重写只要规划一下,到时候只是复制代码的工作,应该可以的。
 
问一下,你们公司的架构设计能力如何?——如果不是非常自信的话(我是指技术经理一
级的骨干的态度,而不是Coder),我建议打补丁。如果很自信,那就可以动手大干一番,
不过,提醒一句,VB不能继承的,建议用更加合适的开发工具。
 
重新设计,重新规划吧,
我觉得这是迟早一定要做的事
 
我现在和你的现象很相似。我将这样做:
1.保持原有的正常运行。
2.吸取原系统精华,构划新产品。
3.重写新系统。
4.渐渐取代老系统。
 
我赞同zhaogh_2171的说法。
 
我觉得贵公司在做这个产品的时候缺乏长远的计划。
公司开发这个项目,要得到什么?包括近期的目标和远期的目标。
要得到当前用户的钱,这是近期目标,但是以后呢?公司应该还想得到更多用户的钱。
怎样才能得到更多用户的钱呢?那就是这个产品不停地优化改变,
也就是说,这个产品的开发时一直在进行的,是随时都在更新。
那么现在这些用户得到的软件产品只不过是在公司开发这个产品的过程中的某一个版本而已。对于这个提供给用户的版本,公司应该派出一部分人维护,而不应该停止整个项目的开发。
现在好像这些公司都是开发完了就是维护,但实际上,开发的工作是永远都不应该结束的。
 
先做好 配置管理,避免代码版本混乱。
然后看看 《重构》
以后的就看运气了。
 
楼主提了一个很好的问题,希望有前辈高人来指点,也可以让我们长点见识。
 
原来的版本继续维护,但暂时不做重大改动。
同时,组建一个二人或三人的攻关小组,对原软件进行改造,1000万的项目,估计不用花50万就可以完成
改造,因为你的业务需求、界面及用户喜好等许多耗费成本的因素都已经基本不存在了,可以闭门造车了,这
种纯技术上的改造成本应该是比较低的。
 
不应该重写
这样错误比较多
还是分两步走
第一步,将原有系统逐步模块化
第二步,再将模块化的系统逐步类化
最后全面规划设计处理
 

Similar threads

S
回复
0
查看
3K
SUNSTONE的Delphi笔记
S
S
回复
0
查看
2K
SUNSTONE的Delphi笔记
S
D
回复
0
查看
1K
DelphiTeacher的专栏
D
I
回复
0
查看
599
import
I
I
回复
0
查看
979
import
I
后退
顶部