重构的局限性是什么？

Question

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

Answer 1

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

Answer 2

重构可能是有风险的

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

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

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

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

因此，如果您的目标是在不进行重大功能更改的情况下实现长期稳定，那么主要的重构通常不是您想要的。

然而，如果你在pike中有更大的功能变化，有一个用户群希望你的产品还没有完全烘焙(即你处于某种测试版)，那么考虑认真的重构要好得多，因为卓越设计的长期好处将会得到回报，你不太可能破坏一个庞大的用户群。

Answer 3

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