所以我们在项目中有这个巨大的mainmodule.cpp源文件(11000行很大吗?)，每次我不得不触摸它时，我都会畏缩。
由于这个文件是如此的核心和大，它不断积累越来越多的代码，我想不出一个好方法来让它实际上开始缩小。
该文件在我们产品的几个(> 10)维护版本中被使用和积极更改，因此很难重构它。如果我“简单地”将其拆分为3个文件，那么从维护版本合并回更改将成为一场噩梦。而且，如果您拆分具有如此长而丰富历史的文件，跟踪和检查SCC历史中的旧更改突然变得非常困难。
这个文件基本上包含了我们程序的“主类”(主要的内部工作调度和协调)，所以每次添加一个特性，它也会影响这个文件，每次它的增长。：-(
在这种情况下你会怎么做?关于如何在不打乱SCC工作流程的情况下将新特性移动到单独的源文件中，您有什么想法吗?
(注意:我们使用c++和Visual Studio;我们使用AccuRev作为SCC，但我认为SCC的类型在这里并不重要;我们使用Araxis Merge来做实际的文件比较和合并)
当前回答
我认为在拆分文件时跟踪源文件历史的最简单的方法是这样的:
使用SCM系统提供的任何保存历史的拷贝命令来复制原始源代码。此时您可能需要提交，但还不需要告诉构建系统关于新文件的信息，因此这应该是可以的。 从这些副本中删除代码。这应该不会打破你所保持的历史。
其他回答
合并不会像将来获得30000个LOC文件那样是一个大噩梦。所以:
停止向该文件添加更多代码。 把它。
如果你不能在重构过程中停止编码，你可以暂时保留这个大文件，至少不向它添加更多的代码:因为它包含一个“主类”，你可以从它继承，并将继承的带有重载函数的类保留在几个新的小而设计良好的文件中。
我想在这种情况下我该做的就是咬紧牙关
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年前，看看是谁修改了代码以及为什么修改代码，这有多大价值呢?
这并不是一个大问题的答案，而是一个具体问题的理论解决方案:
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文件历史，我认为最好的方法是告诉您的源代码控制系统各个片段文件都是原始文件的副本。然后，它将保存该文件中保存的部分的历史，当然，它也将记录大部分被“删除”。
所以从一开始重写产品代码的API是一个坏主意。需要做两件事。
首先，您需要让您的团队决定对该文件的当前生产版本进行代码冻结。
第二，您需要使用这个生产版本并创建一个分支，该分支使用预处理指令来管理构建，以分割大文件。使用JUST预处理器指令(#ifdefs， #includes， #endifs)拆分编译比重新编码API更容易。对于您的sla和持续的支持来说，这绝对更容易。
在这里，您可以简单地删除类中与特定子系统相关的函数，并将它们放在一个文件(例如mainloop_foostuff.cpp)中，并将其包含在mainloop.cpp中的正确位置。
OR
一种更耗时但健壮的方法是设计一个内部依赖关系结构，在包含内容的方式上具有双重间接性。这将允许您分割内容，并仍然照顾到共同依赖关系。注意，这种方法需要位置编码，因此应该加上适当的注释。
这种方法将包括基于您正在编译的变体而使用的组件。
基本结构是mainclass.cpp将在如下语句块后包含一个名为MainClassComponents.cpp的新文件:
#if VARIANT == 1
# define Uses_Component_1
# define Uses_Component_2
#elif VARIANT == 2
# define Uses_Component_1
# define Uses_Component_3
# define Uses_Component_6
...
#endif
#include "MainClassComponents.cpp"
MainClassComponents.cpp文件的主要结构将在那里计算子组件中的依赖关系，如下所示:
#ifndef _MainClassComponents_cpp
#define _MainClassComponents_cpp
/* dependencies declarations */
#if defined(Activate_Component_1)
#define _REQUIRES_COMPONENT_1
#define _REQUIRES_COMPONENT_3 /* you also need component 3 for component 1 */
#endif
#if defined(Activate_Component_2)
#define _REQUIRES_COMPONENT_2
#define _REQUIRES_COMPONENT_15 /* you also need component 15 for this component */
#endif
/* later on in the header */
#ifdef _REQUIRES_COMPONENT_1
#include "component_1.cpp"
#endif
#ifdef _REQUIRES_COMPONENT_2
#include "component_2.cpp"
#endif
#ifdef _REQUIRES_COMPONENT_3
#include "component_3.cpp"
#endif
#endif /* _MainClassComponents_h */
现在，为每个组件创建一个component_xx.cpp文件。
当然，我使用数字，但你应该使用一些更符合逻辑的基于你的代码。
使用预处理器可以让你把事情分开，而不必担心API的变化，这在生产中是一个噩梦。
一旦你确定了产品，你就可以开始重新设计了。
这是一个困难而有趣的重构。
首先，将实现与接口分离。将这个巨大的文件转换为一个只转发调用和参数的空shell。这样，你可以创建责任有限的组件，而不会影响任何调用者(他们仍然调用巨大的文件/模块/类)。
为了做到这一点，您还需要寻找新的潜在组件的创建时间。根据构造函数的发送方式，在拥有所有参数之前，对参数进行堆叠可能非常棘手。
然后，您可以查找调用者并让他们调用您的组件。这是简单的部分。
