我有三个共享大量源代码和数据的遗留应用程序。用户可以随时执行这些应用程序中的每一个的多个实例，例如，一次可以激活十几个混合应用程序执行。这些应用程序目前通过共享内存和消息传递技术进行通信，以便它们可以保持公共光标定位等。这些应用程序主要用 C++ 编写，使用 Qt，总共运行约 500 万行代码。只有一些现有代码是线程安全的。
我想将这三个可执行文件合并到一个可执行文件中，并使用多线程功能来允许三个功能分支中的每一个的多个实例同时执行。有人建议我研究 Boost 提供的一些特性，例如共享指针，并使用 OpenMP 来协调多个线程的整体执行。
任何有关如何进行的评论都将受到赞赏，特别是有关解决此类重构问题的最佳方法的参考。
我对您的建议是首先设计所需的解决方案（首先假设需求相同），然后根据第三方功能可能引入的需求从现有代码库构建分阶段迁移路径。
重构应该是一次一小步——但要知道你要去哪里。
有效地处理遗留代码（Robert C. Martin 系列）将是我建议的好读物。
相信我（我有 T 恤），除非您知道如何证明功能，否则不要尝试重构 - 自动验证测试将是您的救星。
我认为没有人能够给你一个明智的答案。有太多的事情需要考虑。只有在仔细分析了所涉及的过程和背后的代码之后，任何人（包括您）才能为您提供项目路径。
也就是说，您应该考虑一些事项。
在我看来，您的应用程序以及它们似乎相互通信的方式似乎已经是一个合理的解决方案。确实如此，尤其是因为如果您选择重构当前系统，您有 500 万行代码需要处理。这是一个强大的威慑。如果需要提供线程支持以优化当前的应用程序消息传递，我可能会建议您考虑将 MT 引入共享内存和消息传递例程的可能性，而不是合并应用程序。
合并应用程序的行为乍一看可以看作是粘合当前代码并删除当前负责内存共享和消息传递的例程的“简单”行为，用对粘合对象的正常函数调用替换它们。我的直觉告诉我，事情不会那么简单。您必须考虑到几乎可以肯定您当前的主干代码是为当前的消息传递解决方案设计的。您当前的抽象是考虑到这一点的。您几乎肯定会发现您还需要对现有的主干代码进行重大更改。再次在这里，您会发现那堵 500 万行的墙是个大问题。因为更改会迅速传播到您的整个系统，并留下 500 万行代码需要处理，而且天知道有多少新错误。
我建议上面的1。但您可能出于某种原因确实需要整合您的应用程序。既然如此，在您尝试之前，我仍然会建议其他内容 2. 创建一个界面应用程序，负责启动、显示和维护当前的 3 个应用程序。如果你做对了，你的用户不会知道得更好。尽管它们实际上是独立的实体，但您仍然可以将 1 应用到当前系统并在通用界面下加入您的应用程序。