我正在尝试重构一个紧密耦合的大型应用程序,并尝试使其更易于维护和灵活。
我有很多单元测试,所以我希望一步一步重构。
哪种设计&重构模式我应该考虑实施/应用来完成这项任务吗?
我能想到一些:
也可以随意分享您自己的经验和这种重构工作的最佳实践。
更新
我正在进行这次重构because of the reasons explained in this question。基本上我不能在不提取几个接口的情况下实现插件系统,并且这些接口是高度耦合的,这需要将40多个DLL中的应用程序分开,以便在没有循环引用问题的情况下进行编译。
答案 0 :(得分:8)
严肃地说,重构不是一个可以掉以轻心的事,特别是在紧耦合系统中。它在执行之前通常看起来是一项有价值的任务,但根据我的经验,它很快就会成为负担,因为它通常更有可能引入新的错误而不是解决任何现有的问题。
在开始进行重大重构之前,您应该考虑收益是什么以及有哪些替代方案(例如从头开始创建新产品,仅重构需要它的部分等等)。在开始之前,你当然应该很好地理解架构,角色和责任,以及预期和现有的行为,以确保你知道什么时候你已经破坏了什么。
此外,在重构之后绘制一个如何设计的设计以及如何映射到当前实现以便您可以保持重点是有益的。您还应该尽可能经常进行回归测试。
当设计明显需要重构时,完美主义者可能会感到沮丧,但有时必须考虑变更的成本/收益并承认战斗。如果你必须做出改变,请小心行事,不要试图立刻做太多。
答案 1 :(得分:8)
这是一个很大的问题,人们可以写一整本书来回答它。幸运的是,有人已经拥有。请自己获取Michael Feathers的有效使用遗留代码的副本。这几乎是一本专门回答你问题的书。
这本书也是一本非常好的书。我肯定会在代码完成,设计模式和实用程序员的每个开发人员应该在的书籍列表中提出它库。
答案 2 :(得分:5)
重构接口和依赖注入将是减少耦合的关键。您可能还想考虑使用工厂来创建依赖对象。
答案 3 :(得分:2)
以上所有,然后是一些。但在你开始之前,我会想到全局。定义程序的各个部分(包,项目等),然后制定一个计划,将功能转移到适当的包中。然后,一切都在逻辑上应该开始使用提取接口,依赖注入和工厂方法来开始解耦包。
答案 4 :(得分:0)
来自Phlip的一些很好的建议: Refactor the Low-hanging Fruit
我认为在没有更多信息的情况下,很难说出具体情况下哪些特定的重构是合适的。
答案 5 :(得分:0)
感谢所有的答案,在经历了许多不同的方式之后,我发现最好的办法就是为所有东西创建接口。这让我可以自由地改变设计,我只打破了一天的构建(一天,因为项目很大,我需要修复这么多的引用和单元测试+一些重构)。
在提取和修复所有界面后,我可以创建单独的解决方案并自由地使用设计。
基本上我认为首先应该将所有内容移动到接口,然后尝试摆脱内部依赖关系。