这让我想起了我以前的工作。似乎，在我加入之前，所有东西都在一个巨大的文件中(也是c++)。然后他们将其拆分(在完全随机的点上使用include)为大约三个(仍然是巨大的文件)。正如你所预料的那样，这个软件的质量非常糟糕。该项目总标线约为40k。(几乎没有注释，但有大量重复代码)

最后，我完全重写了这个项目。我从头开始重做项目中最糟糕的部分。当然，我想到了这个新部分和其他部分之间可能的(小)接口。然后我把这个部分插入到旧的项目中。我没有重构旧代码来创建必要的接口，只是替换了它。然后我从那里迈出了一小步，重写了旧代码。

我不得不说，这花了大约半年的时间，在此期间，除了修复错误之外，没有开发旧的代码库。

编辑:

它的大小保持在40k LOC左右，但与8年前的软件相比，新应用程序在初始版本中包含了更多的功能，可能bug也更少。重写的一个原因是我们需要新的特性，而在旧代码中引入这些特性几乎是不可能的。

该软件是为一个嵌入式系统，一个标签打印机。

我应该补充的另一点是，理论上这个项目是c++的。但它根本不是面向对象的，它可能是c。新版本是面向对象的。

我猜一下，如果这段代码为10个客户服务，并且包含代码变体，那么您可能有很多针对特定客户的带有变体的代码克隆

我很想对你的11000行文件进行克隆检测。(事实上，如果你把它发给我，我会用我的c++克隆检测器[见生物]，并把答案发给你)。

这将显示任何克隆，以及这些克隆是如何变化的。有了这些信息，重构代码就变得相当容易了。

在我看来，您现在面临的是一堆代码异味。首先，主类似乎违反了开/闭原则。这听起来也像是承担了太多责任。因此，我认为代码比实际需要的更加脆弱。

虽然我可以理解您对重构后可跟踪性的担忧，但我认为该类相当难以维护和增强，而且您所做的任何更改都可能导致副作用。我假设这些的成本超过了重构类的成本。

在任何情况下，由于代码气味只会随着时间的推移而变得更糟，至少在某些时候，这些成本将超过重构的成本。根据你的描述，我认为你已经过了临界点。

重构应该分小步骤进行。如果可能的话，在重构任何东西之前添加自动测试来验证当前行为。然后挑选出独立功能的小区域，并将其提取为类型，以便委派职责。

无论如何，这听起来像是一个大项目，所以祝你好运:)

下面是我所想到的解决这些问题的唯一办法。所述方法的实际增益是演化的累进性。这里没有革命，否则你很快就会陷入麻烦。

在原来的主类上面插入一个新的cpp类。目前，它基本上会将所有调用重定向到当前的主类，但目标是使这个新类的API尽可能清晰和简洁。

一旦完成了这些，就可以在新类中添加新功能。

至于现有的功能，当它们变得足够稳定时，您必须逐步将它们移动到新的类中。对于这段代码，您将失去SCC帮助，但是对此没有太多办法。只要选择合适的时机。

我知道这并不完美，但我希望它能有所帮助，这个过程必须适应您的需要!

额外的信息

注意，Git是一个SCC，它可以从一个文件跟踪代码片段到另一个文件。我听说过关于它的好东西，所以它可以帮助你逐步转移你的工作。

Git是围绕blob的概念构建的，如果我理解正确的话，blob表示代码文件的片段。在不同的文件中移动这些片段，Git会找到它们，即使您修改了它们。除了下面评论中提到的Linus Torvalds的视频之外，我还没有找到关于这个问题的一些清楚的东西。

我认为最好创建一组映射到mainmodule.cpp的API点的命令类。

一旦它们就位，您将需要重构现有的代码库，以通过命令类访问这些API点，一旦完成，您就可以自由地将每个命令的实现重构为新的类结构。

当然，对于一个11 KLOC的类，其中的代码可能是高度耦合和脆弱的，但是创建单独的命令类比任何其他代理/外观策略都更有帮助。

我并不羡慕这项任务，但随着时间的推移，如果不加以解决，这个问题只会变得更糟。

更新

我建议Command模式比Facade更可取。

在一个(相对)单一的Facade上维护/组织许多不同的命令类是可取的。将一个Facade映射到一个11 KLOC文件本身可能需要分解成几个不同的组。

为什么要费心去弄清楚这些门面组呢?使用命令模式，你将能够对这些小类进行有机分组和组织，因此你有更多的灵活性。

当然，这两种选择都比单一的11 KLOC和不断增长的文件要好。

我发现有一件事很有用(我现在正在做，尽管没有达到你所面临的规模)，那就是将方法提取为类(方法对象重构)。不同版本中不同的方法将成为不同的类，这些类可以被注入到公共库中，以提供您所需的不同行为。