这是“十分之一”的时间重写吗？

Question

如果可以避免，我非常反对重写应用程序。我理解10次中9次的规则，重构更好，但我可能是10次中的一次，我希望找到那条线。

目前的情况是：

• 我接手了维护VB6 / SQL应用程序。
• 代码总数为75-100k（代码隐藏，模块和类）。
• 最初的开发人员离开了，所以这只是我，而且至少在几年内没有机会扩大团队。
• 该程序没有架构（只是在代码隐藏形式的纯文本中直接进行SQL调用）。
• 不试图遵循DRY或OAOO原则。
• 数据库有一些主键，但没有外键。
• 在这个系统到位之前，所有东西都是用大型电子表格管理的，所以这个系统确实比他们拥有的东西有了很大的改进，但却没有做到他们想象的那样。
• 我能够自己写一些工具来用常量和查找替换表名和列名的所有文字实例，并且我编写了一个快速代码生成脚本来生成数据库中的常量和查找，所以现在我可以安全地进行数据库更改，并查看所有损坏的地方我已经开始将数据库“边缘化”规范化，但它就像3％的那样。
• 没有单元测试，因此每次更改数据库时，我基本上都要重写其上的任何逻辑，我使用这两个版本来比较功能并确保它们是相同的。到目前为止一切顺利。
• 我开始只是试图修复关键的错误来阻止流血，我可以肯定地说这大部分已经完成了，所以现在我踩了一会儿来看看大局。
• 管理层的期望是支持和合理的。
• 长期目标是将其转换为.NET ...

所以，我正在权衡这些选择：

1. 继续规范化数据库并在我去的时候修改VB6应用程序（最后是逐个重写）
2. 将VB6置于仅维护状态（无新功能），一次选择一个功能模块，并在规范化数据库结构的基础上在.NET中重写该部分。

我的想法是，如果我选择选项1，那么最后我只有一个VB6应用程序，他们仍然想要升级到.NET，我已经研究过它，这是昂贵和耗时的，甚至与你仍然会得到一些有点像弗兰肯斯坦的工具。如果我选择选项2，我相信我可以尽快完成，我会直接跳到目标技术。

在我的规范化过程中我已经重写的小规模部分中，结果是已经存在的改进模块，因此在重写期间会添加值。

现有的应用程序，尽管存在各种缺陷，但仍是一个很好的讨论点。使用它的人可以告诉我什么对他们起作用，什么不起作用，所以那里肯定有很多价值。

那么，这是否有资格成为“十分之一”时间之一？

Answer 1

我有一个最初用VB6编写的项目，他们雇用我将其转换为.NET。我最近离开了这份工作。我相信该程序可能不应该被重写。

如果采用重写方法（基于我的项目），这里有一些因素需要考虑

• 不会直接改写。一旦有消息传出，重新编写的新功能请求将会弹出，并且会有相当数量的重新设计/重新设计
• 人们不会首先接受“维护”模式而不会遇到很多阻力。有一段时间，每个bug都将是“关键任务”
• 将VB6应用程序移植到.Net不应该被视为比将C ++应用程序移植到.Net或将Haskell项目移植到.Net更容易。有一些共性，但最终，它是99％不同的代码库（现有方程式可能为1％）
• 假设这个程序正在生产（甚至在内部），你的新程序很可能不会起作用，至少在最初阶段。你会听到“但是以旧的方式......”或“它曾经......”
• 假设您的客户不是其他IT人员，他们将无法理解：
  • 花了这么长时间
  • 为什么它不像旧版本的程序（外观和感觉）
• 虽然当前的应用程序是随着时间的推移而开发的，但预计您的应用程序将在上线时以及在更短的时间内拥有100％的功能。

这些都是从VB6到.Net的真实生活迁移的经验。我是唯一的.Net开发人员。没有资源可以雇用额外的帮助。我的情况和你的情况之间的主要区别是1.最初的开发人员仍在那里 - 只是在一个新的角色（有时更难）和2.原始的应用程序不需要修复很多错误。

我想如果我要重新做一遍，我会尝试创建一些.NET dll并将它们合并到VB6应用程序中。逐件转换为.net。因此，您可能会将应收帐款的数据和业务逻辑移至.NET。所有其他方面保持不变。 GUI，其他功能等。然后在推出并标记为完成之后，接受Shipping部分并执行相同的操作。最后一步是创建一个使用您的DLL的新.NET GUI。

这为您带来了一些好处

• 最后，应用程序是用.NET编写的
• 允许您慢慢推出更改。您不会在“go-live”一周的同一时间调试运费和应收账款以及小时等。
• 允许您使用更多现代工具而不会破坏整个程序。想使用NHibernate，PLINQ还是MEF？一次做一个模块。学习该工具并采取小步骤
• 允许GUI的灵活性。最后，你可以使用你的核心DLL来完成WinForms，WPF或Web项目。
• 不会同时对用户进行大量更改。您已经重写了应收帐款部分并且用户没有任何线索，因为GUI是相同的。然后，当您推出GUI时，您知道您的后端正在运行。
• 将使未来的重构变得更容易。您已经将项目分解为一口大小的块。你可以进一步了解它们的影响等。

我非常厌倦决定重新编写此应用程序并为其提供可用产品的单一开发人员。我认为保守估计（假设没有范围蔓延等）将是24个月。可能更有可能是3 - 4年。

我离开的项目已经工作了3年并且是可以维修的，但还不是原始应用程序的100％替代品。就像我说的那样......即使这意味着我没有工作，但我认为不应该重写。

Answer 2

在我们一次完成应用程序和数据库的项目中，我建议首先尝试使数据库正确，然后再执行应用程序。

同时尝试两者可能会非常痛苦。但是，如果没有在您旁边查看代码，那么肯定很难说。

我只是觉得如果你有数据库并且你可以依赖它，你应该能够使用集成测试重写，然后更可靠地进行单元测试。

一旦你拥有了数据库，我认为最好的情况是尝试将代码模块化为单独的和可重用的程序集（你应该可以在.NET中使用），然后逐渐将这些程序集成到.NET中。 VB。如果代码是可怕的意大利面条，这可能是不可能的！

Answer 3

开始一次转换一个不同的模块，将它们从VB6应用程序中逐步取出。

根据什么是关键任务/战略性优先考虑，因此您也可以随时增加价值。

由于数据库将是集成点，因此请确保修复相关部分（与当时正在处理的任何部分相关），这样您就可以在坚实的基础上构建。

在短期内，您将有更多的工作（VB6代码和.NET都需要维护），但是通过更清晰的架构，您将能够越来越快地开始远离传统应用程序。

通过这种方式，您可以让两个系统同时运行一段时间，这样您就可以退回，并且可以添加适当的结构（架构，数据库完整性等）。

Answer 4

这是一篇很棒的文章。然而恕我直言，它缺少一个重要的一块根据客户的重写价值是多少，成本和风险是什么。我在这里猜测，但可能是以下

客户可以获得以下

1. 更快的缺陷/增强分辨率。
2. 部署期间出现新缺陷的可能性降低
3. 从
租用较大的开发人员池
4. 可能能够实现过去不可能实现的功能

成本/风险

1. 几乎完全丧失当前投资
2. 可能会引入过去已解决的缺陷。

您应该考虑可以采取哪些措施来降低风险，并了解您的增值是否会超过风险和成本。

Answer 5

我认为在没有帮助的情况下重写100KLOC应用程序（包括逆向工程规范和测试）可能需要一段时间（太长时间）。

Answer 6

从头开始重写应用程序听起来像是一项重要工作，特别是因为没有单元测试，而且您不是原作者。我认为增量方法可能是最好的，从添加单元测试和重新分解代码开始，以便可以进行单元测试以捕获应用程序的功能。然后随着时间的推移逐步改进应用程序，而不是暂停。如果你不是原作者，重写通常很容易被低估，因为那里的业务逻辑不明显。

Answer 7

1）。这是两年前MS停止支持开发的VB6（ref）。他们不支持它，所以你也不应该这样做，这就是软件永远不会完成的原因。

2）。代码量不是一个因素 - 重构或重写应用程序的难度都随着大小而扩展。

3）。没有原始架构师意味着你将永远猜测意图并绊倒你不知道的事情是一个问题。如果您选择不重写，我会认为这是一个严重的风险。

4）。像它这样的架构显然是垃圾，还有另一个严重的风险。一切都会花费你更长的时间，重构的重构效率无论如何都只会持续很短的时间。

5）。缺乏单元测试是另一个严重的风险，因为您无法信任您所做的任何更改。这是你需要改变你采取的任何方法的第一件事。

6）。如果你有管理层的接受和对.NET的战略愿望那么你真的没有任何理由不重写。

因此，如果不进行重写，并且没有理由避免重写，那就是几个严重的风险。我会尝试将应用程序分解为逻辑服务，并尽可能地分离责任。删除并替换使用anti-corruption layers对旧应用程序进行烧录的业务逻辑块，以尝试最小化周转时间并证明重写的有效性。

祝你好运士兵。

Answer 8

The long-term goal is to convert it to .NET anyway...

听起来你只需维护旧代码，直到把它移植到.NET。所以保存一些工作，从今天开始，重写。我的2点。

确保现有的应用程序仍然可以在您重写时使用，就像在一两天内无法完成的那样:)“仅维护”状态对我来说听起来不错。

Answer 9

也许。对于初学者，你说“不试图遵循DRY或OAOO原则”，所以可能会有很多可以重构的冗余，但是如果你在.NET中重写，你就不必重构了。此外，由于这个问题，LOC计数可能会膨胀。

如果你继续使用缓慢的，重构的方法，你仍然需要在.NET中重写。重写的来源最终将更整洁，更清晰（并且可能更加保持理智），但最终还是需要整个重写。

如果您将应用程序置于维护模式，然后开始编写新应用程序，需要多长时间 - 以及通过existsinc应用程序将新功能延迟投入生产需要多长时间？假设将会添加一些需要的关键功能，因此您无论如何都必须添加它们。

Answer 10

首先 - 你很差s * d。从来没有一个好地方被淹没。

但是，听起来好像你已经抓住了公牛并追求稳定的路线。我很想把明年不再支持VB6的混合物（据我所记得）这意味着如果应用程序因os更改而被破坏，那么你基本上会陷入困境。除此之外，我试着看看你可以在.net中进行多少并行开发，因为互操作不应该（着名的最后一句话）太难以解决。

当你在悬崖边时，我会说跳跃但是要谨慎。

当我能够跳回主题时，我会添加更多细节。

Answer 11

我会选择'冻结并写一个新应用'路线。

• 从VB6应用程序中尽可能多地利用VB6代码/方法，或者您认为合适。听起来你可能会去VB.NET，有些代码可能会在升级后继续存在。无论哪种方式，都有可以提供帮助的代码转换器。

• 开始在数据库中重新设计。编写脚本以将数据转换为对您有意义的规范化形式。

• 然后开始逐个模块迁移到新应用程序。如果您能提供帮助，请不要对新应用程序进行任何维护更改/修复/增强。