目前的情况是：
>我接管了VB6 / sql应用程序的维护.
总代码总数为75-100k(代码后缀,模块和类).
>原来的开发人员离开了,所以只是我,没有机会扩大团队,至少在几年之内.
>程序没有体系结构(只是简单的直接sql调用,以代码隐藏的形式).
>不试图遵循DRY或OAOO原则.
>数据库有一些主键,但没有外键.
>在这个系统到位之前,一切都是用大型电子表格进行管理的,所以这个系统真的是一个巨大的改进,而不是做他们想像的.
>我能够自己写一些工具来替换表名和列名称的常量和查找的所有文字实例,并且我写了一个快速的代码生成脚本来生成数据库中的常量和查找,所以现在我可以安全地使数据库发生变化,看到破裂的地方.我已经开始使数据库“围绕边缘”进行归一化,但是它就像3％的方式.
>没有单元测试,所以每次我更改数据库时,我基本上都必须重写任何逻辑,我使用这两个版本来比较功能,并确保它是一样的.到现在为止还挺好.
>我刚开始尝试修复严重的错误来阻止出血,我可以放心地说这大部分都是完成的,所以现在我回过头来看一下大图.
>管理是他们期望的支持和合理的.
>长期目标是将其转换为.NET …
所以,我正在衡量这些选项：
>继续规范化数据库并修改VB6应用程序(最终成为一块一块重写)
>将VB6放入维护状态(无新功能),一次选择一个功能模块,并在规范化数据库结构之上重写.NET中的该部分.
我的想法是,如果我选择选项1,那么最后我只是有一个VB6应用程序,他们仍然想升级到.NET,我已经研究了它,这是昂贵和耗时的,甚至与工具你仍然会得到一些有点像弗兰肯斯坦的东西.如果我选择2,我相信我可以尽快完成,我会跳到目标技术上.
在我在规范化过程中已经重写的小规模部分中,结果是已经有了一个改进的模块,所以在重写期间增加了值.
现有的应用程序,其所有缺陷,是一个很好的讨论点.使用它的人可以告诉我什么是为他们工作,什么不是,所以这里肯定有很多价值.
那么,这是否符合“十分之一”的要求呢？
如果您采用重写方式(基于我的项目),这里有一些要考虑的因素
>这不会是一个直接的重写.一旦字出来,它将重新编写新的功能请求将弹出,并将有大量的重新设计/重新架构
>人们不会接受“维修专用”模式,首先出现很多阻力.有一段时间,每一个bug都将是“关键任务”
>将VB6应用程序移植到.Net不应该被视为比将C应用程序移植到.Net或Haskell项目到.Net更容易.有一些共同点,但最终,它是99％不同的代码库(现有方程可能为1％)
>假设这个程序正在生产(甚至在内部),你的新程序很可能不会在最初初步测出.你会听到“但是在旧的方式…”或“它曾经…”
假设您的客户不是其他IT人员,他们不会明白：
什么是这么长时间？
>为什么它不像旧的程序(外观和感觉)
>虽然当前的应用程序是随着时间的推移而开发的,但可能预计您的应用程序将具有100％的上线功能,并且在较短的时间内.
这些都是从VB6到.Net的现实生活迁移的经验.我是唯一的.Net开发人员.没有资源可以雇用额外的帮助.我的情况和你的主要区别是1.原来的开发人员还在 – 只是一个新的角色(使得更难的时候)和2.原来的应用程序不需要很多错误修复.
我想如果我再做一遍,我会尝试创建一些.NET DLL,并将它们并入VB6应用程序.逐件转换为.net.所以也许你将应收帐款的数据和业务逻辑移动到.NET.所有其他方面保持不变. GUI,其他功能等.然后,它被推出并标记为完整,接受运送部分并做同样的事情.最后一步是创建一个使用您的DLL的新的.NET GUI.
这给了你几个好处
>最后应用程序是用.NET编写的
>允许您慢慢推出您的更改.您不会在“上线”一周的同一时间调试运输和应收帐款和小时等
>允许您使用更多的现代工具,而不会破坏整个程序.想要使用NHibernate,PLINQ还是MEF？一次做一个模块.学习该工具并制作小步骤
>允许GUI上的灵活性.最后,您可以使用WinForms,WPF或Web项目,全部使用您的核心DLL.
>不要一次在用户身上大量的更改.您已经重新编写了应收账款部分,用户没有任何线索,因为GUI是相同的.然后当您推出GUI时,您知道您的后端正在运行.
>将使未来的重构更容易.你已经将你的项目分解成了大小大小的块.你可以进一步了解他们对他们的影响等等.
作为一个开发人员决定重新编写这个应用程序并提供一个工作的产品,我将非常疲倦.我认为保守估计(假设没有范围蠕变等)将是24个月.可能更有可能3-4年.
我离开的项目已经工作了3年,服务良好,但原来的应用程序还没有100％的替代品.就像我说的,即使这意味着我没有工作,我也不认为应该重写.