我正在尝试重构一个大型紧密耦合的应用程序，并试图使其更易于维护和灵活。
我有很多单元测试，所以我希望逐步重构。
我应该考虑实施/应用哪些设计和重构模式来完成这项任务？
我能想到一些：
也可以随意分享你自己的这种重构工作的经验和最佳实践。
更新
由于这个问题中解释的原因，我正在执行此重构。基本上我不能在不提取几个接口的情况下实现插件系统，并且这些接口是高度耦合的，这需要将应用程序分离到 40 多个 DLL 中才能在没有循环引用问题的情况下进行编译。
问问题
2796 次
6 回答
9
说真的，重构并不是一件可以掉以轻心的事情，尤其是在紧密耦合的系统中。在执行之前，它通常看起来像是一项值得的任务，但根据我的经验，一旦开始它很快就会成为一种负担，因为它通常更可能引入新的错误而不是解决任何现有的问题。
在着手进行重大重构之前，您应该考虑将获得哪些收益以及有哪些替代方案（例如从头开始创建新产品，仅立即重构需要它的部分等）。在开始之前，您当然应该对架构、角色和职责以及预期和现有的行为有一个很好的了解，以确保您知道什么时候出了问题。
此外，制定重构后的设计以及如何映射到当前实现，这样您就可以保持重点，这可能是有益的。您还应该尽可能频繁地进行回归测试。
当设计显然需要重构时，完美主义者可能会感到沮丧，但有时必须考虑更改的成本/收益并承认战斗。如果你必须做出改变，小心行事，不要试图一次做太多。
于 2009-04-27T17:37:04.020 回答
9
这是一个很大的问题，一个人可以写一本书来回答它。幸运的是，有人已经有了。获取一份Michael Feathers的《有效使用遗留代码》的副本。这几乎是一整本书，专门用来回答你的问题。
这也是一本非常好的书。我肯定会将它与Code Complete、Design Patterns和Pragmatic Programmer一起放在每个开发人员图书馆都应该包含的书籍列表中。
于 2009-04-27T17:56:46.673 回答
5
重构接口和依赖注入将是减少耦合的关键。您可能还想考虑使用工厂来创建依赖对象。
于 2009-04-27T17:37:43.333 回答
2
以上所有，然后一些。 但在你开始之前，我会考虑大局。定义程序的各个部分（包、项目等），然后制定计划将功能移动到适当的包中。然后，一旦一切都在逻辑上应该开始使用提取接口、依赖注入和工厂方法开始解耦包。
于 2009-04-27T17:59:33.000 回答
1
菲利普的一些好建议： 重构低悬的果实
我认为如果没有更多信息，很难说哪些特定的重构适合您的特定情况。
于 2009-04-27T18:03:11.620 回答
0
感谢所有答案，在尝试了这么多不同的方法之后，我发现最好的办法就是为所有东西创建接口。这让我可以自由地更改设计，我只中断了一天的构建（一天因为项目很大，我需要修复这么多的引用和单元测试 + 一些重构）。
经过一天的提取和修复所有界面后，我可以创建单独的解决方案并自由地使用设计。
基本上，我认为首先应该将所有内容移至接口，然后尝试摆脱内部依赖项。
于 2009-04-29T20:24:28.953 回答