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

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

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

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

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

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


当前回答

我想在这种情况下我该做的就是咬紧牙关

Figure out how I wanted to split the file up (based on the current development version) Put an administrative lock on the file ("Nobody touch mainmodule.cpp after 5pm Friday!!!" Spend your long weekend applying that change to the >10 maintenance versions (from oldest to newest), up to and including the current version. Delete mainmodule.cpp from all supported versions of the software. It's a new Age - there is no more mainmodule.cpp. Convince Management that you shouldn't be supporting more than one maintenance version of the software (at least without a big $$$ support contract). If each of your customers have their own unique version.... yeeeeeshhhh. I'd be adding compiler directives rather than trying to maintain 10+ forks.

跟踪文件的旧更改简单地通过您的第一个签入注释来解决,例如“从mainmodule.cpp分离”。如果你需要回顾最近的东西,大多数人会记得这个变化,如果是2年后,评论会告诉他们从哪里看。当然,回溯到2年前,看看是谁修改了代码以及为什么修改代码,这有多大价值呢?

其他回答

我发现这句话是你帖子中最有趣的部分:

>该文件在我们产品的几个(> 10)维护版本中被使用和积极更改,因此很难重构它

首先,我建议您使用源代码控制系统来开发这10多个支持分支的维护版本。

其次,我将创建10个分支(每个分支对应一个维护版本)。

我已经感觉到你在畏缩了!但是,要么是因为缺少特性,你的源代码控制不能满足你的情况,要么是因为它没有被正确地使用。

现在来看看您正在处理的分支——按照您认为合适的方式对其进行重构,确保不会打乱产品的其他九个分支。

我有点担心你的main()函数中有这么多。

在我编写的任何项目中,我都会使用main()只执行核心对象的初始化——比如模拟或应用程序对象——这些类才是真正的工作应该进行的地方。

我还将在main中初始化一个应用程序日志对象,以便在整个程序中全局使用。

最后,在main中,我还在预处理器块中添加了泄漏检测代码,以确保它只在DEBUG版本中启用。这是我要添加到main()的所有内容。Main()应该很短!

你这么说

>该文件基本包含了我们程序的“主类”(主要的内部工作调度和协调)

听起来这两个任务可以分成两个单独的对象——一个协调器和一个工作分派器。

当你把它们分开的时候,你可能会弄乱你的“SCC工作流”,但是听起来像严格遵守你的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.

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

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

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


编辑:

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

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

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

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

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

这将是一个开始。