用于重建传统应用程序的策略

我有一个新任务即将推出，我已经在.NET WPF中重新构建了一些遗留COM应用程序。如果可能的话，我需要重新使用功能或存在代码，但是我怀疑这个范围是有限的。用于重建传统应用程序的策略

我需要复制现有的功能，但需要使用现代和可扩展的体系结构来实现它。

有没有人有任何接近这种类型的项目的一般建议？这个问题上有没有好的资源？

是否有任何经过验证的技术或普遍的pifalls？

来源

2009-08-22 Steve

我目前正在做几乎这个确切的事情。

我能给的最重要的建议是重新规范系统。如果您对将要交付的产品没有一个全新的期望，那么您将会遵循旧系统的标准。这些标准不会很好，否则你不会重写它。

从使用当前系统的人中确定他们实际上想要完成什么，并且建立了那，而不是一个直接的端口。从长远来看，参与的每个人都会过得更好。

简而言之，不要在此过程中添加功能。在您重新构建应用程序之后，这个机会就会来临。做港口时没有什么比接受与现有功能相矛盾的新要求更糟。

来源

2009-08-24 01:47:27

在那里，做到了 - 我参与了从“规范”（好，有点）重写一百万行代码程序（4GL和C的混合）：它不便宜也不快，结果是值得怀疑的是（为了取得不错的结果，又进行了一次重写）。 – MaD70 2009-10-21 16:33:41

另外：由于系统不符合当前的要求，所以并不总是移植遗留代码，作为改变/改进的前奏。有时进行移植是因为以下平台过时且维护成本高昂，但是您的软件系统仍然具有很大的价值。 – MaD70 2009-10-21 17:30:19

最重要的是自动验证（又称单元/功能测试）。请参阅this question。因为很多建议都是simillar。通过这个我并不是指为新系统编写测试，我的意思是编写测试传递给旧系统，并且将通过新系统。这将是你将如何验证你已经重新创建了原始功能。我认为在一个已经存在的系统中，你可以很容易地（虽然单调乏味）以BDD的风格创建functional specs that could be executed。

来源

2009-08-22 10:19:04

+1：测试驱动的逆向工程。 – 2009-08-22 11:32:39

IT行业对验证过程的依赖是完全动态的，非常不完整的，没有很好地建立起来（即通常进行测试的方式）对其产品质量而言是灾难性的。我们做了什么？（我们是否做出正确的事情？），即产品是否做用户真正需要的东西？）但是对于验证很弱*（“我们做了什么？我们试图制造？“，即产品是否符合规格？）。我知道，时髦的方法蔑视规范，但我认为他们误解了规范。 – MaD70 2009-10-21 17:20:23

我同意规格非常有效，但他们正在呼吸。迄今为止我所遇到的大多数非当前规格都在IT相当于石材的片剂。目前以与软件本身相同的代码对它们进行编码的方式会随着更适合的工具的出现而通过。 – 2009-10-21 20:02:55

我想说一个常见的陷阱是试图修复那些没有被破坏的东西。考虑如何重新使用现有的软件而不是重新发明它。如果它已经存在了很长一段时间，这可能是因为它运行得非常好。您将面临一项艰巨的任务，以匹配没有引入新bug的功能。

再次，这可能是因为你的公司超过了这个遗留系统。想一想为什么要你重新设计这一点，以及你需要解决的旧问题有什么限制。

来源

2009-08-22 10:35:49 tchen

请记住，当您部署新重新构建的系统时，您很可能不得不将整个数据堆从旧的转换或移植到新的。当你走时考虑这一点，因为如果你不这样做，那么这项工作就会变得和你的重写一样大。如果转换不好，无论可靠还是有效，都可能会在第1天即将推出新系统，即使该功能已被发现。

来源

2009-08-22 10:40:59

Michael Feathers：Working effectively with legacy code提供了许多技术来处理和替换遗留代码。我发现它很可读;一些方法（以及许多黑客）对我来说是新手。

来源

2009-08-22 10:56:14 mfx

作者是Michael Feathers - 否则我同意这本书很好，但它特别涉及获取遗留代码，而不是从头开始重写它的技术。 – 2009-08-23 08:15:44

感谢您的注意，我固定了名称。 – mfx 2009-08-23 19:51:35

仔细考虑你的目标。你只是想替换COM基础吗？您是否也要更改数据库实现（例如，从索引到SQL？）屏幕（从GUI到Web？）...？

如果这是一个非常小的应用程序，可能会完全用手重写它。如果大小适中，您可能可以修改现有的应用程序（大概是用一些其他等效的方案替换COM设施）。如果这是中到大的话，你实际上不可能在合理的时间范围内可靠地重写或修改它。

对于如此大规模的更改，您可能需要考虑自动化更改。实现这种变化的工具可以在这里找到：DMS Software Reengineering Toolkit。对于拥有800K SLOC C++代码的客户，使用DMS，我们实现了C++到C＃转换程序的大部分功能，该功能用等效的C＃工具代替了COM接口（鸟笼管理混洗约3/4通过项目失去了兴趣译者尽管接近完整）。

当你这样做时需要考虑的一件事：在不改变功能的情况下，专注于现代化应用程序。通常管理层无法抵挡范围蔓延（“好吧，当我们在那里时，让我们改变应用去做......”），这是通向灾难的道路。请记住，做出所有导致当前问题的变化需要花费数年时间。

来源

2009-08-22 11:18:58

用于重建传统应用程序的策略

回答

相关问题