问题描述

如果可以避免的话，我非常反对重写应用程序.我理解 10 次中有 9 次的规则，最好重构，但我的情况可能是 10 次中有 1 次，我正在寻找这条线.

I'm very much against rewriting an application if it can be avoided. I understand the rule that 9 times out of 10, it's better to refactor, but I'm in a situation where it might be the one time in ten, and I'm looking to find that line.

目前的情况是:

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

所以，我正在权衡这些选项:

So, I'm weighing these options:

1. 继续规范化数据库并随时修改 VB6 应用程序(最终被逐个重写)
2. 将 VB6 置于仅维护状态(无新功能)，一次选择一个功能模块，然后在规范化数据库结构之上用 .NET 重写该部分.

我的想法是，如果我选择选项 1，那么最后我只有一个 VB6 应用程序，他们仍然想升级到 .NET，我已经研究过了，它既昂贵又耗时，即使使用这些工具你仍然会得到一些有点像科学怪人的东西.如果我选择选项 2，我相信我可以更快完成，我会直接跳到目标技术.

My thought is that if I choose option 1, then at the end I just have a VB6 app that they still want to upgrade to .NET, and I've looked into that and it's costly and time consuming, and even with the tools you'll still get something that's somewhat of a Frankenstein. If I go with option 2, I believe I can be done sooner, and I'll jump right to the target technology.

在我在规范化过程中已经重写的小规模片段中，结果是对已有模块进行了改进，因此在重写过程中增加了价值.

In the small scale pieces that I've already rewritten during my normalization process, the result has been an improved module over what was already there, so there is value being added during the rewrite.

现有的应用程序，尽管存在所有缺陷，但却是一个很好的讨论点.使用它的人可以告诉我什么对他们有用，什么没用，所以这样肯定有很多价值.

The existing app, for all its flaws, is a great talking point for discussion. The people using it can tell me what's working for them and what isn't, so there's certainly a lot of value there that way.

那么，这算不算十分之一"的次数之一?

So, does this qualify as one of those "one in ten" times, or not?

推荐答案

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

I had a project that was originally written in VB6 and they hired me to convert it to .NET. I recently left that job. I'm fairly convinced that the program probably shouldn't have been rewritten.

如果您采用重写方法，请考虑以下一些因素(基于我的项目)

Here's some factors to consider if you take the re-write approach (based on my project)

• 这不会是直接重写.一旦消息传出，就会弹出重新编写新功能的请求，并且会有大量的重新设计/重新架构
• 人们不会在没有很多阻力的情况下接受仅维护"模式.有一段时间，每个错误都将是关键任务"
• 不应认为将 VB6 应用程序移植到 .Net 比将 C++ 应用程序移植到 .Net 或将 Haskell 项目移植到 .Net 更容易.有一些共同点，但归根结底，这是一个 99% 不同的代码库(现有方程可能有 1%)
• 假设该程序正在生产中(甚至在内部)，您的新程序很可能无法达到标准，至少最初是这样.您会听到但以旧方式..."或它曾经..."
• 假设您的客户不是其他 IT 人员，他们将不会理解:
  • 为什么要花这么长时间
  • 为什么它不像旧的程序(外观和感觉)

  这些都是现实生活中从 VB6 迁移到 .Net 的经历.我是唯一的 .Net 开发人员.没有资源可以聘请额外的帮助.我的情况和你的情况之间的主要区别是 1. 原来的开发者还在那儿 - 只是换了一个新角色(有时会变得更难)和 2. 原来的应用程序不需要修复很多错误.

  Those are all experiences from a real life migration from VB6 to .Net. I was the only .Net developer. There was no resources to hire additional help. The main differences between my situation and yours is 1. the original developer was still there - just in a new role (making it harder at times) and 2. The original app didn't need a lot of bug fixes.

  我想如果我要重新做一遍，我会尝试创建一些 .NET dll 并将它们合并到 VB6 应用程序中.一块一块地转换成.net.因此，也许您将应收帐款的数据和业务逻辑移至 .NET.所有其他方面保持不变.GUI，其他功能等.然后在推出并标记为完成之后，进入运输部分并做同样的事情.最后一步是创建一个使用您的 DLL 的新 .NET GUI.

  I think if I had it to do all over again, I would try to create some .NET dlls and incorporate those in the VB6 app. Piece by piece converting to .net. So perhaps you move the data and business logic for Accounts Receivable to .NET. All the other aspects stay the same. The GUI, the other features etc. Then after that's rolled out and marked as complete, take on the Shipping section and do the same thing. The final step is to create a new .NET GUI that uses your DLLs.

  这会给您带来一些好处

  • 最终应用程序是用 .NET 编写的
  • 允许您慢慢推出您的更改.您不会在上线"那一周同时调试运输、应收账款和人力资源等.
  • 允许您在不破坏整个程序的情况下使用更现代的工具.想要使用 NHibernate、PLINQ 或 MEF?一次做一个模块.学习工具并迈出一小步
  • 允许在 GUI 上实现灵活性.最后，您可以使用您的核心 DLL 来创建 WinForms、WPF 或 Web 项目.
  • 不会一次性对用户进行大量更改.您已经重写了应收账款部分，而用户不知道，因为 GUI 是相同的.然后，当您推出 GUI 时，您就知道您的后端正在工作.
  • 将使未来的重构更容易.您已经将您的项目分解成小块.您可以进一步研究它们，了解它们的影响等.

  我会非常厌倦作为一个开发人员决定重新编写这个应用程序并为他们提供一个工作产品.我认为保守估计(假设没有范围蔓延等)将是 24 个月.可能更可能是 3-4 年.

  I would be VERY weary of deciding as a single developer to re-write this application and deliver them a working product. I think a conservative estimate of that (assuming no scope creep etc) would be 24 months. Probably more likely 3-4 years.

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

  The project I left had been worked on for 3 years and was servicable, but was not yet a 100% replacement for the original app. Like I said... even though it would have meant me not having a job, I don't think it should have been re-written.

  这篇关于这是“十分之一"吗?是时候重写了吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持编程学习网！