所以我们在项目中有这个巨大的mainmodule.cpp源文件(11000行很大吗?),每次我不得不触摸它时,我都会畏缩。
由于这个文件是如此的核心和大,它不断积累越来越多的代码,我想不出一个好方法来让它实际上开始缩小。
该文件在我们产品的几个(> 10)维护版本中被使用和积极更改,因此很难重构它。如果我“简单地”将其拆分为3个文件,那么从维护版本合并回更改将成为一场噩梦。而且,如果您拆分具有如此长而丰富历史的文件,跟踪和检查SCC历史中的旧更改突然变得非常困难。
这个文件基本上包含了我们程序的“主类”(主要的内部工作调度和协调),所以每次添加一个特性,它也会影响这个文件,每次它的增长。:-(
在这种情况下你会怎么做?关于如何在不打乱SCC工作流程的情况下将新特性移动到单独的源文件中,您有什么想法吗?
(注意:我们使用c++和Visual Studio;我们使用AccuRev作为SCC,但我认为SCC的类型在这里并不重要;我们使用Araxis Merge来做实际的文件比较和合并)
下面是我所想到的解决这些问题的唯一办法。所述方法的实际增益是演化的累进性。这里没有革命,否则你很快就会陷入麻烦。
在原来的主类上面插入一个新的cpp类。目前,它基本上会将所有调用重定向到当前的主类,但目标是使这个新类的API尽可能清晰和简洁。
一旦完成了这些,就可以在新类中添加新功能。
至于现有的功能,当它们变得足够稳定时,您必须逐步将它们移动到新的类中。对于这段代码,您将失去SCC帮助,但是对此没有太多办法。只要选择合适的时机。
我知道这并不完美,但我希望它能有所帮助,这个过程必须适应您的需要!
额外的信息
注意,Git是一个SCC,它可以从一个文件跟踪代码片段到另一个文件。我听说过关于它的好东西,所以它可以帮助你逐步转移你的工作。
Git是围绕blob的概念构建的,如果我理解正确的话,blob表示代码文件的片段。在不同的文件中移动这些片段,Git会找到它们,即使您修改了它们。除了下面评论中提到的Linus Torvalds的视频之外,我还没有找到关于这个问题的一些清楚的东西。
我不知道这是否解决了您的问题,但我猜您想要做的是将文件的内容迁移到彼此独立的更小的文件中(合计)。
我还了解到,你有大约10个不同版本的软件,你需要在不搞砸的情况下支持它们。
首先,这是不可能的简单,将解决自己在几分钟的头脑风暴。文件中链接的函数对应用程序都非常重要,简单地将它们删除并迁移到其他文件中并不能解决问题。
我认为你只有这些选择:
Don't migrate and stay with what you have. Possibly quit your job and start working on serious software with good design in addition. Extreme programming is not always the best solution if you are working on a long time project with enough funds to survive a crash or two.
Work out a layout of how you would love your file to look once it's split up. Create the necessary files and integrate them in your application. Rename the functions or overload them to take an additional parameter (maybe just a simple boolean?).
Once you have to work on your code, migrate the functions you need to work on to the new file and map the function calls of the old functions to the new functions.
You should still have your main-file this way, and still be able to see the changes that were made to it, once it comes to a specific function you know exactly when it was outsourced and so on.
Try to convince your co-workers with some good cake that workflow is overrated and that you need to rewrite some parts of the application in order to do serious business.
在我看来,您现在面临的是一堆代码异味。首先,主类似乎违反了开/闭原则。这听起来也像是承担了太多责任。因此,我认为代码比实际需要的更加脆弱。
虽然我可以理解您对重构后可跟踪性的担忧,但我认为该类相当难以维护和增强,而且您所做的任何更改都可能导致副作用。我假设这些的成本超过了重构类的成本。
在任何情况下,由于代码气味只会随着时间的推移而变得更糟,至少在某些时候,这些成本将超过重构的成本。根据你的描述,我认为你已经过了临界点。
重构应该分小步骤进行。如果可能的话,在重构任何东西之前添加自动测试来验证当前行为。然后挑选出独立功能的小区域,并将其提取为类型,以便委派职责。
无论如何,这听起来像是一个大项目,所以祝你好运:)
我认为最好创建一组映射到mainmodule.cpp的API点的命令类。
一旦它们就位,您将需要重构现有的代码库,以通过命令类访问这些API点,一旦完成,您就可以自由地将每个命令的实现重构为新的类结构。
当然,对于一个11 KLOC的类,其中的代码可能是高度耦合和脆弱的,但是创建单独的命令类比任何其他代理/外观策略都更有帮助。
我并不羡慕这项任务,但随着时间的推移,如果不加以解决,这个问题只会变得更糟。
更新
我建议Command模式比Facade更可取。
在一个(相对)单一的Facade上维护/组织许多不同的命令类是可取的。将一个Facade映射到一个11 KLOC文件本身可能需要分解成几个不同的组。
为什么要费心去弄清楚这些门面组呢?使用命令模式,你将能够对这些小类进行有机分组和组织,因此你有更多的灵活性。
当然,这两种选择都比单一的11 KLOC和不断增长的文件要好。
这让我想起了我以前的工作。似乎,在我加入之前,所有东西都在一个巨大的文件中(也是c++)。然后他们将其拆分(在完全随机的点上使用include)为大约三个(仍然是巨大的文件)。正如你所预料的那样,这个软件的质量非常糟糕。该项目总标线约为40k。(几乎没有注释,但有大量重复代码)
最后,我完全重写了这个项目。我从头开始重做项目中最糟糕的部分。当然,我想到了这个新部分和其他部分之间可能的(小)接口。然后我把这个部分插入到旧的项目中。我没有重构旧代码来创建必要的接口,只是替换了它。然后我从那里迈出了一小步,重写了旧代码。
我不得不说,这花了大约半年的时间,在此期间,除了修复错误之外,没有开发旧的代码库。
编辑:
它的大小保持在40k LOC左右,但与8年前的软件相比,新应用程序在初始版本中包含了更多的功能,可能bug也更少。重写的一个原因是我们需要新的特性,而在旧代码中引入这些特性几乎是不可能的。
该软件是为一个嵌入式系统,一个标签打印机。
我应该补充的另一点是,理论上这个项目是c++的。但它根本不是面向对象的,它可能是c。新版本是面向对象的。
让我猜猜:10个拥有不同功能集的客户和一个提倡“定制化”的销售经理?我以前做过这样的产品。我们遇到了同样的问题。
您认识到拥有一个巨大的文件是很麻烦的,但更麻烦的是您必须保持10个版本的“最新”。这是多重维护。SCC可以使这更容易,但它不能使它正确。
Before you try to break the file into parts, you need to bring the ten branches back in sync with each other so that you can see and shape all the code at once. You can do this one branch at a time, testing both branches against the same main code file. To enforce the custom behavior, you can use #ifdef and friends, but it's better as much as possible to use ordinary if/else against defined constants. This way, your compiler will verify all types and most probably eliminate "dead" object code anyway. (You may want to turn off the warning about dead code, though.)
一旦所有分支隐式地共享了该文件的一个版本,那么就更容易开始使用传统的重构方法。
#ifdefs主要适用于受影响的代码只在其他分支自定义上下文中有意义的部分。有人可能会说,这也为相同的分支合并方案提供了机会,但不要太疯狂。一次只做一个大项目。
In the short run, the file will appear to grow. This is OK. What you're doing is bringing things together that need to be together. Afterwards, you'll begin to see areas that are clearly the same regardless of version; these can be left alone or refactored at will. Other areas will clearly differ depending on the version. You have a number of options in this case. One method is to delegate the differences to per-version strategy objects. Another is to derive client versions from a common abstract class. But none of these transformations are possible as long as you have ten "tips" of development in different branches.
我的0.05欧分:
重新设计整个混乱的系统,考虑到技术和业务需求,将其拆分为子系统(=许多并行维护轨道,每个并行维护轨道的代码库可能不同,显然需要高可修改性等等)。
在划分子系统时,分析变化最大的地方,并将其与不变的部分分开。这应该会显示出问题所在。将最易变化的部分分离到它们自己的模块中(例如dll),这样模块API就可以保持完整,而不需要一直破坏BC。这样,如果需要,您可以为不同的维护分支部署不同版本的模块,同时保持核心不变。
重新设计很可能需要一个单独的项目,试图做一个移动的目标是行不通的。
至于源代码历史,我的意见是:为了新代码忘掉它吧。但是请将历史记录保存在某个地方,以便在需要时进行检查。我打赌你开始之后就不那么需要它了。
对于这个项目,您很可能需要得到管理层的支持。你可以用更快的开发时间、更少的bug、更容易的维护和更少的混乱来反驳。类似于“积极地使我们的关键软件资产具有未来的可靠性和维护可行性”:)
至少这是我开始解决问题的方式。
所以从一开始重写产品代码的API是一个坏主意。需要做两件事。
首先,您需要让您的团队决定对该文件的当前生产版本进行代码冻结。
第二,您需要使用这个生产版本并创建一个分支,该分支使用预处理指令来管理构建,以分割大文件。使用JUST预处理器指令(#ifdefs, #includes, #endifs)拆分编译比重新编码API更容易。对于您的sla和持续的支持来说,这绝对更容易。
在这里,您可以简单地删除类中与特定子系统相关的函数,并将它们放在一个文件(例如mainloop_foostuff.cpp)中,并将其包含在mainloop.cpp中的正确位置。
OR
一种更耗时但健壮的方法是设计一个内部依赖关系结构,在包含内容的方式上具有双重间接性。这将允许您分割内容,并仍然照顾到共同依赖关系。注意,这种方法需要位置编码,因此应该加上适当的注释。
这种方法将包括基于您正在编译的变体而使用的组件。
基本结构是mainclass.cpp将在如下语句块后包含一个名为MainClassComponents.cpp的新文件:
#if VARIANT == 1
# define Uses_Component_1
# define Uses_Component_2
#elif VARIANT == 2
# define Uses_Component_1
# define Uses_Component_3
# define Uses_Component_6
...
#endif
#include "MainClassComponents.cpp"
MainClassComponents.cpp文件的主要结构将在那里计算子组件中的依赖关系,如下所示:
#ifndef _MainClassComponents_cpp
#define _MainClassComponents_cpp
/* dependencies declarations */
#if defined(Activate_Component_1)
#define _REQUIRES_COMPONENT_1
#define _REQUIRES_COMPONENT_3 /* you also need component 3 for component 1 */
#endif
#if defined(Activate_Component_2)
#define _REQUIRES_COMPONENT_2
#define _REQUIRES_COMPONENT_15 /* you also need component 15 for this component */
#endif
/* later on in the header */
#ifdef _REQUIRES_COMPONENT_1
#include "component_1.cpp"
#endif
#ifdef _REQUIRES_COMPONENT_2
#include "component_2.cpp"
#endif
#ifdef _REQUIRES_COMPONENT_3
#include "component_3.cpp"
#endif
#endif /* _MainClassComponents_h */
现在,为每个组件创建一个component_xx.cpp文件。
当然,我使用数字,但你应该使用一些更符合逻辑的基于你的代码。
使用预处理器可以让你把事情分开,而不必担心API的变化,这在生产中是一个噩梦。
一旦你确定了产品,你就可以开始重新设计了。
一个重要的建议:不要将重构和错误修复混合在一起。您需要的是程序的版本与以前的版本相同,只是源代码不同。
一种方法是开始将最小的函数/部分分割到它自己的文件中,然后使用头文件include(从而将main.cpp转换为#includes列表,这本身听起来有点代码味道*尽管我不是c++专家),但至少现在它被分割为文件)。
然后,您可以尝试将所有维护版本切换到“新的”main.cpp或任何您的结构。再次重申:没有其他更改或错误修复,因为跟踪这些是令人困惑的地狱。
另一件事:尽管您可能希望一次性完成整个重构,但您可能会贪多嚼不烂。也许只是选择一两个“部分”,把它们放到所有的版本中,然后为你的客户增加一些更多的价值(毕竟,重构并不会直接增加价值,所以它是一种成本,必须被证明是合理的),然后再选择另外一两个部分。
显然,这需要团队中的一些纪律来实际使用拆分文件,而不是一直向main.cpp中添加新内容,但是,尝试进行一次大规模的重构可能不是最佳的行动方案。
Find some code in the file which is relatively stable (not changing fast, and doesn't vary much between branches) and could stand as an independent unit. Move this into its own file, and for that matter into its own class, in all branches. Because it's stable, this won't cause (many) "awkward" merges that have to be applied to a different file from the one they were originally made on, when you merge the change from one branch to another. Repeat.
Find some code in the file which basically only applies to a small number of branches, and could stand alone. Doesn't matter whether it's changing fast or not, because of the small number of branches. Move this into its own classes and files. Repeat.
因此,我们去掉了到处都一样的代码,以及特定于某些分支的代码。
This leaves you with a nucleus of badly-managed code - it's needed everywhere, but it's different in every branch (and/or it changes constantly so that some branches are running behind others), and yet it's in a single file that you're unsuccessfully trying to merge between branches. Stop doing that. Branch the file permanently, perhaps by renaming it in each branch. It's not "main" any more, it's "main for configuration X". OK, so you lose the ability to apply the same change to multiple branches by merging, but this is in any case the core of code where merging doesn't work very well. If you're having to manually manage the merges anyway to deal with conflicts, then it's no loss to manually apply them independently on each branch.
我认为你说这种SCC无关紧要是错误的,因为例如git的合并能力可能比你正在使用的合并工具更好。因此,核心问题“合并困难”发生在不同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.
这并不是一个大问题的答案,而是一个具体问题的理论解决方案:
Figure out where you want to split the big file into subfiles. Put comments in some special format at each of those points.
Write a fairly trivial script that will break the file apart into subfiles at those points. (Perhaps the special comments have embedded filenames that the script can use as instructions for how to split it.) It should preserve the comments as part of the splitting.
Run the script. Delete the original file.
When you need to merge from a branch, first recreate the big file by concatenating the pieces back together, do the merge, and then re-split it.
另外,如果您想要保存SCC文件历史,我认为最好的方法是告诉您的源代码控制系统各个片段文件都是原始文件的副本。然后,它将保存该文件中保存的部分的历史,当然,它也将记录大部分被“删除”。
你担心文件的大小。
从历史上看,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行对于今天来说是一个微不足道的文件。把自己从历史中解放出来。
我发现这句话是你帖子中最有趣的部分:
>该文件在我们产品的几个(> 10)维护版本中被使用和积极更改,因此很难重构它
首先,我建议您使用源代码控制系统来开发这10多个支持分支的维护版本。
其次,我将创建10个分支(每个分支对应一个维护版本)。
我已经感觉到你在畏缩了!但是,要么是因为缺少特性,你的源代码控制不能满足你的情况,要么是因为它没有被正确地使用。
现在来看看您正在处理的分支——按照您认为合适的方式对其进行重构,确保不会打乱产品的其他九个分支。
我有点担心你的main()函数中有这么多。
在我编写的任何项目中,我都会使用main()只执行核心对象的初始化——比如模拟或应用程序对象——这些类才是真正的工作应该进行的地方。
我还将在main中初始化一个应用程序日志对象,以便在整个程序中全局使用。
最后,在main中,我还在预处理器块中添加了泄漏检测代码,以确保它只在DEBUG版本中启用。这是我要添加到main()的所有内容。Main()应该很短!
你这么说
>该文件基本包含了我们程序的“主类”(主要的内部工作调度和协调)
听起来这两个任务可以分成两个单独的对象——一个协调器和一个工作分派器。
当你把它们分开的时候,你可能会弄乱你的“SCC工作流”,但是听起来像严格遵守你的SCC工作流会导致软件维护问题。抛弃它,现在就不要回头,因为一旦你解决了它,你就会开始睡得很舒服。
如果您不能做出决定,那么就与您的经理进行激烈的斗争——您的应用程序需要重构——听起来很糟糕!不要接受拒绝!
我的同情-在我以前的工作中,我遇到过类似的情况,一个文件比你必须处理的文件大几倍。解决方案是:
编写代码详尽地测试程序中的函数。听起来你还没有掌握这个…
确定一些可以抽象为帮助器/实用程序类的代码。不需要很大,只是一些不是你的“主要”类的真正一部分。
重构2中确定的代码。进入一个单独的班级。
重新运行测试,以确保没有损坏。
当你有时间的时候,去2。并根据需要重复以使代码易于管理。
在第3步中构建的类。迭代可能会增加以吸收更多适合于新清除的函数的代码。
我还可以补充:
0:购买Michael Feathers关于使用遗留代码的书
不幸的是,这种类型的工作太常见了,但我的经验是,在保持工作的同时,能够使工作但可怕的代码逐渐变得不那么可怕是有很大价值的。