我即将推出一项新任务，我将在.Net WPF中重新构建一些传统的COM应用程序。如果可能的话，我需要重用功能或现有代码，但我怀疑这个范围是有限的。
我需要复制现有功能，但需要使用现代且可扩展的架构来实现它。
是否有人对接近此类项目有任何一般性建议？这个问题有什么好的资源吗？
有没有经过试验和测试的技术或普通的pifalls？
答案 0 :(得分：4)
最重要的是自动验证（也就是单元/功能测试）。请参阅this question。正如很多建议将是simillar。
通过这个我并不是说为新系统编写测试，我的意思是编写传递旧系统的测试并将通过新系统。这将是您验证是否已重新创建原始功能的方法。我认为在已经存在的系统中，您可以非常轻松地（尽管繁琐地）以functional specs that could be executed样式创建BDD。
答案 1 :(得分：3)
我会说一个常见的陷阱是试图解决没有破坏的事情。想想如何重新使用现有软件而无需重新发明它。如果它已经存在了很长时间，可能是因为它工作得非常好。您将面临一项重大任务，以便在不引入新错误的情况下匹配功能。
然后，这可能是因为贵公司已经超越了这个遗留系统。想一想为什么要求你重新设计这个以及你需要解决的旧东西的限制。
答案 2 :(得分：3)
Michael Feathers：Working effectively with legacy code提供了许多技术来处理和替换遗留代码。我发现它很可读;一些方法（以及许多黑客攻击）对我来说都是新手。
答案 3 :(得分：3)
仔细考虑您的目标。您是否只对更换COM基础感兴趣？您是否还要更改数据库实现（例如，从索引到SQL？）屏幕（从GUI到Web？）......？
如果这是一个非常小的应用程序，则可以完全手动重写它。如果它是适度的大小，您可能能够修改现有的应用程序（可能是用其他一些等效方案替换COM工具）。如果这是中等到大，您实际上无法在合理的时间范围内可靠地重写或修改它。
对于此类大规模更改，您可能需要考虑自动执行更改。可以在此处找到实现此类更改的工具：DMS Software Reengineering Toolkit。对于具有800K SLOC of C ++代码的客户，使用DMS， 我们实现了大部分的C ++到C＃转换器，用相同的C＃设备取代了COM接口（鸟笼管理随机播放大约3/4的程序，尽管它已经接近完整，但却没有引起对翻译人员的兴趣。）
执行此操作时需要考虑的一件事：继续关注应用程序的现代化而不更改功能。通常管理层无法抵抗范围蔓延（“好吧，我们在那里，让我们改变应用程序做......”）这是通向灾难的道路。请记住，所有导致当前变化的变化需要数年时间。
答案 4 :(得分：2)
请记住，在部署新重新设计的系统时，您很可能必须将整个数据堆从旧数据库转换或移植到新数据库中。当你走的时候考虑这个，因为如果你不这样做，那个工作本身就可以变得像你的重写一样大。从第1天开始，不能很好地，可靠或有效地转换可能会使新系统失效，即使功能已经发挥作用。
答案 5 :(得分：2)
我目前正在做这个事情。
我能给出的最重要的建议是重新规范系统。如果没有对您将提供的产品的一系列期望，您将遵循旧系统的标准。这些标准不是很好，否则你就不会重写它。
从使用当前系统的人员确定他们实际想要完成的内容，并构建那个，而不是直接端口。从长远来看，所涉及的每个人都会变得更好。
除此之外，请勿尝试在此过程中添加功能。在您重新构建应用程序之后，将有机会。在做端口时，没有什么比采用与现有功能相矛盾的新要求更糟糕了。