如何在迁移到.NET时避免从头开始重写VB6

Question

在我们公司，我们开发和销售一个VB6应用程序，我们认为现在是时候将其迁移到.NET了。

主要原因如下：

- 我们预计VB6运行时支持在某个时间点结束，并且我们不想在那时才开始迁移，因为这可能是一个漫长的过程。 - 只剩下1 1/2个VB6开发人员。其中半个是我。 - 越来越多的客户要求支持云和移动设备等功能。

我知道从头开始重写一个应用程序是迁移到.NET最不推荐的方法。我完全同意！抛弃十多年的代码感觉很不对，而且会浪费已经花费的大量资金，我很难向我们的管理层推荐和证明这种做法。

但是现在我看不到其他方法了。

让我稍微介绍一下这个应用程序：

正如我所说，它已经开发了十多年。有无数的开发人员在上面工作过，他们中的大多数当时都没有经验。我们留下了一名最初团队的开发人员。这个应用程序是他的第一个和最大的软件项目，到现在为止，他意识到在过去15年中做出的许多架构决策都是非常错误的，其他一些决策在当时是正确的，但是没有被重构以满足应用程序其他部分所做出的更改，因此在某个时间点变得错误了。这个应用程序似乎是代码腐烂的一个典型例子。

我们正在谈论一个大约有150 KSLOC的应用程序，全部都在一个单一的可执行文件中。它使用了大约15个外部DLL，其中一些是第三方ActiveX控件，另一些是我们自己的.NET程序集。

向应用程序添加新功能仍然是可能的，并且正在进行，但与我们的其他.NET应用程序相比，需要花费很长时间。原因是代码库中的每个小变化都需要在各个地方进行更改。唯一能够进行更改的原因是那位开发人员简单地知道应用程序的大多数依赖项和怪癖。正如你可能已经猜到的那样，意外副作用和错误的发生率相当高。

我对迁移该应用程序的第一个想法是首先清理和重构，然后使用Artinsoft/Microsoft/WhoEver的工具进行迁移/转换，然后再次进行重构，以获得一个漂亮而干净的.NET应用程序。

但我看到了一些问题：

- 似乎没有重构旧应用程序的方法。没有任何自动化测试，甚至没有正式的手动测试方法。每个小变化都需要有经验的用户进行手动测试，他们知道缺陷可能隐藏在哪里。 - 另一方面，我已经建立了一套用于测试我们.NET应用程序的流程和工具，这为我们进行重构提供了坚实的基础。

2. 在不进行重大重构的情况下将该代码转换为.NET感觉就像垃圾进，垃圾出。即使我不喜欢称旧应用程序为垃圾，因为它以某种方式工作并证明自己有用。
3. 我们的管理层习惯于明确要求快速且不太规范的解决方案，而忽略其对生产力的影响，而且这与开发团队的所有建议相违背。开发团队曾经开始否认快速且不太规范的解决方案的存在，以便能够做正确的事情。这并不意味着我们要完善功能，但我们会在估计时间时包括编写测试和进行重构的时间。因此，知道这一点后，我怀疑一旦代码转换为.NET并修复到应用程序启动并似乎工作的程度，重构阶段将被取消，并且应用程序将被交付给某些客户。

所以。我认为，尽管从头开始重写需要很多时间和资源，但这仍然可能是我们唯一的选择。

我是否缺少了其他选项？您看到不必重写该应用程序的可能性吗？

- Gooo

---

考虑到VB6非常古老且笨重（正如您在首次提出动机时所述），而VB.NET实际上只是具有不同语法的C# .NET，我认为答案是您不想要的；也就是说，它不存在。我认为最好的方法是逐个文件地进行“重新编写”，并使用C#等效物逐个替换每个“sub”和“module”。 - Martin Costello

@martin_costello 我强烈建议不要盲目复制；即使没有现有的有机设计，VB6和.NET之间仍然存在许多隐喻和范式的差异。我不想这么说，但实际上我希望最终能够得到一个体面可管理的代码库，而不仅仅是迁移来的无人真正理解的垃圾代码。这意味着：要做好它。 - Marc Gravell

@Gooo，我建议你尝试识别出旧代码中可用的功能单元，并尝试将其逐个移植到.NET平台上以制作一个最小可行产品。请注意，可以使用COM互操作作为过渡设备来实现双向转换，但是：这种方法有点不稳定且麻烦。 - Marc Gravell

我们正在将一个1993年开始开发的C/C++/MFC应用程序完全重写为C#和WPF/XAML/MVVM。这样做不会让人感到“不对劲”，因为我们正在为用户界面增加了无与伦比的方便性和丰富性。 - Federico Berasategui

我有一个15年的系统（从VB3 -> 4 -> 6开始），它也发展成了一个庞大的东西，但并不是很难。不要复制转换，而是设计如何重新/实现旧功能（即继承等），以及任何初始新内容（云等）。升级过时的内容，但保留好的部分。例如，不要浪费时间尝试做控件数组。同样，放弃数组而选择列表等事情也是如此。目标之一必须是为长期发展开发具有概念完整性的新代码库。 - Ňɏssa Pøngjǣrdenlarp

Answer 1

我建议你退后一步，阅读伊利诺伊大学的布赖恩·富特和约瑟夫·约德（Brian Foote & Joseph Yoder）所写的这篇论文。它提供了一些关于你所面临的问题的架构洞见以及解决方案的选择。它的标题是“大泥球”（请不要笑，这是一篇严肃的论文）。以下是摘要：

尽管高级软件架构模式受到了很多关注，但实际上，事实上的标准软件架构很少被讨论。本文研究了最常见的架构：BIG BALL OF MUD。 BIG BALL OF MUD是一个随意、甚至是杂乱无章的结构系统。它的组织方式更多地是出于方便而不是设计。然而，它的持久流行显然不能仅仅表明人们对架构的普遍漠视。这些模式探讨了促使BIG BALL OF MUD出现的力量以及这种方法在软件架构中的 undeniable effectiveness。为了变得如此流行，它必须做对了一些事情。如果更高级的架构方法要竞争，我们必须了解导致BIG BALL OF MUD出现的力量，并检查解决它们的替代方法。许多额外的模式出现在BIG BALL OF MUD之外。我们依次讨论它们。这些模式有两个主要问题：为什么那么多现有的系统在架构上没有特色，我们可以做些什么来改善它们？

顺便说一下，我认为你最好的选择是使用当前应用程序作为你的需求，并使用适当的设计在VB.NET或C#中重新编写所有内容。

- Wagner DosAnjos

---

不错的论文！它解决了我所描述的许多问题，并提出了我们在其他项目中使用的方法。我们通过采用一些XP、一点Scrum和大量相互交流的方式，以小步骤演进我们的应用程序，始终保持着工作状态。 - Gooo

@wdosanjos：（对于Big Ball of Mud表示赞同）。但是我不太喜欢你的建议。这是经验之声吗？你从零开始成功编写了多少个系统？http://www.joelonsoftware.com/articles/fog0000000069.html - Ira Baxter

Answer 2

当你有这样一个应用程序时，有四个主要选项：

• 什么都不做：这总是一个选择，众所周知，如果它不坏，就不用修。然而，由于需要遵守公司的某些安全要求，或者因为其中某个组件在新平台上无法工作，这可能不是一个选项。
• 重写：这将是梦想，对吧？能够摆脱所有不良实践、重复的代码等等？嗯，也许确实如此，但是您必须考虑从头开始开发新应用程序所涉及的所有风险。您是否拥有所有正式要求？测试案例呢？您的团队是否了解代码中的每个细节，还是需要一行一行地去找出那个“if”语句为什么会在那里？此外，您的代码中有多少错误？
• 购买现成的产品：既然您是ISV，这不是一个选项。
• 迁移：当然，您将受制于原始开发中使用的编程实践，但是您将更快地到达新平台，所有业务逻辑将自动迁移，您可以为新平台雇用开发人员，并且您可以摆脱遗留元素。从这里开始，您还可以利用所有可用的工具来重构代码、持续集成、单元测试等。

此外，通过自动迁移，您实际上可以超越WinForms。还有一些工具可以使用现代架构将您的C＃代码全部转换为Web应用程序。

当然，我是Mobilize.Net（之前是Artinsoft）的员工，这是我的偏见观点。我们已经从事这项工作约15年，并见过数十个客户，在试图重新编写其应用程序并在数月甚至数年的努力后失败，无法交付可工作的应用程序后来向我们寻求帮助。

- willvv

---

就我所知，Artinsoft（或者他们现在是谁）已经做了很长时间的这个。虽然我没有使用过他们的工具或服务，但我尊重他们所取得的成就。 - Ira Baxter