所以我们在项目中有这个巨大的mainmodule.cpp源文件(11000行很大吗?)，每次我不得不触摸它时，我都会畏缩。
由于这个文件是如此的核心和大，它不断积累越来越多的代码，我想不出一个好方法来让它实际上开始缩小。
该文件在我们产品的几个(> 10)维护版本中被使用和积极更改，因此很难重构它。如果我“简单地”将其拆分为3个文件，那么从维护版本合并回更改将成为一场噩梦。而且，如果您拆分具有如此长而丰富历史的文件，跟踪和检查SCC历史中的旧更改突然变得非常困难。
这个文件基本上包含了我们程序的“主类”(主要的内部工作调度和协调)，所以每次添加一个特性，它也会影响这个文件，每次它的增长。：-(
在这种情况下你会怎么做?关于如何在不打乱SCC工作流程的情况下将新特性移动到单独的源文件中，您有什么想法吗?
(注意:我们使用c++和Visual Studio;我们使用AccuRev作为SCC，但我认为SCC的类型在这里并不重要;我们使用Araxis Merge来做实际的文件比较和合并)
当前回答
我认为在拆分文件时跟踪源文件历史的最简单的方法是这样的:
使用SCM系统提供的任何保存历史的拷贝命令来复制原始源代码。此时您可能需要提交，但还不需要告诉构建系统关于新文件的信息，因此这应该是可以的。 从这些副本中删除代码。这应该不会打破你所保持的历史。
其他回答
这让我想起了我以前的工作。似乎，在我加入之前，所有东西都在一个巨大的文件中(也是c++)。然后他们将其拆分(在完全随机的点上使用include)为大约三个(仍然是巨大的文件)。正如你所预料的那样，这个软件的质量非常糟糕。该项目总标线约为40k。(几乎没有注释，但有大量重复代码)
最后，我完全重写了这个项目。我从头开始重做项目中最糟糕的部分。当然，我想到了这个新部分和其他部分之间可能的(小)接口。然后我把这个部分插入到旧的项目中。我没有重构旧代码来创建必要的接口，只是替换了它。然后我从那里迈出了一小步，重写了旧代码。
我不得不说，这花了大约半年的时间，在此期间，除了修复错误之外，没有开发旧的代码库。
编辑:
它的大小保持在40k LOC左右，但与8年前的软件相比，新应用程序在初始版本中包含了更多的功能，可能bug也更少。重写的一个原因是我们需要新的特性，而在旧代码中引入这些特性几乎是不可能的。
该软件是为一个嵌入式系统，一个标签打印机。
我应该补充的另一点是，理论上这个项目是c++的。但它根本不是面向对象的，它可能是c。新版本是面向对象的。
好吧，我理解你的痛苦:)我也参与过一些这样的项目，它并不漂亮。这个问题没有简单的答案。
一种可行的方法是开始在所有函数中添加安全保护，也就是说，检查方法中的参数、前置/后置条件，然后最终添加单元测试，以便捕获源的当前功能。一旦你有了这些，你就可以更好地重构代码，因为如果你忘记了什么，你就会有断言和错误弹出来提醒你。
有时候，重构带来的痛苦可能会大于好处。那么，最好是让原始项目处于伪维护状态，从头开始，然后增量地添加野兽的功能。
一个重要的建议:不要将重构和错误修复混合在一起。您需要的是程序的版本与以前的版本相同，只是源代码不同。
一种方法是开始将最小的函数/部分分割到它自己的文件中，然后使用头文件include(从而将main.cpp转换为#includes列表，这本身听起来有点代码味道*尽管我不是c++专家)，但至少现在它被分割为文件)。
然后，您可以尝试将所有维护版本切换到“新的”main.cpp或任何您的结构。再次重申:没有其他更改或错误修复，因为跟踪这些是令人困惑的地狱。
另一件事:尽管您可能希望一次性完成整个重构，但您可能会贪多嚼不烂。也许只是选择一两个“部分”，把它们放到所有的版本中，然后为你的客户增加一些更多的价值(毕竟，重构并不会直接增加价值，所以它是一种成本，必须被证明是合理的)，然后再选择另外一两个部分。
显然，这需要团队中的一些纪律来实际使用拆分文件，而不是一直向main.cpp中添加新内容，但是，尝试进行一次大规模的重构可能不是最佳的行动方案。
正如你所描述的，主要的问题是区分拆分前和拆分后，合并bug修复等。围绕它的工具。用Perl、Ruby等语言硬编码一个脚本不会花那么长时间，就可以去除分离前和分离后的连接所产生的大部分噪音。用最简单的方法处理噪音:
在连接前/过程中删除某些行(例如包括警卫) 如果有必要，从diff输出中删除其他内容
您甚至可以这样做，只要有签入，连接就会运行，并且您已经准备好了一些与单文件版本不同的东西。
我认为在拆分文件时跟踪源文件历史的最简单的方法是这样的:
使用SCM系统提供的任何保存历史的拷贝命令来复制原始源代码。此时您可能需要提交，但还不需要告诉构建系统关于新文件的信息，因此这应该是可以的。 从这些副本中删除代码。这应该不会打破你所保持的历史。
