另一本你可能会觉得有趣/有用的书是《重构》。

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

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

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

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

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

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

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

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

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

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

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

额外的信息

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

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

我发现这句话是你帖子中最有趣的部分:

>该文件在我们产品的几个(> 10)维护版本中被使用和积极更改，因此很难重构它

首先，我建议您使用源代码控制系统来开发这10多个支持分支的维护版本。

其次，我将创建10个分支(每个分支对应一个维护版本)。

我已经感觉到你在畏缩了!但是，要么是因为缺少特性，你的源代码控制不能满足你的情况，要么是因为它没有被正确地使用。

现在来看看您正在处理的分支——按照您认为合适的方式对其进行重构，确保不会打乱产品的其他九个分支。

我有点担心你的main()函数中有这么多。

在我编写的任何项目中，我都会使用main()只执行核心对象的初始化——比如模拟或应用程序对象——这些类才是真正的工作应该进行的地方。

我还将在main中初始化一个应用程序日志对象，以便在整个程序中全局使用。

最后，在main中，我还在预处理器块中添加了泄漏检测代码，以确保它只在DEBUG版本中启用。这是我要添加到main()的所有内容。Main()应该很短!

你这么说

>该文件基本包含了我们程序的“主类”(主要的内部工作调度和协调)

听起来这两个任务可以分成两个单独的对象——一个协调器和一个工作分派器。

当你把它们分开的时候，你可能会弄乱你的“SCC工作流”，但是听起来像严格遵守你的SCC工作流会导致软件维护问题。抛弃它，现在就不要回头，因为一旦你解决了它，你就会开始睡得很舒服。

如果您不能做出决定，那么就与您的经理进行激烈的斗争——您的应用程序需要重构——听起来很糟糕!不要接受拒绝!

永远不要再碰这个文件和代码! 对待就像你被困住了一样。开始为编码在那里的功能编写适配器。 用不同的单元编写新代码，只与封装怪物功能的适配器对话。 ．.． 如果以上只有一项是不可能的，那就辞职去找一份新工作。