refactoring - 重构的局限性是什么？

Question

我正在研究重构对改进现有软件架构的限制，我很想听听您的经验，您发现重构不足以或仍然太不成熟而无法实现您的目标。

Answer 1

重构可能有风险

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

当一个新的或年轻的团队成员对这个系统没有完全的经验，决定将新的酷wizbang技术或想法注入一个稳定的系统时，尤其如此。通常，当新的团队成员没有很好地融入团队并且没有得到足够的指导时，他们可能会开始迫使项目朝着整个团队意想不到的方向发展。

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

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

因此，如果您的目标是在没有重大功能更改的情况下保持长期稳定性，那么重大重构通常不是您想要的。

但是，如果您在 pike 中有较大的功能更改，并且有一个用户群期望您的产品尚未完全成熟（即您处于某种测试阶段），那么考虑进行认真的重构是一个更好的情况，因为卓越设计的长期利益将得到回报，并且您不太可能破坏庞大的用户群。

Answer 2

重构没有相应单元测试套件的代码可能会有风险。如果项目已经建立了单元测试套件，那么只要您保持 TDD 方法，就应该没有什么担心的理由。

Answer 3

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

Answer 4

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

所以风险是花费太多时间来重构。

Answer 5

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

Answer 6

对于 Kev 的出色回答 - Michael Feathers 的“有效地使用遗留代码”应该是从事软件工程工作的人必读的。