如果可以避免的话，我非常反对重写应用程序。我理解这样的规则：十分之九，最好进行重构，但我所处的情况可能是十分之一，我正在寻找这条线。
目前的情况是：
- 我接手了一个 VB6/SQL 应用程序的维护。
- 总代码行数为 75-100k（代码隐藏、模块和类）。
- 原来的开发人员离开了，所以只有我一个人，没有机会扩大团队，至少几年内是这样。
- 该程序没有架构（只是以代码隐藏形式以纯文本形式进行直接 SQL 调用）。
- 不尝试遵循 DRY 或 OAOO 原则。
- 数据库有一些主键，但没有外键。
- 在这个系统到位之前，一切都是在大型电子表格中管理的，所以这个系统确实比他们现有的系统有了巨大的改进，但并没有达到他们的设想。
- 我能够自己编写一些工具，用常量和查找替换表名和列名的所有文字实例，并且我编写了一个快速代码生成脚本来从数据库生成这些常量和查找，所以现在我可以安全地进行数据库更改并查看所有损坏的地方。我已经开始“边缘”规范化数据库，但只完成了 3%。
- 没有单元测试，因此每次更改数据库时，我基本上都必须重写其上的任何逻辑，并且我使用两个版本来比较功能并确保它是相同的。到目前为止，一切都很好。
- 我一开始只是尝试修复关键错误以止血，我可以有把握地说这已经大部分完成了，所以现在我退后一步来看看大局。
- 管理层对他们的期望表示支持和合理。
- 无论如何，长期目标是将其转换为.NET......
所以，我正在权衡这些选择：
- 继续标准化数据库并修改 VB6 应用程序（最终是逐步重写）
- 将 VB6 置于仅维护状态（无新功能），一次选择一个功能模块，并在标准化数据库结构之上用 .NET 重写该部分。
我的想法是，如果我选择选项 1，那么最终我只有一个 VB6 应用程序，他们仍然想升级到 .NET，我已经对此进行了研究，它既昂贵又耗时，即使使用您所使用的工具仍然会得到一些有点像弗兰肯斯坦的东西。如果我选择选项 2，我相信我可以更快完成，并且我会直接跳到目标技术。
在我在规范化过程中已经重写的小规模部分中，结果是对已有模块的改进，因此在重写过程中增加了价值。
现有的应用程序尽管存在种种缺陷，但却是一个很好的讨论话题。使用它的人可以告诉我什么对他们有用，什么对他们无效，所以这种方式肯定有很多价值。
那么，这是否符合“十分之一”的次数之一？
我有一个最初用 VB6 编写的项目，他们雇用我将其转换为 .NET。我最近离开了那份工作。我相当确信该程序可能不应该被重写。
如果您采用重写方法，需要考虑以下一些因素（基于我的项目）
- 这不会是直接重写。一旦消息传出，就会出现重新编写的新功能请求，并且将会有相当多的重新设计/重新架构
- 如果没有很大的阻力，人们不会接受“仅维护”模式。有一段时间，每个错误都将是“关键任务”
- 将 VB6 应用程序移植到 .Net 不应被视为比将 C++ 应用程序移植到 .Net 或 Haskell 项目到 .Net 更容易。有一些共性，但最终，它的代码库有 99% 不同（现有方程可能有 1% 不同）
- 假设该程序正在生产中（即使是在内部），您的新程序很可能达不到标准，至少在最初是这样。您会听到“但是以旧方式......”或“它曾经......”
- Assuming your customers are not other IT people, they WILL NOT understand:
- 什么事要花这么长时间
- 为什么它不像旧程序（在外观和感觉上）
- 虽然当前应用程序是随着时间的推移而开发的，但您的应用程序可能会在上线后在更短的时间内拥有 100% 的功能。
这些都是现实生活中从 VB6 迁移到 .Net 的经历。我是唯一的 .Net 开发人员。没有资源来雇用额外的帮助。我的情况和你的情况之间的主要区别是 1. 原始开发人员仍然存在 - 只是担任新角色（有时会变得更困难），2. 原始应用程序不需要大量错误修复。
我想如果我能重来一次，我会尝试创建一些 .NET dll 并将它们合并到 VB6 应用程序中。逐段转换为.net。因此，也许您可以将应收帐款的数据和业务逻辑移至.NET。所有其他方面保持不变。 GUI、其他功能等。然后在推出并标记为完成后，进入“运输”部分并执行相同的操作。最后一步是创建一个使用 DLL 的新 .NET GUI。
这给你带来了几个好处
- 最后应用程序是用.NET编写的
- 允许您慢慢地推出您的更改。您不会在“上线”那周同时调试运输、应收账款和人力资源等
- 允许您使用更现代的工具，而不会破坏整个程序。想要使用 NHibernate、PLINQ 或 MEF？一次执行一个模块。学习该工具并采取小步骤
- 允许 GUI 上的灵活性。最后，您可以使用您的核心 DLL 来完成 WinForms、WPF 或 Web 项目。
- 不会立即向用户提供大量更改。您已经重写了应收账款部分，但用户没有任何线索，因为 GUI 是相同的。然后，当您推出 GUI 时，您就知道后端正在工作。
- 将使以后的重构变得更加容易。您已经将项目分解为小块。您可以进一步研究它们，了解它们的影响等。
作为一个开发人员，我会非常厌倦决定重写这个应用程序并向他们提供一个工作产品。我认为保守估计（假设没有范围蔓延等）将是 24 个月。更有可能是3-4年。
我离开的项目已经工作了 3 年并且可以使用，但还不能 100% 替代原始应用程序。就像我说的......即使这意味着我没有工作，我认为它不应该被重写。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
