所以我们在项目中有这个巨大的mainmodule.cpp源文件(11000行很大吗?)，每次我不得不触摸它时，我都会畏缩。
由于这个文件是如此的核心和大，它不断积累越来越多的代码，我想不出一个好方法来让它实际上开始缩小。
该文件在我们产品的几个(> 10)维护版本中被使用和积极更改，因此很难重构它。如果我“简单地”将其拆分为3个文件，那么从维护版本合并回更改将成为一场噩梦。而且，如果您拆分具有如此长而丰富历史的文件，跟踪和检查SCC历史中的旧更改突然变得非常困难。
这个文件基本上包含了我们程序的“主类”(主要的内部工作调度和协调)，所以每次添加一个特性，它也会影响这个文件，每次它的增长。：-(
在这种情况下你会怎么做?关于如何在不打乱SCC工作流程的情况下将新特性移动到单独的源文件中，您有什么想法吗?
(注意:我们使用c++和Visual Studio;我们使用AccuRev作为SCC，但我认为SCC的类型在这里并不重要;我们使用Araxis Merge来做实际的文件比较和合并)
当前回答
一个重要的建议:不要将重构和错误修复混合在一起。您需要的是程序的版本与以前的版本相同，只是源代码不同。
一种方法是开始将最小的函数/部分分割到它自己的文件中，然后使用头文件include(从而将main.cpp转换为#includes列表，这本身听起来有点代码味道*尽管我不是c++专家)，但至少现在它被分割为文件)。
然后，您可以尝试将所有维护版本切换到“新的”main.cpp或任何您的结构。再次重申:没有其他更改或错误修复，因为跟踪这些是令人困惑的地狱。
另一件事:尽管您可能希望一次性完成整个重构，但您可能会贪多嚼不烂。也许只是选择一两个“部分”，把它们放到所有的版本中，然后为你的客户增加一些更多的价值(毕竟，重构并不会直接增加价值，所以它是一种成本，必须被证明是合理的)，然后再选择另外一两个部分。
显然，这需要团队中的一些纪律来实际使用拆分文件，而不是一直向main.cpp中添加新内容，但是，尝试进行一次大规模的重构可能不是最佳的行动方案。
其他回答
您不应该关注如何减小文件大小，而应该关注如何减小类大小。这几乎是一样的，但让你从不同的角度看问题(正如@Brian Rasmussen所建议的，你的类似乎有很多责任)。
“这个文件基本上包含了我们程序的‘主类’(主要的内部工作调度和协调)，所以每次添加一个特性，它也会影响这个文件，每次它的增长。”
如果这个大的SWITCH(我认为是有的)成为主要的维护问题，你可以重构它，使用字典和命令模式，并从现有的代码中删除所有的开关逻辑到加载器，加载器填充该映射，即:
// declaration
std::map<ID, ICommand*> dispatchTable;
...
// populating using some loader
dispatchTable[id] = concreteCommand;
...
// using
dispatchTable[id]->Execute();
我的同情-在我以前的工作中，我遇到过类似的情况，一个文件比你必须处理的文件大几倍。解决方案是:
编写代码详尽地测试程序中的函数。听起来你还没有掌握这个… 确定一些可以抽象为帮助器/实用程序类的代码。不需要很大，只是一些不是你的“主要”类的真正一部分。 重构2中确定的代码。进入一个单独的班级。 重新运行测试，以确保没有损坏。 当你有时间的时候，去2。并根据需要重复以使代码易于管理。
在第3步中构建的类。迭代可能会增加以吸收更多适合于新清除的函数的代码。
我还可以补充:
0:购买Michael Feathers关于使用遗留代码的书
不幸的是，这种类型的工作太常见了，但我的经验是，在保持工作的同时，能够使工作但可怕的代码逐渐变得不那么可怕是有很大价值的。
下面是我所想到的解决这些问题的唯一办法。所述方法的实际增益是演化的累进性。这里没有革命，否则你很快就会陷入麻烦。
在原来的主类上面插入一个新的cpp类。目前，它基本上会将所有调用重定向到当前的主类，但目标是使这个新类的API尽可能清晰和简洁。
一旦完成了这些，就可以在新类中添加新功能。
至于现有的功能，当它们变得足够稳定时，您必须逐步将它们移动到新的类中。对于这段代码，您将失去SCC帮助，但是对此没有太多办法。只要选择合适的时机。
我知道这并不完美，但我希望它能有所帮助，这个过程必须适应您的需要!
额外的信息
注意，Git是一个SCC，它可以从一个文件跟踪代码片段到另一个文件。我听说过关于它的好东西，所以它可以帮助你逐步转移你的工作。
Git是围绕blob的概念构建的，如果我理解正确的话，blob表示代码文件的片段。在不同的文件中移动这些片段，Git会找到它们，即使您修改了它们。除了下面评论中提到的Linus Torvalds的视频之外，我还没有找到关于这个问题的一些清楚的东西。
我发现这句话是你帖子中最有趣的部分:
>该文件在我们产品的几个(> 10)维护版本中被使用和积极更改，因此很难重构它
首先，我建议您使用源代码控制系统来开发这10多个支持分支的维护版本。
其次，我将创建10个分支(每个分支对应一个维护版本)。
我已经感觉到你在畏缩了!但是，要么是因为缺少特性，你的源代码控制不能满足你的情况，要么是因为它没有被正确地使用。
现在来看看您正在处理的分支——按照您认为合适的方式对其进行重构，确保不会打乱产品的其他九个分支。
我有点担心你的main()函数中有这么多。
在我编写的任何项目中，我都会使用main()只执行核心对象的初始化——比如模拟或应用程序对象——这些类才是真正的工作应该进行的地方。
我还将在main中初始化一个应用程序日志对象，以便在整个程序中全局使用。
最后，在main中，我还在预处理器块中添加了泄漏检测代码，以确保它只在DEBUG版本中启用。这是我要添加到main()的所有内容。Main()应该很短!
你这么说
>该文件基本包含了我们程序的“主类”(主要的内部工作调度和协调)
听起来这两个任务可以分成两个单独的对象——一个协调器和一个工作分派器。
当你把它们分开的时候，你可能会弄乱你的“SCC工作流”，但是听起来像严格遵守你的SCC工作流会导致软件维护问题。抛弃它，现在就不要回头，因为一旦你解决了它，你就会开始睡得很舒服。
如果您不能做出决定，那么就与您的经理进行激烈的斗争——您的应用程序需要重构——听起来很糟糕!不要接受拒绝!
