所以我们在项目中有这个巨大的mainmodule.cpp源文件(11000行很大吗?)，每次我不得不触摸它时，我都会畏缩。
由于这个文件是如此的核心和大，它不断积累越来越多的代码，我想不出一个好方法来让它实际上开始缩小。
该文件在我们产品的几个(> 10)维护版本中被使用和积极更改，因此很难重构它。如果我“简单地”将其拆分为3个文件，那么从维护版本合并回更改将成为一场噩梦。而且，如果您拆分具有如此长而丰富历史的文件，跟踪和检查SCC历史中的旧更改突然变得非常困难。
这个文件基本上包含了我们程序的“主类”(主要的内部工作调度和协调)，所以每次添加一个特性，它也会影响这个文件，每次它的增长。：-(
在这种情况下你会怎么做?关于如何在不打乱SCC工作流程的情况下将新特性移动到单独的源文件中，您有什么想法吗?
(注意:我们使用c++和Visual Studio;我们使用AccuRev作为SCC，但我认为SCC的类型在这里并不重要;我们使用Araxis Merge来做实际的文件比较和合并)
当前回答
我认为最好创建一组映射到mainmodule.cpp的API点的命令类。
一旦它们就位，您将需要重构现有的代码库，以通过命令类访问这些API点，一旦完成，您就可以自由地将每个命令的实现重构为新的类结构。
当然，对于一个11 KLOC的类，其中的代码可能是高度耦合和脆弱的，但是创建单独的命令类比任何其他代理/外观策略都更有帮助。
我并不羡慕这项任务，但随着时间的推移，如果不加以解决，这个问题只会变得更糟。
更新
我建议Command模式比Facade更可取。
在一个(相对)单一的Facade上维护/组织许多不同的命令类是可取的。将一个Facade映射到一个11 KLOC文件本身可能需要分解成几个不同的组。
为什么要费心去弄清楚这些门面组呢?使用命令模式，你将能够对这些小类进行有机分组和组织，因此你有更多的灵活性。
当然，这两种选择都比单一的11 KLOC和不断增长的文件要好。
其他回答
好吧，我理解你的痛苦:)我也参与过一些这样的项目，它并不漂亮。这个问题没有简单的答案。
一种可行的方法是开始在所有函数中添加安全保护，也就是说，检查方法中的参数、前置/后置条件，然后最终添加单元测试，以便捕获源的当前功能。一旦你有了这些，你就可以更好地重构代码，因为如果你忘记了什么，你就会有断言和错误弹出来提醒你。
有时候，重构带来的痛苦可能会大于好处。那么，最好是让原始项目处于伪维护状态，从头开始，然后增量地添加野兽的功能。
您不应该关注如何减小文件大小，而应该关注如何减小类大小。这几乎是一样的，但让你从不同的角度看问题(正如@Brian Rasmussen所建议的，你的类似乎有很多责任)。
我认为最好创建一组映射到mainmodule.cpp的API点的命令类。
一旦它们就位，您将需要重构现有的代码库，以通过命令类访问这些API点，一旦完成，您就可以自由地将每个命令的实现重构为新的类结构。
当然，对于一个11 KLOC的类，其中的代码可能是高度耦合和脆弱的，但是创建单独的命令类比任何其他代理/外观策略都更有帮助。
我并不羡慕这项任务，但随着时间的推移，如果不加以解决，这个问题只会变得更糟。
更新
我建议Command模式比Facade更可取。
在一个(相对)单一的Facade上维护/组织许多不同的命令类是可取的。将一个Facade映射到一个11 KLOC文件本身可能需要分解成几个不同的组。
为什么要费心去弄清楚这些门面组呢?使用命令模式，你将能够对这些小类进行有机分组和组织，因此你有更多的灵活性。
当然，这两种选择都比单一的11 KLOC和不断增长的文件要好。
这并不是一个大问题的答案，而是一个具体问题的理论解决方案:
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文件历史，我认为最好的方法是告诉您的源代码控制系统各个片段文件都是原始文件的副本。然后，它将保存该文件中保存的部分的历史，当然，它也将记录大部分被“删除”。
哇，听起来不错。我认为向你的老板解释，你需要很多时间来重构这头野兽值得一试。如果他不同意，你可以选择辞职。
Anyway, what I suggest is basically throwing out all the implementation and regrouping it into new modules, let's call those "global services". The "main module" would only forward to those services and ANY new code you write will use them instead of the "main module". This should be feasible in a reasonable amount of time (because it's mostly copy and paste), you don't break existing code and you can do it one maintenance version at a time. And if you still have any time left, you can spend it refactoring all old depending modules to also use the global services.
