所以我们在项目中有这个巨大的mainmodule.cpp源文件(11000行很大吗?)，每次我不得不触摸它时，我都会畏缩。
由于这个文件是如此的核心和大，它不断积累越来越多的代码，我想不出一个好方法来让它实际上开始缩小。
该文件在我们产品的几个(> 10)维护版本中被使用和积极更改，因此很难重构它。如果我“简单地”将其拆分为3个文件，那么从维护版本合并回更改将成为一场噩梦。而且，如果您拆分具有如此长而丰富历史的文件，跟踪和检查SCC历史中的旧更改突然变得非常困难。
这个文件基本上包含了我们程序的“主类”(主要的内部工作调度和协调)，所以每次添加一个特性，它也会影响这个文件，每次它的增长。：-(
在这种情况下你会怎么做?关于如何在不打乱SCC工作流程的情况下将新特性移动到单独的源文件中，您有什么想法吗?
(注意:我们使用c++和Visual Studio;我们使用AccuRev作为SCC，但我认为SCC的类型在这里并不重要;我们使用Araxis Merge来做实际的文件比较和合并)
当前回答
这个问题在“有效地使用遗留代码”(http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052)一书的其中一章中得到了解决。
其他回答
哇，听起来不错。我认为向你的老板解释，你需要很多时间来重构这头野兽值得一试。如果他不同意，你可以选择辞职。
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.
好吧，我理解你的痛苦:)我也参与过一些这样的项目，它并不漂亮。这个问题没有简单的答案。
一种可行的方法是开始在所有函数中添加安全保护，也就是说，检查方法中的参数、前置/后置条件，然后最终添加单元测试，以便捕获源的当前功能。一旦你有了这些，你就可以更好地重构代码，因为如果你忘记了什么，你就会有断言和错误弹出来提醒你。
有时候，重构带来的痛苦可能会大于好处。那么，最好是让原始项目处于伪维护状态，从头开始，然后增量地添加野兽的功能。
我猜一下，如果这段代码为10个客户服务，并且包含代码变体，那么您可能有很多针对特定客户的带有变体的代码克隆
我很想对你的11000行文件进行克隆检测。(事实上，如果你把它发给我，我会用我的c++克隆检测器[见生物]，并把答案发给你)。
这将显示任何克隆，以及这些克隆是如何变化的。有了这些信息，重构代码就变得相当容易了。
永远不要再碰这个文件和代码! 对待就像你被困住了一样。开始为编码在那里的功能编写适配器。 用不同的单元编写新代码，只与封装怪物功能的适配器对话。 ．.． 如果以上只有一项是不可能的，那就辞职去找一份新工作。
一个重要的建议:不要将重构和错误修复混合在一起。您需要的是程序的版本与以前的版本相同，只是源代码不同。
一种方法是开始将最小的函数/部分分割到它自己的文件中，然后使用头文件include(从而将main.cpp转换为#includes列表，这本身听起来有点代码味道*尽管我不是c++专家)，但至少现在它被分割为文件)。
然后，您可以尝试将所有维护版本切换到“新的”main.cpp或任何您的结构。再次重申:没有其他更改或错误修复，因为跟踪这些是令人困惑的地狱。
另一件事:尽管您可能希望一次性完成整个重构，但您可能会贪多嚼不烂。也许只是选择一两个“部分”，把它们放到所有的版本中，然后为你的客户增加一些更多的价值(毕竟，重构并不会直接增加价值，所以它是一种成本，必须被证明是合理的)，然后再选择另外一两个部分。
显然，这需要团队中的一些纪律来实际使用拆分文件，而不是一直向main.cpp中添加新内容，但是，尝试进行一次大规模的重构可能不是最佳的行动方案。
