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

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

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

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

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

额外的信息

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

你这么说

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

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

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

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

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

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年前，看看是谁修改了代码以及为什么修改代码，这有多大价值呢?

在我看来，您现在面临的是一堆代码异味。首先，主类似乎违反了开/闭原则。这听起来也像是承担了太多责任。因此，我认为代码比实际需要的更加脆弱。

虽然我可以理解您对重构后可跟踪性的担忧，但我认为该类相当难以维护和增强，而且您所做的任何更改都可能导致副作用。我假设这些的成本超过了重构类的成本。

在任何情况下，由于代码气味只会随着时间的推移而变得更糟，至少在某些时候，这些成本将超过重构的成本。根据你的描述，我认为你已经过了临界点。

重构应该分小步骤进行。如果可能的话，在重构任何东西之前添加自动测试来验证当前行为。然后挑选出独立功能的小区域，并将其提取为类型，以便委派职责。

无论如何，这听起来像是一个大项目，所以祝你好运:)

我猜一下，如果这段代码为10个客户服务，并且包含代码变体，那么您可能有很多针对特定客户的带有变体的代码克隆

我很想对你的11000行文件进行克隆检测。(事实上，如果你把它发给我，我会用我的c++克隆检测器[见生物]，并把答案发给你)。

这将显示任何克隆，以及这些克隆是如何变化的。有了这些信息，重构代码就变得相当容易了。