我正在研究重构对改进现有软件体系结构的局限性，我很想听听经验，我们发现重构不足或者还不太成熟，无法实现目标。

解决方案

重构可能有风险

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

当一个不熟悉该系统的新的或者年轻的团队成员决定将new-cool-wizbang技术或者思想注入到本来稳定的系统中时，尤其如此。通常，当新的团队成员没有很好地融入团队并没有得到足够的指导时，他们可能会开始按照整个团队意想不到的方向来推动项目。

这只是一种风险，但是，也有可能团队错了，如果新团队成员掌管并被允许去做他或者她的事情，实际上会带来很大的进步。

这些问题通常出现在研究遗留系统的团队中。通常，没有计划改变世界的增强功能，因此团队在设计时比较保守。他们的目标是防止注入新的错误，并使用一些额外的功能修复旧错误。新团队成员可能会坚持要求改写某些代码子系统，从而使苹果购物车陷入困境。从这个角度来看，由于该软件的性能越来越差，因此会创建新的错误，并使相当稳定的产品的用户感到不安。

因此，如果目标是长期稳定性而不更改主要功能，则通常不需要主要的重构。

但是，如果我们在长矛中进行了较大的功能更改，那么有一个用户群希望产品尚未完全烘焙(例如，我们处于某种beta版本)，那么考虑进行认真的重构是一个更好的选择，因为优质设计的长期利益将获得回报，并且我们破坏大型用户群的可能性也较小。

没有相应的一组单元测试套件的重构代码可能会有风险。如果项目已经有一个已建立的单元测试套件，那么只要我们维护TDD方法，就没有什么值得担心的理由了。

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

因此，风险在于花费太多时间进行重构。

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

我不太确定问题是否有效。我们在问重构的局限性。但是，重构涉及代码的重写。如何限制我们重写的内容？我们可以在大规模重构过程中逐步地完全替换旧代码。实际上，我们可以不用原始代码的单个字符就可以结束重构，尽管这是极端的。鉴于重构的可能性太远了，我们如何假设可能存在任何限制？如果所有最终代码都可能是全新的，则与从头开始编写最终代码相比，我们没有更多的限制。但是，从头开始编写相同的结果代码将给我们提供更少的基础，也使得进行迭代开发的机会更少，因此我必须以一个反问来回答：与任何重写相比，任何重构都固有地具有更少的限制吗？

迈克尔·费瑟斯(Michael Feathers)致敬凯夫(Kev)的出色答案"有效地使用遗留代码"是软件工程领域的工作人员必读的书。