你如何继续发展与传统的和新的代码大（长期）的软件系统？ [关闭]

Question

我在一个大的代码基础工作与用户的大的安装基础。该代码最初被写在vb6与低电平工作几个C ++ COM模块。

这是完全不可能重写所有这一切都已经写在VB6和每天都被用来深受广大客户的代码，但我们也在不断的进行改进和用户定义的软件（大，小）。

我的解决方案到目前为止是写最新的代码在C＃（WinForms和甚至WPF现在），然后使用COM互操作以从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和未重新wrtten直到我们升级SQL Server中。

Answer 4

我们有这种类型的几个系统。所有这一切的令人不安的部分是生命周期支持VB6 的状态。还有就是你将无法从微软获得帮助与例如一个搅局者的问题的危险（无论多小）未来的服务器升级，而不必自己修复它（比如，由于之间的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 /编译器的升级，我们已经清理了一些外观和感觉，并已加入托管C ++与WinForms和现在C＃与WCF。

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