所以我们在项目中有这个巨大的mainmodule.cpp源文件(11000行很大吗?)，每次我不得不触摸它时，我都会畏缩。
由于这个文件是如此的核心和大，它不断积累越来越多的代码，我想不出一个好方法来让它实际上开始缩小。
该文件在我们产品的几个(> 10)维护版本中被使用和积极更改，因此很难重构它。如果我“简单地”将其拆分为3个文件，那么从维护版本合并回更改将成为一场噩梦。而且，如果您拆分具有如此长而丰富历史的文件，跟踪和检查SCC历史中的旧更改突然变得非常困难。
这个文件基本上包含了我们程序的“主类”(主要的内部工作调度和协调)，所以每次添加一个特性，它也会影响这个文件，每次它的增长。：-(
在这种情况下你会怎么做?关于如何在不打乱SCC工作流程的情况下将新特性移动到单独的源文件中，您有什么想法吗?
(注意:我们使用c++和Visual Studio;我们使用AccuRev作为SCC，但我认为SCC的类型在这里并不重要;我们使用Araxis Merge来做实际的文件比较和合并)
当前回答
这让我想起了我以前的工作。似乎，在我加入之前，所有东西都在一个巨大的文件中(也是c++)。然后他们将其拆分(在完全随机的点上使用include)为大约三个(仍然是巨大的文件)。正如你所预料的那样，这个软件的质量非常糟糕。该项目总标线约为40k。(几乎没有注释，但有大量重复代码)
最后，我完全重写了这个项目。我从头开始重做项目中最糟糕的部分。当然，我想到了这个新部分和其他部分之间可能的(小)接口。然后我把这个部分插入到旧的项目中。我没有重构旧代码来创建必要的接口，只是替换了它。然后我从那里迈出了一小步，重写了旧代码。
我不得不说，这花了大约半年的时间，在此期间，除了修复错误之外，没有开发旧的代码库。
编辑:
它的大小保持在40k LOC左右，但与8年前的软件相比，新应用程序在初始版本中包含了更多的功能，可能bug也更少。重写的一个原因是我们需要新的特性，而在旧代码中引入这些特性几乎是不可能的。
该软件是为一个嵌入式系统，一个标签打印机。
我应该补充的另一点是，理论上这个项目是c++的。但它根本不是面向对象的，它可能是c。新版本是面向对象的。
其他回答
Find some code in the file which is relatively stable (not changing fast, and doesn't vary much between branches) and could stand as an independent unit. Move this into its own file, and for that matter into its own class, in all branches. Because it's stable, this won't cause (many) "awkward" merges that have to be applied to a different file from the one they were originally made on, when you merge the change from one branch to another. Repeat. Find some code in the file which basically only applies to a small number of branches, and could stand alone. Doesn't matter whether it's changing fast or not, because of the small number of branches. Move this into its own classes and files. Repeat.
因此，我们去掉了到处都一样的代码，以及特定于某些分支的代码。
This leaves you with a nucleus of badly-managed code - it's needed everywhere, but it's different in every branch (and/or it changes constantly so that some branches are running behind others), and yet it's in a single file that you're unsuccessfully trying to merge between branches. Stop doing that. Branch the file permanently, perhaps by renaming it in each branch. It's not "main" any more, it's "main for configuration X". OK, so you lose the ability to apply the same change to multiple branches by merging, but this is in any case the core of code where merging doesn't work very well. If you're having to manually manage the merges anyway to deal with conflicts, then it's no loss to manually apply them independently on each branch.
我认为你说这种SCC无关紧要是错误的，因为例如git的合并能力可能比你正在使用的合并工具更好。因此，核心问题“合并困难”发生在不同scc的不同时期。但是，您不太可能更改scc，因此这个问题可能无关紧要。
好吧，我理解你的痛苦:)我也参与过一些这样的项目，它并不漂亮。这个问题没有简单的答案。
一种可行的方法是开始在所有函数中添加安全保护，也就是说，检查方法中的参数、前置/后置条件，然后最终添加单元测试，以便捕获源的当前功能。一旦你有了这些，你就可以更好地重构代码，因为如果你忘记了什么，你就会有断言和错误弹出来提醒你。
有时候，重构带来的痛苦可能会大于好处。那么，最好是让原始项目处于伪维护状态，从头开始，然后增量地添加野兽的功能。
孔子说:“出洞的第一步是停止挖洞。”
您不应该关注如何减小文件大小，而应该关注如何减小类大小。这几乎是一样的，但让你从不同的角度看问题(正如@Brian Rasmussen所建议的，你的类似乎有很多责任)。
在我看来，您现在面临的是一堆代码异味。首先，主类似乎违反了开/闭原则。这听起来也像是承担了太多责任。因此，我认为代码比实际需要的更加脆弱。
虽然我可以理解您对重构后可跟踪性的担忧，但我认为该类相当难以维护和增强，而且您所做的任何更改都可能导致副作用。我假设这些的成本超过了重构类的成本。
在任何情况下，由于代码气味只会随着时间的推移而变得更糟，至少在某些时候，这些成本将超过重构的成本。根据你的描述，我认为你已经过了临界点。
重构应该分小步骤进行。如果可能的话，在重构任何东西之前添加自动测试来验证当前行为。然后挑选出独立功能的小区域，并将其提取为类型，以便委派职责。
无论如何，这听起来像是一个大项目，所以祝你好运:)
