2

我有一个新的任务即将到来，我在 .Net WPF 中重新设计了一些旧的 COM 应用程序。如果可能的话，我需要重用功能或现有代码，但是我怀疑这样做的范围是有限的。

我需要复制现有功能，但需要使用现代且可扩展的架构来实现它。

有没有人对处理这种类型的项目有任何一般性建议？有没有关于这个主题的好资源？

是否有任何久经考验的技术或常见的陷阱？

4

6 回答 6

4

最重要的是自动验证（又名单元/功能测试）。请看这个问题。因为很多建议都是相似的。

这里我的意思不是为新系统编写测试，我的意思是编写通过旧系统并将通过新系统的测试。这将是您验证是否已重新创建原始功能的方式。我认为在一个已经存在的系统中，您可以很容易（尽管很乏味）创建可以以 BDD 样式执行的功能规范。

于 2009-08-22T10:19:04.803 回答
3

我想说一个常见的陷阱是试图修复没有损坏的东西。想想如何在不重新发明的情况下重用现有软件。如果它已经存在了很长时间，那可能是因为它运行得非常好。您将面临一项艰巨的任务，即在不引入新错误的情况下匹配功能。

再说一次，这可能是因为您的公司已经超出了这个遗留系统。想想为什么你被要求重新架构这个，以及你需要解决的旧东西有哪些限制。

于 2009-08-22T10:35:49.030 回答
3

Michael Feathers： 有效地使用遗留代码提供了许多使用和替换遗留代码的技术。我发现它很有可读性；一些方法（以及许多技巧）对我来说是新的。

于 2009-08-22T10:56:14.043 回答
3

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

如果这是一个非常小的应用程序，则可以完全手动重写它。如果它的大小适中，您也许可以修改现有的应用程序（大概是用其他等效方案替换 COM 工具）。如果这是中型到大型，您实际上将无法在合理的时间范围内可靠地重写或修改它。

对于如此大规模的更改，您可能需要考虑使更改自动化。可在此处找到实现此类更改的工具： DMS Software Reengineering Toolkit。使用 DMS，对于拥有 800K SLOC 的 C++ 代码的客户，我们实现了大部分 C++ 到 C# 的翻译器，用等效的 C# 工具替换了 COM 接口（鸟笼管理洗牌大约 3/4 的项目结束了对译者尽管其近乎完整）。

执行此操作时要考虑的一件事：在不更改功能的情况下继续关注应用程序的现代化。管理层通常无法抵抗范围蔓延（“好吧，当我们在那里时，让我们更改应用程序来做......”）这是通往灾难的道路。请记住，做出所有导致当前变化的变化需要数年时间。

于 2009-08-22T11:18:58.800 回答
2

请记住，当您部署新重新构建的系统时，您很可能必须将一整堆数据从旧的转换或移植到新的。在你去的时候考虑一​​下，因为如果你不这样做，那项工作可能会变得和你的重写一样大。不能很好、可靠或有效地转换可能会从第一天起就注定你的新系统，即使功能是正确的。

于 2009-08-22T10:40:59.050 回答
2

我目前正在做几乎完全一样的事情。

我能给出的最重要的建议是重新规范系统。如果对您将交付的内容没有新的期望，您将被要求遵守旧系统的标准。这些标准不可能很好，否则你不会重写它。

从使用当前系统的人那里确定他们实际想要完成的任务，并构建它，而不是一个直接的端口。从长远来看，参与其中的每个人都会过得更好。

除此之外，不要尝试在此过程中添加功能。在您重新构建应用程序之后，这个机会就会出现。在进行移植时，没有什么比接受与现有功能相矛盾的新要求更糟糕的了。

于 2009-08-24T01:47:27.287 回答