所以我们在项目中有这个巨大的mainmodule.cpp源文件(11000行很大吗?)，每次我不得不触摸它时，我都会畏缩。
由于这个文件是如此的核心和大，它不断积累越来越多的代码，我想不出一个好方法来让它实际上开始缩小。
该文件在我们产品的几个(> 10)维护版本中被使用和积极更改，因此很难重构它。如果我“简单地”将其拆分为3个文件，那么从维护版本合并回更改将成为一场噩梦。而且，如果您拆分具有如此长而丰富历史的文件，跟踪和检查SCC历史中的旧更改突然变得非常困难。
这个文件基本上包含了我们程序的“主类”(主要的内部工作调度和协调)，所以每次添加一个特性，它也会影响这个文件，每次它的增长。：-(
在这种情况下你会怎么做?关于如何在不打乱SCC工作流程的情况下将新特性移动到单独的源文件中，您有什么想法吗?
(注意:我们使用c++和Visual Studio;我们使用AccuRev作为SCC，但我认为SCC的类型在这里并不重要;我们使用Araxis Merge来做实际的文件比较和合并)
当前回答
好吧，我理解你的痛苦:)我也参与过一些这样的项目，它并不漂亮。这个问题没有简单的答案。
一种可行的方法是开始在所有函数中添加安全保护，也就是说，检查方法中的参数、前置/后置条件，然后最终添加单元测试，以便捕获源的当前功能。一旦你有了这些，你就可以更好地重构代码，因为如果你忘记了什么，你就会有断言和错误弹出来提醒你。
有时候，重构带来的痛苦可能会大于好处。那么，最好是让原始项目处于伪维护状态，从头开始，然后增量地添加野兽的功能。
其他回答
孔子说:“出洞的第一步是停止挖洞。”
下面是我所想到的解决这些问题的唯一办法。所述方法的实际增益是演化的累进性。这里没有革命，否则你很快就会陷入麻烦。
在原来的主类上面插入一个新的cpp类。目前，它基本上会将所有调用重定向到当前的主类，但目标是使这个新类的API尽可能清晰和简洁。
一旦完成了这些，就可以在新类中添加新功能。
至于现有的功能，当它们变得足够稳定时，您必须逐步将它们移动到新的类中。对于这段代码，您将失去SCC帮助，但是对此没有太多办法。只要选择合适的时机。
我知道这并不完美，但我希望它能有所帮助，这个过程必须适应您的需要!
额外的信息
注意，Git是一个SCC，它可以从一个文件跟踪代码片段到另一个文件。我听说过关于它的好东西，所以它可以帮助你逐步转移你的工作。
Git是围绕blob的概念构建的，如果我理解正确的话，blob表示代码文件的片段。在不同的文件中移动这些片段，Git会找到它们，即使您修改了它们。除了下面评论中提到的Linus Torvalds的视频之外，我还没有找到关于这个问题的一些清楚的东西。
我认为在拆分文件时跟踪源文件历史的最简单的方法是这样的:
使用SCM系统提供的任何保存历史的拷贝命令来复制原始源代码。此时您可能需要提交，但还不需要告诉构建系统关于新文件的信息，因此这应该是可以的。 从这些副本中删除代码。这应该不会打破你所保持的历史。
好吧，我理解你的痛苦:)我也参与过一些这样的项目，它并不漂亮。这个问题没有简单的答案。
一种可行的方法是开始在所有函数中添加安全保护，也就是说，检查方法中的参数、前置/后置条件，然后最终添加单元测试，以便捕获源的当前功能。一旦你有了这些，你就可以更好地重构代码，因为如果你忘记了什么，你就会有断言和错误弹出来提醒你。
有时候，重构带来的痛苦可能会大于好处。那么，最好是让原始项目处于伪维护状态，从头开始，然后增量地添加野兽的功能。
一种不太危险的方法是对所有的线变化进行历史性的观察。有没有特定的函数比其他函数更稳定?可以说是变化的热点。
如果某一行在几年内没有被更改过，你可以将它移到另一个文件中，而不用太担心。我会看一下用最后一次修改注释的源代码，看看是否有任何函数可以提取出来。
