重构有哪些局限性？

Question

我正在研究改进现有软件架构的重构限制，我很想听听你的经验，你发现重构不够或者还不成熟，无法实现你的目标。

Answer 1

重构可能有风险

重构通常很困难，因为重构器通常与原始设计者不同。因此，他或她在系统和原始设计背后的决策中没有相同的背景。您总是冒着原设计中避免的错误可能会在新设计中出现的风险。

当一个没有完全体验过这个系统的新的或年轻的团队成员决定向一个稳定的系统注入新的冷却技术或想法时，情况尤其如此。通常，当新的团队成员没有很好地融入团队并且没有得到足够的指导时，他们可能会开始强迫整个团队无意中执行项目。

这只是一种风险，但是，团队也有可能出错，新的团队成员，如果负责并被允许做他或她的事情，实际上会做出重大改进。

这些问题经常出现在一个致力于遗留系统的团队中。通常没有计划改变世界的增强功能，因此团队的设计保守。他们的目标是防止注入新的错误并修复旧的错误，并添加一些额外的功能。一个新的团队成员可能会坚持认为，他重写了代码的某些子系统，从而打乱了苹果车。创建了新的错误，并且相当稳定的产品的用户感到不安，因为从那时起软件变得越来越糟糕。

因此，如果您的目标是长期稳定而没有重大功能变化，那么通常重大的重构并不是您想要的。

如果你在派克中有更大的功能变化，那么拥有一个用户群，期望你的产品还没有被完全烘焙（即你处于某种类型的测试阶段），那么它应该考虑更好的情况严重的重构，因为优越设计的长期利益将得到回报，你不太可能破坏庞大的用户群。

Answer 2

重构没有相应的单元测试套件的代码可能存在风险。如果该项目已经建立了单元测试套件，那么只要您保持TDD方法，就没有什么值得关注的。

Answer 3

我不太确定你的问题是否有效。你问的是重构的局限性。但是，重构涉及重写代码。你重写的内容怎么限？您可以在大规模重构过程中完全替换旧代码。实际上，您可以在没有原始代码的单个字符的情况下结束重构，尽管这无疑是极端的。鉴于重构可能性的这一远端，您如何假设可能存在任何限制？如果所有最终代码都可能是全新的，那么您没有比从头开始编写最终代码更多的限制。但是，从头开始编写相同的结果代码会减少继续使用的基础，减少迭代开发的机会，因此我必须回答一个反问题：任何重构本身都没有比任何重写更少的限制吗？

Answer 4

并非所有经理都喜欢重构的想法。在他们看来，重构所花费的时间并不用于添加新功能。因此，您需要说服您的经理需要它，或者您可以在添加功能时隐藏它。

因此风险是花费太多时间来重构。

Answer 5

当您无法更改类的外部接口时，会出现重构的一个问题。在这些情况下，您对重构的内容非常非常有限。

Answer 6

对于Kev的优秀答案 - Michael Feathers的“有效使用遗留代码”应该是需要阅读软件工程人员的。