我将在一个巨大的代码库(18000+ Java类)中重构某些部分。目标是能够提取较低层作为独立库,以便在当前使用此代码库副本的其他项目中重用。特别是其中一个部分需要重构为独立于业务逻辑的框架。最终,我希望代码有一个干净的架构分层。
我用一个名为Structure 101 for java的工具查看了代码,发现了很多(!)架构分层问题,其中较低层引用较高层。
我不想简单地开始弄乱代码,而是尝试想出一个合理的策略来解决这个问题。我应该记住什么事情?
我在想至少要迈出一小步。我也在考虑建立单元测试,但这需要创建它们,因为没有单元测试。
对此有什么想法吗?
发布于 2009-05-16 00:10:42
您还应该看看使用Michael Feathers的遗留代码:
我认为你可以采取的最重要的事情之一是测试,以确保在重构/拉出到单独的模块后一切仍然正常工作。通过引入持续集成系统来补充这一点,该系统在您签入某些东西时运行您的测试。
发布于 2009-05-16 00:05:32
18,000个类真的走向了“巨大”的终点。这会给你带来明显的问题,包括构建/编译时间,以及当你启动ide时计算机冒烟。
我的第一个假设是,有这么多的类,有很多重复的通用功能,可能没有使用的类,甚至可能是子系统。我之所以想到这一点,是因为当事情变得如此庞大时,开发人员越来越有可能不知道整个系统,或者不知道那些Util函数在哪里,并且发现编写一个新的函数会更容易。寻找要删除的冗余将有助于简化。
另一个可能的冗余来源是无用的深层类层次结构,或者是一堆毫无意义的接口(举个例子--我工作的地方有一个目录,大约有50个类,大多数超过1000行(不是我的,也不是我的!)。这些方法中的每一个都实现了一个接口,这个接口只不过是它自己的方法框架。这些接口没有其他实现。所有50个都可以删除而不会出现问题)。还有一些开发人员刚刚发现了OO,并且非常热衷于OO--你知道的,一个具体的实现,扩展了5个抽象类和3个接口的链。
除此之外,我会尝试提取一部分代码(最多只有几百个类),并将它们移到一个子项目中,然后将其作为jar链接到main。然后,你可以平静地工作,合理地希望能够理解整个事情-这也有心理方面的原因-如果你觉得自己在做一件巨大的、令人费解的事情,那就没有动力做好工作,而如果你正在做你完全理解的干净的子项目。
发布于 2009-05-15 23:29:37
第一件事:祝你好运,你会需要它的。这可能是你遇到的一项艰巨的工作。这对我来说听起来很熟悉;我以前也做过类似的事情。
需要考虑的一件事是:在开始重构之前,我真的会强烈地考虑将一个广泛的测试框架放在适当的位置。原因是:有了好的单元测试和回归测试,您可以开始进行更改,而不必太担心破坏现有功能。(这就是说,总会有一个担忧,但是...)
也就是说:我会考虑将不同的“垂直”功能切片,看看是否可以为它们编写不同的单元和集成测试;一旦完成,我就会立即开始重构工作。虽然一开始它可能非常小,但仅仅是隔离垂直功能切片,然后为其编写集成和单元测试代码的过程就会让您获得大量使用现有代码库的经验。如果你一开始就能让它变得更好一点,那么你就领先了那么多。
完成后,开始寻找潜在的更大的功能块来进行重构。如果不可能获得干净的功能块来重构,我会开始寻找小块;如果您可以找到一小块(有时非常小)代码块来进行提取、单元测试和重构,那么您就前进了。这有时看起来进展很慢,如果你有一个非常大的项目,它会的,但你会有一个凹痕。
但通常情况下,请考虑先进行测试以确认预期的功能。一旦这些测试到位,你就可以有信心地重构(不是十全十美的信心,但总比什么都没有强),相信你没有破坏一些东西。从小处开始,并在现有代码库之外揭示自身的技术基础上构建。这是一个漫长的过程,但你最终会到达那里,并且代码库会对它更好。
https://stackoverflow.com/questions/871238
复制相似问题