所以我们在项目中有这个巨大的mainmodule.cpp源文件(11000行很大吗?),每次我不得不触摸它时,我都会畏缩。

由于这个文件是如此的核心和大,它不断积累越来越多的代码,我想不出一个好方法来让它实际上开始缩小。

该文件在我们产品的几个(> 10)维护版本中被使用和积极更改,因此很难重构它。如果我“简单地”将其拆分为3个文件,那么从维护版本合并回更改将成为一场噩梦。而且,如果您拆分具有如此长而丰富历史的文件,跟踪和检查SCC历史中的旧更改突然变得非常困难。

这个文件基本上包含了我们程序的“主类”(主要的内部工作调度和协调),所以每次添加一个特性,它也会影响这个文件,每次它的增长。:-(

在这种情况下你会怎么做?关于如何在不打乱SCC工作流程的情况下将新特性移动到单独的源文件中,您有什么想法吗?

(注意:我们使用c++和Visual Studio;我们使用AccuRev作为SCC,但我认为SCC的类型在这里并不重要;我们使用Araxis Merge来做实际的文件比较和合并)


当前回答

正如你所描述的,主要的问题是区分拆分前和拆分后,合并bug修复等。围绕它的工具。用Perl、Ruby等语言硬编码一个脚本不会花那么长时间,就可以去除分离前和分离后的连接所产生的大部分噪音。用最简单的方法处理噪音:

在连接前/过程中删除某些行(例如包括警卫) 如果有必要,从diff输出中删除其他内容

您甚至可以这样做,只要有签入,连接就会运行,并且您已经准备好了一些与单文件版本不同的东西。

其他回答

您不应该关注如何减小文件大小,而应该关注如何减小类大小。这几乎是一样的,但让你从不同的角度看问题(正如@Brian Rasmussen所建议的,你的类似乎有很多责任)。

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

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

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

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

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

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

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

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

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

更新

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

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

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

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

我的同情-在我以前的工作中,我遇到过类似的情况,一个文件比你必须处理的文件大几倍。解决方案是:

编写代码详尽地测试程序中的函数。听起来你还没有掌握这个… 确定一些可以抽象为帮助器/实用程序类的代码。不需要很大,只是一些不是你的“主要”类的真正一部分。 重构2中确定的代码。进入一个单独的班级。 重新运行测试,以确保没有损坏。 当你有时间的时候,去2。并根据需要重复以使代码易于管理。

在第3步中构建的类。迭代可能会增加以吸收更多适合于新清除的函数的代码。

我还可以补充:

0:购买Michael Feathers关于使用遗留代码的书

不幸的是,这种类型的工作太常见了,但我的经验是,在保持工作的同时,能够使工作但可怕的代码逐渐变得不那么可怕是有很大价值的。

如果我理解错了,请指正。

为什么不能将源代码拆分为函数或类(单独的.h/.cpp文件)并将它们作为头文件包含?当然,一定会重用一些功能。

这将是一个开始。