我的0.05欧分:

重新设计整个混乱的系统，考虑到技术和业务需求，将其拆分为子系统(=许多并行维护轨道，每个并行维护轨道的代码库可能不同，显然需要高可修改性等等)。

在划分子系统时，分析变化最大的地方，并将其与不变的部分分开。这应该会显示出问题所在。将最易变化的部分分离到它们自己的模块中(例如dll)，这样模块API就可以保持完整，而不需要一直破坏BC。这样，如果需要，您可以为不同的维护分支部署不同版本的模块，同时保持核心不变。

重新设计很可能需要一个单独的项目，试图做一个移动的目标是行不通的。

至于源代码历史，我的意见是:为了新代码忘掉它吧。但是请将历史记录保存在某个地方，以便在需要时进行检查。我打赌你开始之后就不那么需要它了。

对于这个项目，您很可能需要得到管理层的支持。你可以用更快的开发时间、更少的bug、更容易的维护和更少的混乱来反驳。类似于“积极地使我们的关键软件资产具有未来的可靠性和维护可行性”:)

至少这是我开始解决问题的方式。

好吧，我理解你的痛苦:)我也参与过一些这样的项目，它并不漂亮。这个问题没有简单的答案。

一种可行的方法是开始在所有函数中添加安全保护，也就是说，检查方法中的参数、前置/后置条件，然后最终添加单元测试，以便捕获源的当前功能。一旦你有了这些，你就可以更好地重构代码，因为如果你忘记了什么，你就会有断言和错误弹出来提醒你。

有时候，重构带来的痛苦可能会大于好处。那么，最好是让原始项目处于伪维护状态，从头开始，然后增量地添加野兽的功能。

合并不会像将来获得30000个LOC文件那样是一个大噩梦。所以:

停止向该文件添加更多代码。 把它。

如果你不能在重构过程中停止编码，你可以暂时保留这个大文件，至少不向它添加更多的代码:因为它包含一个“主类”，你可以从它继承，并将继承的带有重载函数的类保留在几个新的小而设计良好的文件中。

下面是我所想到的解决这些问题的唯一办法。所述方法的实际增益是演化的累进性。这里没有革命，否则你很快就会陷入麻烦。

在原来的主类上面插入一个新的cpp类。目前，它基本上会将所有调用重定向到当前的主类，但目标是使这个新类的API尽可能清晰和简洁。

一旦完成了这些，就可以在新类中添加新功能。

至于现有的功能，当它们变得足够稳定时，您必须逐步将它们移动到新的类中。对于这段代码，您将失去SCC帮助，但是对此没有太多办法。只要选择合适的时机。

我知道这并不完美，但我希望它能有所帮助，这个过程必须适应您的需要!

额外的信息

注意，Git是一个SCC，它可以从一个文件跟踪代码片段到另一个文件。我听说过关于它的好东西，所以它可以帮助你逐步转移你的工作。

Git是围绕blob的概念构建的，如果我理解正确的话，blob表示代码文件的片段。在不同的文件中移动这些片段，Git会找到它们，即使您修改了它们。除了下面评论中提到的Linus Torvalds的视频之外，我还没有找到关于这个问题的一些清楚的东西。

考虑以更合理的方式重写整个应用程序的方法。也许可以重写其中的一小部分作为原型，看看你的想法是否可行。

如果您已经确定了一个可行的解决方案，那么相应地重构应用程序。

如果所有产生更合理架构的尝试都失败了，那么至少您知道解决方案可能是重新定义程序的功能。

首先向它添加注释。参考函数被调用的位置以及是否可以移动物体。这可以让事情动起来。你真的需要评估它的代码基础有多脆弱。然后将公共功能转移到一起。一次做一些小改变。