如何处理11000行c++源文件?

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

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

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

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

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

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

当前回答

我的0.05欧分:

重新设计整个混乱的系统，考虑到技术和业务需求，将其拆分为子系统(=许多并行维护轨道，每个并行维护轨道的代码库可能不同，显然需要高可修改性等等)。

在划分子系统时，分析变化最大的地方，并将其与不变的部分分开。这应该会显示出问题所在。将最易变化的部分分离到它们自己的模块中(例如dll)，这样模块API就可以保持完整，而不需要一直破坏BC。这样，如果需要，您可以为不同的维护分支部署不同版本的模块，同时保持核心不变。

重新设计很可能需要一个单独的项目，试图做一个移动的目标是行不通的。

至于源代码历史，我的意见是:为了新代码忘掉它吧。但是请将历史记录保存在某个地方，以便在需要时进行检查。我打赌你开始之后就不那么需要它了。

对于这个项目，您很可能需要得到管理层的支持。你可以用更快的开发时间、更少的bug、更容易的维护和更少的混乱来反驳。类似于“积极地使我们的关键软件资产具有未来的可靠性和维护可行性”:)

至少这是我开始解决问题的方式。

2010-09-01 08:47:44

其他回答

首先向它添加注释。参考函数被调用的位置以及是否可以移动物体。这可以让事情动起来。你真的需要评估它的代码基础有多脆弱。然后将公共功能转移到一起。一次做一些小改变。

2010-09-02 10:12:14

你担心文件的大小。

从历史上看，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行对于今天来说是一个微不足道的文件。把自己从历史中解放出来。

2010-09-02 12:30:37

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

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

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

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

更新

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

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

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

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