我发现有一件事很有用(我现在正在做，尽管没有达到你所面临的规模)，那就是将方法提取为类(方法对象重构)。不同版本中不同的方法将成为不同的类，这些类可以被注入到公共库中，以提供您所需的不同行为。

我想在这种情况下我该做的就是咬紧牙关

Figure out how I wanted to split the file up (based on the current development version) Put an administrative lock on the file ("Nobody touch mainmodule.cpp after 5pm Friday!!!" Spend your long weekend applying that change to the >10 maintenance versions (from oldest to newest), up to and including the current version. Delete mainmodule.cpp from all supported versions of the software. It's a new Age - there is no more mainmodule.cpp. Convince Management that you shouldn't be supporting more than one maintenance version of the software (at least without a big $$$ support contract). If each of your customers have their own unique version.... yeeeeeshhhh. I'd be adding compiler directives rather than trying to maintain 10+ forks.

跟踪文件的旧更改简单地通过您的第一个签入注释来解决，例如“从mainmodule.cpp分离”。如果你需要回顾最近的东西，大多数人会记得这个变化，如果是2年后，评论会告诉他们从哪里看。当然，回溯到2年前，看看是谁修改了代码以及为什么修改代码，这有多大价值呢?

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

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

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

我的0.05欧分:

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

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

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

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

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

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

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

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

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

一种不太危险的方法是对所有的线变化进行历史性的观察。有没有特定的函数比其他函数更稳定?可以说是变化的热点。

如果某一行在几年内没有被更改过，你可以将它移到另一个文件中，而不用太担心。我会看一下用最后一次修改注释的源代码，看看是否有任何函数可以提取出来。