问题描述

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

I know that there are already Questions about VB6 migration, but the code base of my project brings some new questions here.

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

I have to say the Code quality, structure and architecture is just a nightmare. There are 2 Big Projects: Nr.1 with 40 Forms, 40 Modules and a few class files, this EXE is kind of a "base system". Nr.2 with 80 Forms, 20 Modules and a few class files again, this EXE calls functions form the "base system". Then there are ~10 other Projects with GUI (1-3 Forms each) and another 90 non-GUI Projects, most of them EXE Files, some DLLs. The DLLs are written in C, C++ and VB6.

代码自 10 年以来不断发展，并且一次主要由 1 个(糟糕的)开发人员编写.

The Code has grown evolutionary since 10 years, and written mostly by 1 (bad) developer at a time.

• 500 行(甚至更多)的函数非常常见.
• 90% 的 GUI 组件被命名为 text1、command2(1)、……
• 复制和粘贴无处不在 e.G.复制了一个包含 5000 行代码的 EXE 项目(没有 GUI)，副本中唯一的变化是每个邮件而不是 FTP 发送文件(同一项目还有 2 个另外的副本).
• 我曾经有一个小表单(15 个字段)，我应该在其中解决一个小问题(通常最多半小时)，每次我更改某些内容时，它要么不起作用，要么在形式.2 天后，我决定彻底重写表格，从旧表格中的约 20 条 SQL 语句中，只有 2 条在新表格中幸存下来.
• 甚至不要询问代码中的注释……

几个月前我接手了这个项目，我是唯一的维护者.变更请求和错误持续(但很少)流，我们从客户那里获得维护预算，以保持软件运行并根据法律要求保持最新".

I took over the project a few months ago and I'm the only maintainer. There is a constant, (but low) flow of Change Requests and errors and we get a maintenance budget from our customers to keep the software running and "up to date" in terms of legal requirements.

我的选项

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

1) Rewrite from scratch - In that case I could write it in Java for portability. The problem here is that besides some (old) user help, there is no documentation, so the ugly code is the "documentation". There is one Person who has the high level know how what the software should do. Also it's hard to convince management about doing it, even if there are huge cost savings in the long term, there are political issues. I also can't do that one (vb) project at a time because the database structure is no better than the code i.e. has to done from scratch too. So I can only change the whole software at once.

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

2) Migrate the code to VB.NET / C# Migration of the main Projects first, I tested that already and got ~2000 upgrade comments from Project Nr.1, most of them things like Screen.MousePointer changed, functions with variant return values and so on. My Idea here is after the convert, create classes for DB abstraction, change the code to use these classes and do refactoring, migrate and change the other projects too and when all the code uses the DB classes, change the DB structure.

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

3) Refactor the code in VB6 whenever I have to change something there anyway (I'm already doing this partly) and at some point refactor also the rest. That way it's more easy to see the original functionality, because it's original code and when there are errors, it's obvious that they can't be results of the migration. When the code is refactored (I assume it will be 50-75% smaller then also) it's easier to migrate it to .NET. Then change DB structure (and then do another round of refactoring…).

将来会有一些更大的更改(使其与 Win7 兼容，以及影响大部分代码的另一个大 CR)，所以会有一个很好的机会来做这些更改，我将有无论如何都要通过很多代码.

There are some bigger changes to do in the future (make it compatible with Win7, and another big CR which affects big parts of the code), so there would be a good opportunity to do these changes, as I'll have to go through lot's of the code anyway.

我的问题是谁有迁移糟糕、丑陋的代码的经验/提示?您会建议哪些选项?

My Question is who has experience / hints for migrating bad, ugly code? Which options would you suggest?

推荐答案

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

I had to go through the same thing (Massive VB6 app with no documentation and horrible code.). The only safe and reasonable route you can take is number 3. To improve something you must first understand it. If you take route 1 or 2 you are guaranteed to be left with a horrible mess.

请记住始终牢记您的最终目标是完全迁移到 .NET.在重构时，请考虑 VB6 糟糕的 OO 支持在 VB.NET 或 C# 中的样子.如果可能的话，改变你的代码以使迁移更容易.

Remember to always keep the idea in the back of your mind that your end goal is a full migration to .NET. As you are refactoring think about how VB6s awful OO support will look like in VB.NET or C#. If possible shift your code around to make the migration easier.

您可能需要考虑将许多核心功能转移到 .NET DLL 中，并通过 COM 将其公开给 VB6.这将从您的 VB6 中删除大量可笑的代码，并有望留下大部分业务逻辑.

You may want to consider shifting a lot of your core functionality into a .NET DLL and exposing it to VB6 through COM. This will remove a ridiculous amount of code from your VB6 and will hopefully leave mostly business logic.

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

The most important thing you need to remember is don't be a cowboy.

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

这篇关于如何将丑陋且未记录的 VB6 代码迁移到 .NET的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持编程学习网！