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

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

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

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

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

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

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

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

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

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

你这么说

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

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

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

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

我不知道这是否解决了您的问题，但我猜您想要做的是将文件的内容迁移到彼此独立的更小的文件中(合计)。 我还了解到，你有大约10个不同版本的软件，你需要在不搞砸的情况下支持它们。

首先，这是不可能的简单，将解决自己在几分钟的头脑风暴。文件中链接的函数对应用程序都非常重要，简单地将它们删除并迁移到其他文件中并不能解决问题。

我认为你只有这些选择:

Don't migrate and stay with what you have. Possibly quit your job and start working on serious software with good design in addition. Extreme programming is not always the best solution if you are working on a long time project with enough funds to survive a crash or two. Work out a layout of how you would love your file to look once it's split up. Create the necessary files and integrate them in your application. Rename the functions or overload them to take an additional parameter (maybe just a simple boolean?). Once you have to work on your code, migrate the functions you need to work on to the new file and map the function calls of the old functions to the new functions. You should still have your main-file this way, and still be able to see the changes that were made to it, once it comes to a specific function you know exactly when it was outsourced and so on. Try to convince your co-workers with some good cake that workflow is overrated and that you need to rewrite some parts of the application in order to do serious business.

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

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

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

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

“这个文件基本上包含了我们程序的‘主类’(主要的内部工作调度和协调)，所以每次添加一个特性，它也会影响这个文件，每次它的增长。”

如果这个大的SWITCH(我认为是有的)成为主要的维护问题，你可以重构它，使用字典和命令模式，并从现有的代码中删除所有的开关逻辑到加载器，加载器填充该映射，即:

    // declaration
    std::map<ID, ICommand*> dispatchTable;
    ...

    // populating using some loader
    dispatchTable[id] = concreteCommand;

    ...
    // using
    dispatchTable[id]->Execute();

您不应该关注如何减小文件大小，而应该关注如何减小类大小。这几乎是一样的，但让你从不同的角度看问题(正如@Brian Rasmussen所建议的，你的类似乎有很多责任)。