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

Question

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

主要原因是：

• 我们希望VB6运行时支持在某个时间点结束，我们不想在那时开始迁移，因为它可能会是一个漫长的过程。
• 只剩下1 1/2个VB6开发者。一半是我。
• 越来越多的客户要求提供云和移动设备支持等功能。

我知道从头开始重写应用程序是迁移到.Net的最不推荐的方法。我完全赞同这一点！抛弃十多年的代码感觉是错误的，浪费金钱，我很难向我们的管理层推荐和证明它。

但是现在我没有看到另一种方法。

让我告诉你一些关于申请的内容：

就像我说它已经发展了十多年。已经有很多开发人员在开展这项工作，其中大多数都是当时没有经验的。我们从最初的团队中留下了一名开发人员。该应用程序是他的第一个也是最大的软件项目，到目前为止，他意识到过去15年中做出的许多架构决策都是错误的，其他人当时是正确的，但没有进行重构以满足其他部分的变更。应用程序等在某个时间点变得错误。此应用程序似乎是代码腐烂的展示示例。

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

向应用程序添加新功能仍然可以完成，但与其他.Net应用程序相比需要很长时间。原因是代码库中的每一个小变化都需要在整个地方进行更改。改变是可能的唯一原因是因为一个开发人员只知道应用程序的大部分依赖性和怪癖。你可能已经猜到了意想不到的副作用和错误率非常高。

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

但是我看到了一些问题：

1. 似乎没有办法重构旧的应用程序。没有任何自动化测试，甚至没有正式的手动测试方法。每一个小小的变化都需要经验丰富的用户进行手动测
   • 另一方面，我已经建立了一个流程和一套工具来测试我们的.Net应用程序，这为我们提供了重构的坚实基础
2. 将代码转换为.Net而不进行重大修改感觉就像：垃圾进入，垃​​圾进出。尽管我讨厌调用旧的应用程序垃圾，因为它以某种方式工作并证明它本身很有用。
3. 我们的管理层习惯明确要求​​快速和肮脏的解决方案，无视其对生产力的影响，并反对开发团队的所有建议，这些建议在某些时候开始否认存在快速和肮脏的解决方案，以便能够做正确的事。这并不意味着我们改进功能，但我们确实包括编写测试的时间并在我们的估算中进行重构。所以知道这一点，我怀疑一旦代码转换为.Net并修复到应用程序启动并且似乎有效的程度，重构阶段将被取消，应用程序将被发送给一些客户。

因此。我认为，尽管从头开始重写需要花费大量的时间和资源，但它仍然是我们唯一的选择。

我错过了一个选项吗？您是否看到不必重写该应用程序的可能性？

Answer 1

我建议您退后一步，阅读Brian Foote＆amp; Joseph Yoder（伊利诺伊大学）。它提供了一些建筑洞察力，可以解决您遇到的问题以及解决问题的方法。它的标题是“泥球大球”。 （请不要笑，这是一篇严肃的论文）。这是摘要：

  

虽然很多注意力集中在高级软件上   建筑模式，实际上是事实上的标准   软件架构很少被讨论。本文考察了   最经常部署的架构：MIG BALL OF MUD。一个大球   OF MUD是一个随意的，甚至是偶然的，结构化的系统。它的   组织，如果可以称之为，则更多地由权宜之计决定   而不是设计。然而，它的持久受欢迎程度不仅仅是指示性的   一般无视建筑。

     

这些模式探索了鼓励a的出现的力量   MUD的大球，以及这种方法的无可否认的有效性   软件架构。为了变得如此受欢迎，它必须这样做   对的东西。如果有更高尚的建筑方法   竞争，我们必须了解导致BIG BALL OF的力量   MUD是，并研究解决它们的替代方法。

     

BIG BALL OF MUD出现了许多其他模式。我们   依次讨论它们。这些模式背后有两个主要问题：   为什么这么多现有系统在架构上没有区别，并且   我们可以做些什么来改善它们？

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

Answer 2

当您拥有这样的应用程序时，有四个主要选项：

• 什么都不做：这总是一个选择，因为每个人都知道，如果没有破坏，就不要修理它。但是，由于某些原因，例如需要遵守公司的某些安全要求，或者仅仅因为其中一个组件在新平台中不起作用，这可能不是一种选择。
• 重写：这将是梦想，对吧？能够摆脱所有不良做法和重复代码等等？好吧，可能就是这样，但是你必须考虑从头开始开发新应用程序所涉及的所有风险。你有所有的正式要求吗？测试用例怎么样？你的团队是否知道代码中的每一个细节，或者你需要一行一行地试图弄清楚为什么会这样？此外，还有多少错误
• 购买现成品：由于您是ISV，因此不能选择。
• 迁移：当然，您将受到用于原始开发的编程实践的约束，但您将更快地进入新平台，所有业务逻辑将自动迁移，您实际上可以雇用开发人员平台，你可以摆脱遗留元素。从这里您还可以利用所有可用的工具来重构代码，持续集成，单元​​测试等。

此外，通过自动迁移，您实际上可以比WinForms更进一步。还有一些工具可以使用现代架构将您的C＃代码一直带到Web上。

当然，我为Mobilize.Net（以前的Artinsoft）工作，这是我的偏见。 我们已经在这方面工作了大约15年，并且已经看到过几十个客户在尝试重新编写他们的应用程序之后来找我们，并且经过数月甚至数年的努力而无法提供有效的应用程序而失败。