您无法重构解决所有问题的方法

重构是一种纪律严明的方法，可以在您进行更改时澄清，保留或还原系统的设计，并有助于清理和纠正我们在工作中所犯的错误和混乱，以清除错误的启动和更改的证据。方向和向后追踪，并帮助填补空白和误会。

正如我的一位同事所指出的那样，即使是最简单，最明显的重构更改，您也可以从中受益匪浅：消除重复，更改变量和方法名称使其更有意义，提取方法，简化条件逻辑，将幻数替换为命名常量。 这些都是很容易做到的事情，将使您在可理解性和可维护性方面获得巨大回报。

但是重构有局限性-重构无法解决某些问题。

如果设计根本上是错误的，那么重构将无济于事

有些人天真地相信您可以通过重构来解决任何设计错误或误解 ，并且可以将重构用作前期设计的替代品 。 假设您将能够立即识别出客户反馈中的错误和差距，并在开发过程中纠正设计。

但是，这可能需要很长时间，通常只有在真实客户在现实世界中使用该系统来完成实际工作之后，才能了解实际的错误，错失和误解的程度，异常，边缘情况和缺陷。在您最终了解（或接受）不接受之前，请先进行堆积，然后再继续设计并修补您拥有的内容，您不能只是继续扩展它-您需要完全不同的抽象集或完全不同的体系结构。

重构可帮助您进行课程更正。 但是，如果您发现自己一直在以错误的方向或绕圈行驶，该怎么办？

Barry Boehm在平衡敏捷性和纪律中解释说，从简单开始并重构通往正确答案的方式有时会失败：

“迄今为止的经验还表明，随着项目规模的扩大，低成本的重构不能被依赖。 简单设计中出现的最严重问题是被称为“体系结构断路器”的问题。 当早期，简单的设计决策导致可预见的变更，这些变更会导致设计崩溃，超出了重构的处理能力时，就会发生这些非常昂贵的问题。”

这是“ 重构或设计 ”大战中的另一个论点，即应先进行/需要完成多少设计，以及在进行增量更改和重构时可以填写多少设计 。

明智的决定

随着时间的流逝，许多设计思想可以得到完善，完善，迭代和改进，而重构将帮助您。 但是，有关方法，包装，体系结构和技术平台的一些早期决策太基础和太深，无法通过重构进行更改或纠正。

您可以使用重构将内部代码替换为标准库调用，或将一个库换为另一个库-以不同的方式完成相同的事情。 在进行重构时进行小的设计更改和清理工作可用于扩展或填补设计中的空白，并实现诸如日志记录和审核，甚至访问控制和国际化之类的跨领域功能，这就是XP的方法增量设计就是这样。

但是，如果您的体系结构无法扩展，或者您选择了错误的方法，那么进行小规模的设计更改以及对代码结构的改进，提取和移动方法，简化条件逻辑以及摆脱case语句都无济于事。例如SOA）或错误的应用程序框架 （带有Enterprise Java Beans的J2EE，任何多平台UI框架或任何早期的O / R映射框架–记住TopLink的第一个版本吗？或者您在了解如何之前就已经滚动了自己实际使用的语言），错误的语言（如果您发现Ruby或PHP无法扩展 ），或者核心平台中间件技术被证明不可靠，无法承受负载或已被放弃，或者您是针对错误类型的客户设计的系统，并且几乎需要进行所有更改。

重构为模式和大型重构

约书亚Kerievsky的工作重构到模式提供了更高级别的复合重构，改善-或引进-结构的系统，通过适当地实现充分理解设计模式，如工厂和复合材料和观察员，以战略替代条件逻辑等 。

重构为模式有助于清理和纠正诸如

“重复的代码，冗长的方法，条件复杂性，原始的痴迷，不雅的暴露，解决方案蔓延，具有不同接口的替代类，惰性类，大型类，组合爆炸和奇数解”。

Lippert和Roock的有关大型重构的工作解释了如何处理类，包，子系统和层之间以及它们之间的常见体系结构问题，进行丑陋的继承层次结构的改头换面，减少模块之间的耦合，清理依赖缠结，并纠正体系结构层之间的冲突。诸如Structure 101之类的工具可以帮助您了解和理解的事物。

他们发现了一组建筑气味和重构来纠正它们：

• 在依赖图中闻到：可见的依赖图，树状依赖图，类之间的循环，未使用的类
• 在继承层次结构中闻到：并行继承层次结构，类似列表的继承层次结构，没有多态分配的继承层次结构，继承层次结构太深，没有重新定义的子类
• 包裹中有异味：未使用的包裹，包裹之间的循环，太小/太大的包裹，包裹的名称不明确，包裹太深或嵌套不平衡
• 子系统中有异味：子系统过度泛化，子系统API被绕过，子系统太小/太大，子系统太多，没有子系统，子系统API太大
• 分层嗅到：太多层，没有层，违反了严格的层，垂直分开的层之间的引用，层中的向上引用，面向协议的层之间的继承（耦合）。

复合重构和大型重构将重构提升到更高的抽象性和实用性水平，并向您展示如何自行识别问题以及如何提出自己的重构模式和策略 。

但是，重构为模式甚至大规模重构仍不足以取消或重新制定深层次的决策或更改系统设计和体系结构的基础假设。 或挽救不安全重构或值得重构的代码。

有时您需要重写而不是重构

在放弃并重写它 之前 ，而不是试图通过它重构方式之前，必须要有多少糟糕的代码是没有争议的 。

最好的答案似乎是，重构应该始终是您的第一选择， 即使对于您没有编写，不理解，无法测试的遗留代码 （有整本书都写着如何以及在何处开始重建遗留问题） spps ）。

但是，如果代码无法正常工作，或者它是如此不稳定且如此危险，以至于试图对其进行重构只会带来更多问题，如果您无法重构甚至修补它而不产生新的错误，或者您需要重构过多的代码，将其设置为可接受的形状的代码（我读过20％左右的代码是一个很好的起点，但我找不到参考），那么该宣布技术破产并重新开始了。 从头开始重写代码有时是您唯一的选择。 某些代码不应该或不能保存。

“有时代码不需要做些小改动-需要将其扔掉以便重新开始。 如果您发现自己处于主要的重构会话中，请问自己是否应该从头开始重新设计和重新实现那部分代码。 Steve McConnell， 代码完成

您可以使用重构来还原，修复，清理或调整设计甚至系统的体系结构。 重构可以帮助您回过头来进行更正，降低复杂性并填补空白。 它将为减少持续开发和支持的成本和风险而分红。

但是，如果您必须重新构造系统，或者仅仅需要做一些根本不同的事情，或者需要以根本不同的方式做事，或者代码不值得挽救，那么重构还不够。 不要因为重构永远是正确的事情而相信自己，或者您可以从每个问题中重构自己。

参考： Building Real Software博客上的JCG合作伙伴 Jim Bird 无法重构解决每个问题的方法 。

翻译自: https://www.javacodegeeks.com/2012/10/you-cant-refactor-your-way-out-of-every-problem.html