所以我们在项目中有这个巨大的mainmodule.cpp源文件(11000行很大吗?)，每次我不得不触摸它时，我都会畏缩。
由于这个文件是如此的核心和大，它不断积累越来越多的代码，我想不出一个好方法来让它实际上开始缩小。
该文件在我们产品的几个(> 10)维护版本中被使用和积极更改，因此很难重构它。如果我“简单地”将其拆分为3个文件，那么从维护版本合并回更改将成为一场噩梦。而且，如果您拆分具有如此长而丰富历史的文件，跟踪和检查SCC历史中的旧更改突然变得非常困难。
这个文件基本上包含了我们程序的“主类”(主要的内部工作调度和协调)，所以每次添加一个特性，它也会影响这个文件，每次它的增长。：-(
在这种情况下你会怎么做?关于如何在不打乱SCC工作流程的情况下将新特性移动到单独的源文件中，您有什么想法吗?
(注意:我们使用c++和Visual Studio;我们使用AccuRev作为SCC，但我认为SCC的类型在这里并不重要;我们使用Araxis Merge来做实际的文件比较和合并)
当前回答
你担心文件的大小。
从历史上看，C程序的文件大小是由机器PDP11/40的限制决定的。 我使用的这个可以处理最大4096字节的文件。为了解决这个问题 C编译器使用#include并发明了.h文件来帮助链接器和分段加载器，因为 加载器必须动态交换(因此在Intel架构中使用段寄存器)。
Small files solved the problem but left an historical legacy. Programmers now believe that small files are the only way to program. You have a machine with 4 gigabytes (vs 8 kilobytes on the 11/40). You have a machine with 3 billion instructions per second (vs 500 kilo instructions on the 11/40). You have a compiler that can block optimize code it can see (as opposed to linking .o files which it cannot see). You have a machine that is bandwidth limited by disk I/O but you want to create 500 tiny .c, .h, and .o files, possibly multiple times with the .h includes.
大的C文件绝对没有错。编译器可以大量优化 磁盘I/O最小，链接器时间消失，编辑器可以找到琐碎的东西 一个花哨的IDE，……
11000行对于今天来说是一个微不足道的文件。把自己从历史中解放出来。
其他回答
让我猜猜:10个拥有不同功能集的客户和一个提倡“定制化”的销售经理?我以前做过这样的产品。我们遇到了同样的问题。
您认识到拥有一个巨大的文件是很麻烦的，但更麻烦的是您必须保持10个版本的“最新”。这是多重维护。SCC可以使这更容易，但它不能使它正确。
Before you try to break the file into parts, you need to bring the ten branches back in sync with each other so that you can see and shape all the code at once. You can do this one branch at a time, testing both branches against the same main code file. To enforce the custom behavior, you can use #ifdef and friends, but it's better as much as possible to use ordinary if/else against defined constants. This way, your compiler will verify all types and most probably eliminate "dead" object code anyway. (You may want to turn off the warning about dead code, though.)
一旦所有分支隐式地共享了该文件的一个版本，那么就更容易开始使用传统的重构方法。
#ifdefs主要适用于受影响的代码只在其他分支自定义上下文中有意义的部分。有人可能会说，这也为相同的分支合并方案提供了机会，但不要太疯狂。一次只做一个大项目。
In the short run, the file will appear to grow. This is OK. What you're doing is bringing things together that need to be together. Afterwards, you'll begin to see areas that are clearly the same regardless of version; these can be left alone or refactored at will. Other areas will clearly differ depending on the version. You have a number of options in this case. One method is to delegate the differences to per-version strategy objects. Another is to derive client versions from a common abstract class. But none of these transformations are possible as long as you have ten "tips" of development in different branches.
我认为在拆分文件时跟踪源文件历史的最简单的方法是这样的:
使用SCM系统提供的任何保存历史的拷贝命令来复制原始源代码。此时您可能需要提交，但还不需要告诉构建系统关于新文件的信息，因此这应该是可以的。 从这些副本中删除代码。这应该不会打破你所保持的历史。
在我看来，您现在面临的是一堆代码异味。首先，主类似乎违反了开/闭原则。这听起来也像是承担了太多责任。因此，我认为代码比实际需要的更加脆弱。
虽然我可以理解您对重构后可跟踪性的担忧，但我认为该类相当难以维护和增强，而且您所做的任何更改都可能导致副作用。我假设这些的成本超过了重构类的成本。
在任何情况下，由于代码气味只会随着时间的推移而变得更糟，至少在某些时候，这些成本将超过重构的成本。根据你的描述，我认为你已经过了临界点。
重构应该分小步骤进行。如果可能的话，在重构任何东西之前添加自动测试来验证当前行为。然后挑选出独立功能的小区域，并将其提取为类型，以便委派职责。
无论如何，这听起来像是一个大项目，所以祝你好运:)
我发现有一件事很有用(我现在正在做，尽管没有达到你所面临的规模)，那就是将方法提取为类(方法对象重构)。不同版本中不同的方法将成为不同的类，这些类可以被注入到公共库中，以提供您所需的不同行为。
考虑以更合理的方式重写整个应用程序的方法。也许可以重写其中的一小部分作为原型，看看你的想法是否可行。
如果您已经确定了一个可行的解决方案，那么相应地重构应用程序。
如果所有产生更合理架构的尝试都失败了，那么至少您知道解决方案可能是重新定义程序的功能。
