我知道已经有关于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名（坏）开发人员编写。
我的选项
1）从头开始重写 - 在这种情况下，我可以用Java编写它以实现可移植性。 这里的问题是，除了一些（旧）用户帮助，没有文档，所以丑陋的代码是“文档”。有一个人具有高级别知道该软件应该如何做。此外，很难说服管理层这样做，即使长期存在巨大的成本节约，也存在政治问题。我也不能一次做那个（vb）项目，因为数据库结构并不比代码好，即必须从头开始。所以我只能一次更改整个软件。
2）将代码迁移到VB.NET / C＃ 首先迁移主项目，我已经测试了并且从Project Nr.1获得了~2000升级注释，其中大部分内容如Screen.MousePointer已更改，函数具有变量返回值等等。 我的想法是在转换之后，创建用于数据库抽象的类，更改代码以使用这些类，并进行重构，迁移和更改其他项目，当所有代码使用数据库类时，更改数据库结构。
3）无论何时我必须在那里改变一些东西（我已经在部分地做了这个）并且在某些时候重构其余部分时重构VB6中的代码。这样就可以更容易地看到原始功能，因为它是原始代码，当出现错误时，很明显它们不能成为迁移的结果。 当代码被重构时（我假设它也会小50-75％），将它迁移到.NET更容易。然后更改数据库结构（然后进行另一轮重构......）。
将来会有一些更大的变化（使它与Win7兼容，以及另一个影响代码大部分的大CR），因此我将有很好的机会进行这些更改。无论如何要经历很多代码。
我的问题是谁有移植糟糕，丑陋代码的经验/提示？你会建议哪些选择？
答案 0 :(得分：19)
我不得不经历同样的事情（Massive VB6应用程序，没有文档和可怕的代码。）。您可以采取的唯一安全合理的路线是3号。要改进某些东西，您必须先了解它。如果你采取1号或2号路线，你将确保留下一个可怕的混乱。
请记住始终牢记这一想法，即您的最终目标是完全迁移到.NET。正如你在重构时想一想VB6在VB.NET或C＃中的支持是多么糟糕。如果可能的话，可以移动代码以简化迁移。
您可能需要考虑将大量核心功能转换为.NET DLL并通过COM将其暴露给VB6。这将从你的VB6中删除大量的代码，并希望主要留下业务逻辑。
你需要记住的最重要的事情就是不要成为牛仔。
答案 1 :(得分：11)
代码是否绝对必须迁移？如果它没有，仍然服务于它的目的，并且是一半可维护的，只需不管它并继续前进。
将代码转换为新语言的动机很快就会在无数小时，数周和数月的代码迁移后消失 - 特别是在您提到的规模上。
从概念上讲，代码迁移的想法是一个奇妙的想法。很可能，这是一个可怕的混乱，你会厌恶生活。
考虑一下，你在修复缺陷的同时是否讨厌你的生活？为迁移项目估算了100倍。
只要有效，大多数企业都可以真正关心它的内幕。请记住，他们不是开发人员，不关心解决它的痛苦程度（因为他们不是那样做）并且激励企业花费数万美元带来代码是最新的，根本没有任何商业意义。
答案 2 :(得分：10)
经历过类似的将14岁的代码迁移到VS2008
以下是一些提示：
有一家公司可以帮助您完成整个过程（虽然我们没有使用它们） http://www.vbmigration.com/
答案 3 :(得分：6)
查看M. Feathers'"Working Effectively with Legacy Code" - 它讨论了增强，重构和迁移以及未经测试的代码的缺陷。
答案 4 :(得分：6)
你在制定这个问题方面做得很好。谢谢你的询问！感谢stackoverflow社区发布深思熟虑的回复（像往常一样）。
如果这是一个相当大的代码库，它听起来像是（50-100个相互关联的VBP，200-500K LOC），那么你应该考虑投资迁移工具。请考虑这个类比：如果您要转换大量数据，即使源数据很脏并且与所需格式非常不同，您也可以使用工具。如果有人建议您只是重新输入数据，或者甚至进行粗略转换然后手动修复，您会认为它们是疯子。此外，通过120种表单，应用程序听起来像是提供了相当多的业务功能。这种业务功能已经出现多年使用，无论喜欢与否，VB6代码代表了该功能的完整，正式且经过生产测试的规范，以及关于应用程序如何在幕后工作的无数技术事实。 “从头开始”重新收集，重新编码和重新测试所有这些功能/技术要求是非常昂贵和困难的。为了管理项目的成本和风险，您必须“兑现”遗留代码。问题是：如何做到这一点，并确保在迁移后降低拥有成本。
挑战与代码库的大小关系不大，而不是需要适应和利用.NET的重新设计细节。您需要确定使VB6代码“丑陋”代码的具体内容，为什么它“丑陋”，以及如何/应该/想要在.NET中以不同方式执行这些操作。一旦开始制定这些重新设计要求，您就可以开始在转换过程中实现它们，以便它们显示在您的.NET代码中。我们提倡的一般方法称为“工具辅助重写”，完成如下：
该工具的输出不需要“完美”（软件永远不会......）它只需要“足够好”。步骤3中提到的“足够好”是一个关键问题。从本质上讲，它意味着代码质量 - 在验证功能正确且符合您的标准方面 - 是开发团队知道完成迁移然后继续操作/维护应用程序需要做什么 - 他们是相信他们可以在给定的时间和资源限制内做到这一点。对于一个非常大的代码库“足够好”是“非常好的”，因为它试图完成并随后保持低质量的迁移太昂贵和冒险。通常，代码越大，预算越小，迁移过程的效率就越高。
关于“完成.NET中的工作”的一些想法：在.NET中使用格式良好的代码是一个重要的里程碑。 .NET社区提供了很好的重构，分析和单元测试工具，可以帮助您加快完成迁移的速度。您将在此过程的早期阶段使用Visual Studio来试验和优化重新设计，并调试/测试应用程序。能够在迁移工作的早期使用.NET和Visual Studio中的整个代码库是工具辅助方法的关键优势（也是关键部分）。
当然，为了实现这一点，您需要能够投资专门用于支持工具辅助重写的迁移工具集。来自Great Migrations的工具是我在此类别中知道的唯一工具。
免责声明：我为Great Migrations工作。我们网站上有更多信息 - 包括如何使用该工具帮助迁移超过1M的VB6重新设计C＃的案例研究，以及详细描述产品和方法的gmStudio用户手册。
答案 5 :(得分：2)
与我工作过的一些东西相比，听起来很小。然而，还有另一种方法可以与PeanutPower所示的方法结合使用。
答案是构建一个框架，允许您一次删除程序的各个部分并逐个转换。
e.g。插入一个数据库适配器'layer'来处理对数据库的所有调用，然后逐个删除除SQL之外的每一个，并用对db层的调用替换它。当新呼叫通过该层时，旧呼叫仍然会直接进入。最终所有调用都将通过该层，您可以更改后端数据库。
您可以通过扩展框架“图层”来覆盖该功能，从而对代码的任何其他部分执行相同操作。
将它从VB6转移到VB.NET（例如）的关键是使用Interop库 - 这里有一篇文章：http://support.microsoft.com/kb/817248
另一个很久以后的想法：获取MZ-Tools并使用他们的分析工具找到冗余代码并摆脱它。我设法在我公司的旧版产品中消除了5％到10％的代码。
答案 6 :(得分：2)
根据您对此项目的描述，您可能会同时进行重构和迁移。你显然会采用大量的冗余代码并将其整合起来;作为整合的一部分，你可以在.NET中重写它（冗余代码）。
这不适用于UI的东西。但它将用于数据库和业务逻辑的东西。例如，我没有看到你的代码，但我敢打赌你的应用程序中的大多数组合框都可以通过其形式的方法填充（可能复制并粘贴到Form_Load）来创建ADO记录集，循环遍历它们。这可以重构为.NET数据访问类并轻松集成到现有表单中。它还可能允许您将缓存的神奇世界引入此应用程序，这将很好，因为这可能会导致可见的性能改进。
明显的改进非常重要。除非您的管理层完全满足这样做的必要性，否则这是一项非常高风险的工作。如果您发现自己告诉管理层由于重构中的问题而导致实施CR的时间比预期的要长，那将是非常糟糕的。即使你有完全的支持，你也不希望出现这种情况，但如果你的支持是偏袒的，情况会更糟。可见的改进将为减轻这种情况做很多工作。
此外，关于重构遗留代码问题的文献越来越多。你需要掌握它。在您深入了解之前，您知道的越多，您的体验就会越好。我自己没有看过Michael Feathers的书，但如果我在你的鞋子里，这是我做的第一件事。
答案 7 :(得分：2)
参与了多个迁移项目后，首先要做的是明确您的迁移目标。这些可能因组织而异，但它们有助于在实际迁移项目期间设置优先级。它还有助于更好地评估风险和成本的收益。
与其他人提到的一样，重要的是要意识到迁移过程不会自动提高代码的质量。因此，如果您的主要目标是重构（而不是其他任何内容），那么您应该意识到，在您拥有功能相同的代码（取决于代码大小和迁移复杂性）之前可能需要数周或数月。
话虽如此，除了单元测试套件外，.NET确实有一些非常好的重构和代码分析工具。 ArtinSoft的Visual Basic Upgrade Companion等自动转换工具可以进行自定义，以在转换过程中强制执行编码标准或显着改进代码。这与其他代码修改工具（如ReSharper）混合将大大加快您向.NET的过渡。
根据我的经验，迁移项目是一个可管理的项目，只要您知道涉及手动工作。商业工具具有评估模式，可以帮助量化迁移工作量，并让您了解迁移过程中可能遇到的挑战。
如果您更喜欢低风险和低成本的解决方案，我会坚持重构代码，着眼于最终的迁移。我有这种方法的客户。因此，当需要迁移他们的代码时，已经解决了几个问题。
基本上，任何新的自定义控件都应该用.NET编写，并作为ActiveX控件公开，供VB6应用程序使用。同样，新的DLL函数应该放在可以通过COM使用的.NET程序集中。这样，当您需要迁移时，您不必担心这些控件或库。
答案 8 :(得分：1)
不要从头开始重写。听起来它会花费你很多年，你很可能会在代码中引入新的（旧）错误。
我会考虑缓慢但简单地重构代码。从小处开始。令人惊讶的是，您可以快速地将代码重构为更易于管理的内容。并且您应该能够在每个refractoring块的末尾保持代码“正常工作”。
<强>更新 值得注意的是，自动迁移只会将您的问题转移到另一种语言。