这是"十分之一"的时间重写吗?

Rew*_*tor 13 .net vb6 rewrite

如果可以避免,我非常反对重写应用程序.我理解10次中9次的规则,重构更好,但是我可能是10次中的一次,而我正在寻找那条线.

目前的情况是:

  • 我接手了VB6/SQL应用程序的维护.
  • 代码总行数为75-100k(代码隐藏,模块和类).
  • 最初的开发人员离开了,所以这只是我,并且没有机会扩展团队,至少在几年内.
  • 程序没有架构(只是在代码隐藏形式的纯文本中直接进行SQL调用).
  • 不试图遵循DRY或OAOO原则.
  • 数据库有一些主键,但没有外键.
  • 在这个系统到位之前,所有东西都是用大型电子表格管理的,所以这个系统确实比他们拥有的东西有了很大的改进,但却没有做到他们想象的那样.
  • 我能够自己编写一些工具来用常量和查找替换表名和列名的所有文字实例,并且我编写了一个快速代码生成脚本来从数据库中生成这些常量和查找,所以现在我可以安全地进行数据库更改并查看破坏的所有地方 我已经开始将数据库"边缘化"规范化,但它就像3%的方式.
  • 没有单元测试,所以每次我更改数据库时,我基本上都要重写其上的任何逻辑,我使用这两个版本来比较功能并确保它们是相同的.到现在为止还挺好.
  • 我开始只是试图修复关键的错误来阻止流血,我可以肯定地说,这大部分已经完成了,所以现在我踩了一会儿来看看大局.
  • 管理层对他们的期望是支持和合理的.
  • 长期目标是将其转换为.NET无论如何......

所以,我正在权衡这些选择:

  1. 继续规范化数据库并在我去的时候修改VB6应用程序(最终是一块一块地重写)
  2. 将VB6置于仅维护状态(无新功能),一次选择一个功能模块,并在规范化数据库结构之上重写.NET中的该部分.

我的想法是,如果我选择选项1,那么最后我只有一个VB6应用程序,他们仍然想要升级到.NET,我已经研究过它,这是昂贵和耗时的,甚至使用你的工具我还会得到一些有点像弗兰肯斯坦的东西.如果我选择选项2,我相信我可以尽快完成,我会直接跳到目标技术.

在我的规范化过程中我已经重写的小规模部分中,结果是已经存在的改进模块,因此在重写期间会添加值.

现有的应用程序,除了它的所有缺陷,是一个很好的讨论点.使用它的人可以告诉我什么对他们起作用,什么不起作用,所以那里肯定有很多价值.

那么,这是否有资格成为"十分之一"时间之一?

tay*_*onr 14

我有一个最初用VB6编写的项目,他们雇用我将其转换为.NET.我最近离开了这份工作.我相信该程序可能不应该被重写.

如果采用重写方法(基于我的项目),需要考虑以下因素

  • 它不会是一个直接重写.一旦消息传出,重新编写的新功能请求将会弹出,并且会有相当多的重新设计/重新设计
  • 人们不会接受"仅维护"模式而首先会遇到很多阻力.有一段时间,每个bug都将是"关键任务"
  • 将VB6应用程序移植到.Net不应该被视为比将C++应用程序移植到.Net或将Haskell项目移植到.Net更容易.有一些共性,但最终,它是99%不同的代码库(现有方程式可能为1%)
  • 假设这个程序正在生产(甚至在内部),你的新程序很可能不会起作用,至少在最初阶段.你会听到"但是以旧方式......"或"它曾经......"
  • 假设您的客户不是其他IT人员,他们将无法理解:
    • 花了这么长时间
    • 为什么它不像旧的程序(外观和感觉)
  • 虽然当前的应用程序是随着时间的推移而开发的,但预计您的应用程序将在上线时以及在更短的时间内拥有100%的功能.

这些都是从VB6到.Net的真实生活迁移的经验.我是唯一的.Net开发人员.没有资源可以雇用额外的帮助.我的情况和你的情况之间的主要区别是1.最初的开发人员仍然存在 - 只是在一个新的角色(有时更难)和2.原始的应用程序不需要很多错误修复.

我想如果我再做一遍,我会尝试创建一些.NET dll并将它们合并到VB6应用程序中.逐件转换为.net.因此,您可能会将应收帐款的数据和业务逻辑移至.NET.所有其他方面保持不变.GUI,其他功能等.然后在推出并标记为完成之后,接受Shipping部分并执行相同的操作.最后一步是创建一个使用您的DLL的新.NET GUI.

这给你带来了一些好处

  • 最后,应用程序是用.NET编写的
  • 允许您慢慢推出更改.您将不会在"上线"的同一周同时调试运输和应收账款以及人力资源等
  • 允许您使用更多现代工具而不会破坏整个程序.想使用NHibernate,PLINQ还是MEF?一次做一个模块.学习该工具并采取小步骤
  • 允许GUI的灵活性.最后,你可以使用你的核心DLL来做WinForms,WPF或Web项目.
  • 不会一次性对用户进行大量更改.您已经重写了应收帐款部分并且用户没有任何线索,因为GUI是相同的.然后,当您推出GUI时,您知道您的后端正在运行.
  • 将使未来的重构更容易.您已经将项目分解为一口大小的块.你可以进一步了解他们的影响等等.

我非常厌倦决定作为一名开发人员重新编写这个应用程序并为他们提供一个可用的产品.我认为保守估计(假设没有范围蔓延等)将是24个月.可能更有可能是3 - 4年.

我离开的项目已经工作了3年并且是可以维修的,但还不是原始应用程序的100%替代品.就像我说的那样......虽然这意味着我没有工作,但我认为不应该重写.

  • +1,好的,有点长,但很好说,你看到我在其他VB6 - > .NET项目中看到的东西.一些优点. (2认同)
  • +1.官方[微软英国的建议](http://msdn.microsoft.com/en-gb/dd408373.aspx)是他们只建议在VB.Net中从头开始重写VB6代码以适应少数情况.有更好的选择,例如使用商业工具进行自动迁移,或逐个模块地逐步替换. (2认同)

Art*_*old 5

在我们一次完成应用程序和数据库的项目中,我建议首先尝试使数据库正确,然后再执行应用程序.

试图同时做这两件事可能会非常痛苦.但是,如果没有在您旁边查看代码,那么肯定很难说.

我总是觉得如果你拥有数据库并且你可以依赖它,你应该能够使用集成测试重写,然后更可靠地进行单元测试.

一旦你拥有了数据库,我认为最好的情况是尝试将代码模块化为单独的和可重用的程序集(你应该可以在.NET中使用),然后逐渐将这些程序从VB中移植到.NET中.如果代码是可怕的意大利面条,这可能是不可能的!

  • 最好先处理最简单,最简单的事情.直接介绍常数.还可以将任何内联sql输出到存储过程中的数据库(或使用存储库模式来提高开发速度).另外,不要害怕编写许多可以测试和命名的方法来帮助你理智.听起来你需要阅读:http://www.amazon.co.uk/Working-Effectively-Legacy-Robert-Martin/dp/0131177052/ref=sr_1_1?s=books&ie=UTF8&qid=1282665779&sr=1-1完整重写可能仍然是必要的,但如果你能做到这一点,这是一个很好的重构路线图...... (2认同)

Sel*_*t0r 0

无论如何,长期目标是将其转换为.NET......

听起来您只需维护旧代码,直到将其移植到 .NET 为止。因此,保留一些工作并从今天开始重写。我的2分钱。

确保在重写时仍然可以使用现有的应用程序,因为听起来这不可能在一两天内完成。“仅维护”状态对我来说听起来是个好主意。