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

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

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

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

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

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

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

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

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

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

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

这让我想起了我以前的工作。似乎，在我加入之前，所有东西都在一个巨大的文件中(也是c++)。然后他们将其拆分(在完全随机的点上使用include)为大约三个(仍然是巨大的文件)。正如你所预料的那样，这个软件的质量非常糟糕。该项目总标线约为40k。(几乎没有注释，但有大量重复代码)

最后，我完全重写了这个项目。我从头开始重做项目中最糟糕的部分。当然，我想到了这个新部分和其他部分之间可能的(小)接口。然后我把这个部分插入到旧的项目中。我没有重构旧代码来创建必要的接口，只是替换了它。然后我从那里迈出了一小步，重写了旧代码。

我不得不说，这花了大约半年的时间，在此期间，除了修复错误之外，没有开发旧的代码库。

编辑:

它的大小保持在40k LOC左右，但与8年前的软件相比，新应用程序在初始版本中包含了更多的功能，可能bug也更少。重写的一个原因是我们需要新的特性，而在旧代码中引入这些特性几乎是不可能的。

该软件是为一个嵌入式系统，一个标签打印机。

我应该补充的另一点是，理论上这个项目是c++的。但它根本不是面向对象的，它可能是c。新版本是面向对象的。

这并不是一个大问题的答案，而是一个具体问题的理论解决方案:

Figure out where you want to split the big file into subfiles. Put comments in some special format at each of those points. Write a fairly trivial script that will break the file apart into subfiles at those points. (Perhaps the special comments have embedded filenames that the script can use as instructions for how to split it.) It should preserve the comments as part of the splitting. Run the script. Delete the original file. When you need to merge from a branch, first recreate the big file by concatenating the pieces back together, do the merge, and then re-split it.

另外，如果您想要保存SCC文件历史，我认为最好的方法是告诉您的源代码控制系统各个片段文件都是原始文件的副本。然后，它将保存该文件中保存的部分的历史，当然，它也将记录大部分被“删除”。