如何将丑陋和未记录的VB6代码迁移到.NET

Question

我知道已经有关于VB6迁移的问题,但是我的项目的代码库带来了一些新的问题.

我不得不说代码质量,结构和架构只是一场噩梦.有两个大项目:Nr.1有40个表格,40个模块和一些类文件,这个EXE是一种"基础系统".Nr.2有80个表格,20个模块和几个类文件,这个EXE调用函数形成"基本系统".然后还有大约10个带GUI的项目(每个1-3个表单)和另外90个非GUI项目,其中大多数是EXE文件,一些是DLL.DLL用C,C++和VB6编写.

该守则自10年以来逐渐发展,并且一次由1个(坏)开发人员编写.

• 500行(及更多)的功能非常常见.
• 90%的GUI组件被命名为text1,command2(1),...
• 复制和粘贴到处都是例如一个EXE项目(没有GUI),复制了5000行代码,副本中唯一的变化是每个Mail而不是FTP发送文件(同样项目的另外2个副本也是).
• 我曾经有一个小形式(15个字段),在那里我应该解决一个小问题(通常最多半小时的事情),每次我改变一些东西,它要么不起作用,要么在表格中产生新的错误.2天之后,我决定完全重写表单,从旧表单中的~20个SQL语句中,只有2个在新表单中存活.
• 甚至不询问代码中的评论......

几个月前我接手了这个项目,我是唯一的维护者.变更请求和错误的流量不断(但很低),我们从客户处获得维护预算,以保持软件运行并在法律要求方面"更新".

我的选择

1)从头开始重写 - 在这种情况下,我可以用Java编写它以实现可移植性.这里的问题是,除了一些(旧)用户帮助,没有文档,所以丑陋的代码是"文档".有一个人具有高级别知道该软件应该如何做.此外,很难说服管理层这样做,即使长期存在巨大的成本节约,也存在政治问题.我也不能一次做那个(vb)项目,因为数据库结构并不比代码好,即必须从头开始.所以我只能一次更改整个软件.

2)将代码迁移到VB.NET/C#主要项目的迁移首先,我测试了已经从Project Nr.1获得~2000升级注释,其中大部分内容如Screen.MousePointer更改,函数具有变量返回值和等等.我的想法是在转换之后,创建用于数据库抽象的类,更改代码以使用这些类,并进行重构,迁移和更改其他项目,当所有代码使用数据库类时,更改数据库结构.

3)每当我必须在那里改变一些东西时重构VB6中的代码(我已经部分地做了这个)并且在某些时候重构了其余部分.这样就可以更容易地看到原始功能,因为它是原始代码,当出现错误时,很明显它们不能成为迁移的结果.当代码被重构时(我假设它也会小50-75%),将它迁移到.NET更容易.然后改变DB结构(然后进行另一轮重构......).

将来会有一些更大的变化(使它与Win7兼容,以及影响代码大部分的另一个大CR),因此我将不得不通过这些变更进行这些更改.无论如何,很多代码.

我的问题是谁有移植糟糕,丑陋代码的经验/提示？你会建议哪些选择？

Answer 1

我不得不经历同样的事情(Massive VB6应用程序,没有文档和可怕的代码.).您可以采取的唯一安全合理的路线是3号.要改进某些东西,您必须先了解它.如果你选择1号或2号路线,你可能会遇到一个可怕的混乱局面.

请记住始终牢记这一想法,即您的最终目标是完全迁移到.NET.正如你在重构时想一想VB6在VB.NET或C#中的支持是多么糟糕.如果可能的话,可以移动代码以简化迁移.

您可能需要考虑将大量核心功能转换为.NET DLL并通过COM将其暴露给VB6.这将从您的VB6中删除大量的代码,并希望主要留下业务逻辑.

你需要记住的最重要的事情就是不要成为牛仔.

1. 编写模块测试.
2. 重构一个模块.
3. 测试模块.
4. 发布您的应用.
5. GOTO 1

Answer 2

代码是否绝对必须迁移？如果没有,仍然是为了它的目的,并且是一半可维护的,只是不管它并继续前进.

将代码转换为新语言的动机很快就会在无数个小时,几周和几个月的代码迁移后消失 - 特别是在您提到的规模上.

从概念上讲,代码迁移的想法是一个奇妙的想法.很可能,这是一个可怕的混乱,你会厌恶生活这样做.

想想看,在修复缺陷的同时,你是否讨厌自己的生活？ 为迁移项目估计减去100倍.

只要有效,大多数企业都可以真正关心引擎盖下的东西.请记住,他们不是开发人员,不关心修复它的痛苦程度(因为他们不是那样做)并且激励企业花费数万美元带来代码是最新的,根本没有任何商业意义.

Answer 3

经验丰富的类似迁移14年代码到VS2008

以下是一些提示:

1. 删除第三方组件的依赖关系.
2. 考虑分阶段迁移,例如使用反向互操作.
3. 颜色和字体需要手工处理.
4. 迁移到.NET后,请注意数组中未初始化的对象
5. 更改错误以尝试捕获
6. 在需要的地方使用Microsoft.VisualBasic.Compatibility.VB6命名空间.
7. 将重构保持在最低限度,直到所有代码都转换为.NET
8. 注意VB6代码中的非零数组.
9. 在VB6中重构(最小化)代码,以便它可以通过代码转换向导.
10. 注意基于1的VB6控件,例如ListView
11. 使用synclock可以避免线程问题.
12. 如果您正在对子进行手动重构,请注意数据类型大小的更改,尤其是在使用文件IO时.

有一家公司可以帮助您完成整个过程(虽然我们没有使用它们) http://www.vbmigration.com/

Answer 4

查看M. Feathers的"有效使用遗留代码" - 它讨论了增强,重构和迁移以及未经测试的代码的缺陷.

Answer 5

你在制定这个问题上做得很好.谢谢你的询问!感谢stackoverflow社区发布深思熟虑的回复(像往常一样).

如果这是一个相当大的代码库,它听起来像是(50-100个相互关联的VBP,200-500K LOC),那么你应该考虑投资迁移工具.请考虑这个类比:如果您要转换大量数据,即使源数据很脏并且与所需格式非常不同,您也可以使用工具.如果有人建议您只是重新输入数据,或者甚至进行粗略转换然后手动修复,您会认为它们是疯子.此外,通过120种表单,应用程序听起来像是提供了相当多的业务功能.这种业务功能已经出现多年使用,无论喜欢与否,VB6代码代表了该功能的完整,正式且经过生产测试的规范,以及关于应用程序如何在幕后工作的无数技术事实."从头开始"重新收集,重新编码和重新测试所有这些功能/技术要求是非常昂贵和困难的.为了管理项目的成本和风险,您必须"兑现"遗留代码.问题是:如何做到这一点,并确保在迁移后降低拥有成本.

挑战与代码库的大小关系不大,而不是需要适应和利用.NET的重新设计细节.您需要确定使VB6代码"丑陋"代码的具体内容,为什么它"丑陋",以及如何/应该/想要在.NET中以不同方式执行这些操作.一旦开始制定这些重新设计要求,您就可以开始在转换过程中实现它们,以便它们显示在.NET代码中.我们提倡的一般方法称为" 工具辅助重写 ",其完成如下:

1. 运行翻译
2. 构建/审查/测试生成的代码以识别/优化所需的代码改进
3. 如果生成的代码"足够好",请转到.NET中的作业
4. 重新配置翻译器以实现所需的改进(如果适用)
5. 转到1

该工具的输出不需要"完美"(软件永远不会......)它只需要"足够好".步骤3中提到的"足够好"是一个关键问题.从本质上讲,它意味着代码质量 - 在验证功能正确且符合您的标准方面 - 是开发团队知道完成迁移然后继续操作/维护应用程序需要做什么 - 他们是相信他们可以在给定的时间和资源限制内做到这一点.对于一个非常大的代码库"足够好"是"非常好的",因为它试图完成并随后保持低质量的迁移太昂贵和冒险.一般来说,代码越大,预算越少,

还有一些关于"完成.NET中的工作"的想法:在.NET中使用格式良好的代码是一个重要的里程碑..NET社区提供了很好的重构,分析和单元测试工具,可以帮助您加快完成迁移的速度.您将在此过程的早期阶段使用Visual Studio来试验和优化重新设计,并调试/测试应用程序.能够在迁移工作的早期使用.NET和Visual Studio中的整个代码库是工具辅助方法的关键优势(也是关键部分).

当然,为了实现这一点,您需要能够投资专门用于支持工具辅助重写的迁移工具集.从工具大迁徙,是我此类别中知道的唯一工具.

免责声明:我为Great Migrations工作.我们网站上提供了更多信息 - 包括如何使用该工具帮助迁移超过1M的VB6重新设计C#的案例研究,以及详细描述产品和方法的gmStudio用户手册.