您如何继续开发具有旧代码和新代码的大型（长期）软件系统？

Question

我在一个拥有大量用户安装基础的大型代码库上工作。该代码最初是用vb6编写的，带有一些c ++ COM模块，用于低级工作。

重写所有已在vb6中编写并且每天都被我们的客户使用的代码是完全不可行的，但我们也在继续对软件（大型和小型）进行改进和自定义。

到目前为止，我的解决方案是在c＃（winforms甚至是wpf）中编写大部分新代码，然后使用COM interop从vb6调用模块。

有没有人有像这样（10年以上）的长期软件套件的经验，这些软件套件无法完全重写，但需要同时进行持续的新开发。此外，在这样的混合系统中，连接模块的最佳方法是什么？我现在正在使用COM，但也认为IPC也有单独的流程。

Answer 1

很难给出一个包罗万象的答案，但高级方法很明确。至少，这是我用过的方法。确定目标的优先顺序，然后尝试确定实现这些目标的成本。您的成本基本上可归结为“开发时间”。

首先，你想要一直在努力工作。如果你有一些有效的东西，并且没有充分的理由重写它，那就保留它。

如果您的某些现有代码需要更新以完成其工作，那么您正在考虑维护成本。此时，您需要确定重写是否会提高维护成本，足以使其值得。不要忘记减去新bug的测试和调试，因为会有新的bug。不要仅因为旧代码而忽略工作代码。

如果您现有的代码足够模块化，您通常可以一次完成一个代码。首先重写高维护组件。

如果您要在C＃中进行新的开发，那么您应该很好地使用COM组件，直到您有足够的理由来替换它们。

Answer 2

我认为你有一个好的计划。这将最终将大部分代码转移到C＃中，利用更好的工具集。

VB6代码是否包含COM对象？

您提到代码“无法停止以进行完全重写”。但你不必停下来。一个接一个，您可以用等效的C＃代码替换每个VB6功能。这将允许您一次进行一次更改（最好使用自动化测试来证明您没有破坏任何东西）。

Answer 3

当存在激励因素时，根据需要重写。

我工作的一个旧的Windows项目有一个用C编写的规则引擎，它正在工作，所以我们把它留作黑盒DLL。

我们构建了一个新的前端，用户群对应用程序易于使用的全新现代外观印象深刻。内部的任何东西都没有真正改变。

数据库访问层使用的是SQL Server DBLIB，在我们升级SQL Server之前没有重新编写。

Answer 4

我们有几种这样的系统。所有这些令人不安的部分是lifecycle support status of VB6。存在风险（无论多么小），您将无法获得Microsoft的帮助，例如有一个showstopper问题。未来的服务器升级，并且无法自行修复（例如，由于VB6 DLL和修补的服务器O / S之间的不兼容）。这是您的管理层可能感兴趣的风险 - 但是，如果您现在没有任何支持协议，也许他们对此感到满意？

我们实际上正在考虑重写和重新设计一些更重要的一些。我们已经尝试过渐进式进化，它可以工作，但是（让我们说）有趣的操作和维护情况。我强烈建议使用大量可配置的日志记录来处理所有内容（旧代码和新代码）（如果您还没有），以帮助进行故障隔离。

COM听起来像是旧版和新版之间的合理界面。除非你在组件之间进行非常简单的交互，否则我真的不明白你为什么要回到更基本的IPC机制。 COM有其复杂性，但它也提供了许多有用的抽象，例如数据输入和版本控制，你必须重新发明和维护......

Answer 5

我认为您需要查看客户的升级路径。事实是，在某些时候，当他们拥有16个核心CPU时，你会想要并发性来加快速度。所以你有一个商业案例可以从VB6转向WCF。 WCF内置了并发和同步支持。它可用于本地进程内通信以及跨进程和跨机器通信。它还具有允许您进行更多AOP风格编程的好处。

Answer 6

我目前是开发大型遗留系统的几个开发人员之一，该系统最初是作为C和C ++与Win32的组合，后来，MFC在后端C代码中进行了少量组装。我们最近从VC ++ 6跳到Visual Studio 2005（并且已经升级到2008年），用于我们正在开发的项目的最新版本。自从IDE /编译器升级以来，我们一直在清理一些外观和感觉，并且一直在使用WinForms添加托管C ++，现在使用WCF添加C＃。

虽然我们的系统（包括后端）的基础几乎肯定会保留在C中（至少在可预见的未来），但前端的任何新功能都很可能在C＃/ WCF中完成。当我们有时间和/或需要时，我们打算开始用等效的C＃/ WCF代码替换前端的旧部分。