我继承了一个用C ++（VS2003）MFC编写的遗留应用程序，该应用程序多年未更新。 我在C ++方面经验有限，主要是Delphi开发人员。该公司的所有其他应用程序都是用Delphi编写的。
展望未来，我看到了一些选择：
1）保持应用程序不变，成为C ++ MFC开发人员。但我不喜欢在未来几年使用过时技术（MFC）的想法，试图跟上新的Windows版本和UI标准。它在某种程度上感觉就像倒退了几步，我不认为这是最好的方式（？）
2）将应用程序转换为C ++提供的任何现代UI技术，并成为C ++开发人员，但至少使用现代技术。可能需要做很多工作，不确定。
3）在Delphi中从头开始重建应用程序，在那里我将更加高效地思考未来。现在这项工作要多得多，但以后可能会有所回报。
显然，我个人更喜欢3）但我想从您的经验中了解哪种方式最适合该产品。
这是一个长期的决定，我必须坚持下去，因此我不想匆匆走向一个方向。
（我故意不将此问题标记为C ++，试图在类似情况下从Delphi开发人员那里获得答案）
修改
感谢大家的回答。
在得知可以使用MFC应用程序切换到C ++ Builder之后，这似乎是最好的解决方案。
它结合了对当前应用程序的最少量修改，可以使用VCL继续进行GUI改进。
EDIT2：
在一个应用程序中组合MFC和VCL是不可能的，因此C ++ Builder不是一个选项。 （感谢大卫指出这一点）
答案 0 :(得分：5)
一般来说，一切都取决于应用程序逻辑的复杂程度以及应用程序的预计生命周期。如果需要再维护20年，那么 我在Delphi中重写了UI并将业务逻辑移动到C ++ DLL中（开始并可能在Delphi中重写它）。然后可以将应用程序以这种方式维护10年，并且如果需要可以相对容易地移植到其他平台（需要的工作量更少）。
答案 1 :(得分：3)
保持应用程序不变，将你绑定到MFC，可能效率不高 - 你需要学习一个你很可能永远不会用于其他东西的GUI工具包（Delphi 很棒对于GUI，除了新语言之外，MFC甚至没有接近IMO）。
这使您可以选择使用不熟悉的GUI工具包以一种不熟悉的语言重写它，这比使用熟悉的GUI工具包以熟悉的语言重写它需要花费更多的时间。所以你应该开始将它移植到Delphi。
答案 2 :(得分：3)
这是一个难以回答的问题。您能否提供有关特定应用的更多信息？它使用什么样的技术？ UI与底层和逻辑的区别是什么？
虽然有些普遍观点：
重写应用程序通常是一个坏主意，原因如下：
很难准确了解要求。你确定你知道它做了什么（毕竟，它就在你面前！）然后你释放你的重写应用程序然后你抱怨你不知道的功能是否缺失，功能更难如果你改变了某些东西就可以访问
它引入了错误。代码，特别是如果它已经陈旧，充满了错误修正，调整等。如果你重写，你将失去所有这些，特别是如果它是一种不同的语言，你根本不能重用任何代码。
当使用不同的UI层（MFC与其他东西）时，如果首先没有很好地编写应用程序，那么分离UI可能会非常困难。你可能最终会进行大量的重构，即使你没有完全重写，只需从MFC转移到“别的东西”。
MFC保持最新（ish） - 例如，MFC Ribbon control以及modern controls和Windows 7 support。可能最少的工作是升级到现代版本的Visual C ++并成为C ++开发人员。但是，你说MFC是一项古老的技术并且使用起来不方便，这不仅是因为它的设计，还因为现代表格设计师等很好用。
您是Delphi开发人员。如果不重写整个内容，您可以考虑迁移到C ++ Builder。考虑一下：
您可以在C ++ Builder中使用旧版本的MFC。我从来没有这样做过，因为VCL领先一步，但它有可能并且有很多人这样做。例如，查看this forum。 （相信该链接：this thread。）
一旦您的应用程序编译并使用C ++ Builder，您就可以开始迁移到VCL。作为Delphi开发人员，您会发现使用它，即使使用C ++，也非常熟悉。它当然是相同的表单设计器，并且从C ++使用它非常简单 - 它是一种不同的语言，但代码通常是逐行可转换的。你习惯的一切（DFM文件，单位，事件处理程序等）都可以翻译。
不仅如此， Delphi代码可以在C ++项目中使用。只需将单元添加到项目中，并在C ++代码中包含自动生成的unitname.hpp文件。 You can't (easily) use C++ code from Delphi，但您可以在Delphi中创建新模块并从C ++中使用它们。当你这样做时，越来越多的你的应用程序将慢慢成为Delphi代码 - 也就是说，你不需要一次性用另一种语言重写。
作为Delphi开发人员，我建议使用C ++ Builder路由。让它使用MFC，然后将窗口迁移到VCL。那时，您可以开始在Delphi中重写模块，或者您可能会发现自己在C ++中已经足够开心以继续开发。
编辑：我在上面的回复中注意到你喜欢上面的使它成为C ++ DLL的想法。我在using C++ object from Delphi上面给出一段或两段的链接可能比我想象的更合适。它也适合RAD Studio（C ++和Delphi的混合）方法。
答案 3 :(得分：2)
在Delphi中重写C ++代码并不像你想象的那么容易。重写它的一个更好的方法是从头开始重新设计它，而不需要查看旧代码。随意查看旧应用程序的工作原理，以便重建它。只是不要看代码。这样，你应该得到一个更现代的结果
当然，如果您使用RAD Studio，那么您同时拥有C ++作为Delphi编译器，因此它应该能够继续开发C ++应用程序，尽管这意味着您必须学习C ++。然后，任何优秀的程序员都应该能够转移到另一种编程语言并学习在2周到一个月内使用它。 C ++可能很复杂，但是，学习C ++然后维护遗留应用程序应该比完全重写花费更少的时间。
请记住，任何通用C ++应用程序都应该能够针对任何平台进行编译，尽管MFC可能会将此限制为仅限于Windows。不过，它是一种比Delphi具有更好的向后兼容性的语言！
但请记住，这个应用程序将来会在不同的平台上运行吗？它应该成为.NET应用程序吗？还是在Linux上运行？它应该支持平板电脑吗？ Android的？你今天的选择可能会在两年后再次过时。而且由于Delphi目前的未来有点不确定，主要是因为C＃/ .NET变得如此受欢迎，你可能会更安全地使用C ++。尝试使用更现代的UI技术替换MFC库，最好是可用于多个平台的UI技术，并且非常非常地考虑该应用程序的未来用途。
答案 4 :(得分：1)
我推荐
1）保持应用程序不变，成为C ++ MFC开发人员。但我不喜欢在未来几年使用过时技术（MFC）的想法，试图跟上新的Windows版本和UI标准。它在某种程度上感觉就像倒退了几步，我不认为这是最好的方式（？）
由于MFC得到了很好的支持并且时间紧迫。 MFC也是一个你称之为侵入式框架，这意味着框架依赖性通常不容易重构。 （CPPDepend的作者在IIRC上发表了一些不错的统计数据，但我可以根据自己对大型MFC应用程序的经验来证明这一点。）
如果您要重写任何现代UI框架，不要用C ++编写UI （从Delphi是一个选项的事实来看，它不是关于实时可视化或类似的东西这一点）。
（我将在这里解开未提出的问题：我要改写，XXXXXXXXXXXXX？） 请温柔（我）男人，让我们不要做火焰
答案 5 :(得分：1)
总的来说，我会说：
如果它是一个很小的工具应用程序，只需要几天就可以完全重写：去吧。不要浪费时间创建DLL包装器或以其他方式与现有代码交互。只需完全重写即可完成。
否则：您可能只会在应用程序的某个特定区域进行更改。除非代码是一个完整的意大利面条，否则你甚至可以在不完全理解其余代码的实现细节的情况下进行一些本地更改。
无论如何，您需要花一些时间来理解应用程序及其语言+框架。
答案 6 :(得分：1)
您有很好的机会学习C ++和MFC。利用它。当Delphi误入歧途时，您将掌握必要的知识，继续使用一种不会轻易消失的语言进行编码，甚至可以将您的开发视野拓展到Delphi（和C ++ Builder）永远无法达到的领域。 MFC并不比VCL更过时（虽然我同意原设计更糟）。 良好的UI编程与在视觉上删除窗体上的控件的能力无关。许多优秀的应用程序都没有这样构建。实际上，只要Embarcadero缓慢提供，并且没有可靠的路线图，尝试在Delphi中重写它可能会给你带来问题。
答案 7 :(得分：0)
该应用程序是否具有下降量的自动化测试？如果不是，你几乎坚持选项1并希望最好。如果有很多测试，你可以用代码做更多的事情，而不会破坏那些你不知道的东西。