所以我们在项目中有这个巨大的mainmodule.cpp源文件(11000行很大吗?)，每次我不得不触摸它时，我都会畏缩。
由于这个文件是如此的核心和大，它不断积累越来越多的代码，我想不出一个好方法来让它实际上开始缩小。
该文件在我们产品的几个(> 10)维护版本中被使用和积极更改，因此很难重构它。如果我“简单地”将其拆分为3个文件，那么从维护版本合并回更改将成为一场噩梦。而且，如果您拆分具有如此长而丰富历史的文件，跟踪和检查SCC历史中的旧更改突然变得非常困难。
这个文件基本上包含了我们程序的“主类”(主要的内部工作调度和协调)，所以每次添加一个特性，它也会影响这个文件，每次它的增长。：-(
在这种情况下你会怎么做?关于如何在不打乱SCC工作流程的情况下将新特性移动到单独的源文件中，您有什么想法吗?
(注意:我们使用c++和Visual Studio;我们使用AccuRev作为SCC，但我认为SCC的类型在这里并不重要;我们使用Araxis Merge来做实际的文件比较和合并)
当前回答
在我看来，您现在面临的是一堆代码异味。首先，主类似乎违反了开/闭原则。这听起来也像是承担了太多责任。因此，我认为代码比实际需要的更加脆弱。
虽然我可以理解您对重构后可跟踪性的担忧，但我认为该类相当难以维护和增强，而且您所做的任何更改都可能导致副作用。我假设这些的成本超过了重构类的成本。
在任何情况下，由于代码气味只会随着时间的推移而变得更糟，至少在某些时候，这些成本将超过重构的成本。根据你的描述，我认为你已经过了临界点。
重构应该分小步骤进行。如果可能的话，在重构任何东西之前添加自动测试来验证当前行为。然后挑选出独立功能的小区域，并将其提取为类型，以便委派职责。
无论如何，这听起来像是一个大项目，所以祝你好运:)
其他回答
我发现有一件事很有用(我现在正在做，尽管没有达到你所面临的规模)，那就是将方法提取为类(方法对象重构)。不同版本中不同的方法将成为不同的类，这些类可以被注入到公共库中，以提供您所需的不同行为。
我猜一下，如果这段代码为10个客户服务，并且包含代码变体，那么您可能有很多针对特定客户的带有变体的代码克隆
我很想对你的11000行文件进行克隆检测。(事实上，如果你把它发给我，我会用我的c++克隆检测器[见生物]，并把答案发给你)。
这将显示任何克隆，以及这些克隆是如何变化的。有了这些信息，重构代码就变得相当容易了。
如果我理解错了，请指正。
为什么不能将源代码拆分为函数或类(单独的.h/.cpp文件)并将它们作为头文件包含?当然，一定会重用一些功能。
这将是一个开始。
这让我想起了我以前的工作。似乎，在我加入之前，所有东西都在一个巨大的文件中(也是c++)。然后他们将其拆分(在完全随机的点上使用include)为大约三个(仍然是巨大的文件)。正如你所预料的那样，这个软件的质量非常糟糕。该项目总标线约为40k。(几乎没有注释，但有大量重复代码)
最后，我完全重写了这个项目。我从头开始重做项目中最糟糕的部分。当然，我想到了这个新部分和其他部分之间可能的(小)接口。然后我把这个部分插入到旧的项目中。我没有重构旧代码来创建必要的接口，只是替换了它。然后我从那里迈出了一小步，重写了旧代码。
我不得不说，这花了大约半年的时间，在此期间，除了修复错误之外，没有开发旧的代码库。
编辑:
它的大小保持在40k LOC左右，但与8年前的软件相比，新应用程序在初始版本中包含了更多的功能，可能bug也更少。重写的一个原因是我们需要新的特性，而在旧代码中引入这些特性几乎是不可能的。
该软件是为一个嵌入式系统，一个标签打印机。
我应该补充的另一点是，理论上这个项目是c++的。但它根本不是面向对象的，它可能是c。新版本是面向对象的。
我的同情-在我以前的工作中，我遇到过类似的情况，一个文件比你必须处理的文件大几倍。解决方案是:
编写代码详尽地测试程序中的函数。听起来你还没有掌握这个… 确定一些可以抽象为帮助器/实用程序类的代码。不需要很大，只是一些不是你的“主要”类的真正一部分。 重构2中确定的代码。进入一个单独的班级。 重新运行测试，以确保没有损坏。 当你有时间的时候，去2。并根据需要重复以使代码易于管理。
在第3步中构建的类。迭代可能会增加以吸收更多适合于新清除的函数的代码。
我还可以补充:
0:购买Michael Feathers关于使用遗留代码的书
不幸的是，这种类型的工作太常见了，但我的经验是，在保持工作的同时，能够使工作但可怕的代码逐渐变得不那么可怕是有很大价值的。
