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

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

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

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

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

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


当前回答

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

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

这将是一个开始。

其他回答

这是一个经典的例子,一个已知的反设计模式,称为blob。花点时间阅读我在这里指出的文章,也许你会发现一些有用的东西。此外,如果这个项目像它看起来的那样大,您应该考虑一些设计来防止发展成您无法控制的代码。

好吧,我理解你的痛苦:)我也参与过一些这样的项目,它并不漂亮。这个问题没有简单的答案。

一种可行的方法是开始在所有函数中添加安全保护,也就是说,检查方法中的参数、前置/后置条件,然后最终添加单元测试,以便捕获源的当前功能。一旦你有了这些,你就可以更好地重构代码,因为如果你忘记了什么,你就会有断言和错误弹出来提醒你。

有时候,重构带来的痛苦可能会大于好处。那么,最好是让原始项目处于伪维护状态,从头开始,然后增量地添加野兽的功能。

我认为在拆分文件时跟踪源文件历史的最简单的方法是这样的:

使用SCM系统提供的任何保存历史的拷贝命令来复制原始源代码。此时您可能需要提交,但还不需要告诉构建系统关于新文件的信息,因此这应该是可以的。 从这些副本中删除代码。这应该不会打破你所保持的历史。

另一本你可能会觉得有趣/有用的书是《重构》。

你担心文件的大小。

从历史上看,C程序的文件大小是由机器PDP11/40的限制决定的。 我使用的这个可以处理最大4096字节的文件。为了解决这个问题 C编译器使用#include并发明了.h文件来帮助链接器和分段加载器,因为 加载器必须动态交换(因此在Intel架构中使用段寄存器)。

Small files solved the problem but left an historical legacy. Programmers now believe that small files are the only way to program. You have a machine with 4 gigabytes (vs 8 kilobytes on the 11/40). You have a machine with 3 billion instructions per second (vs 500 kilo instructions on the 11/40). You have a compiler that can block optimize code it can see (as opposed to linking .o files which it cannot see). You have a machine that is bandwidth limited by disk I/O but you want to create 500 tiny .c, .h, and .o files, possibly multiple times with the .h includes.

大的C文件绝对没有错。编译器可以大量优化 磁盘I/O最小,链接器时间消失,编辑器可以找到琐碎的东西 一个花哨的IDE,……

11000行对于今天来说是一个微不足道的文件。把自己从历史中解放出来。