关闭。这个问题是opinion-based .它目前不接受答案。
想改善这个问题吗？更新问题，以便可以通过 editing this post 用事实和引文回答问题.
2年前关闭。
Improve this question
由于非常晚的主要需求更改，当前正在对应用程序进行相当大的重构。
我总是觉得当我在做这种事情时，我并没有以一种非常有纪律的方式来接近它。我的应用程序可能会一次运行数天/数周，处于无法构建或需要注释掉大量代码才能编译的状态。
我不喜欢在这种状态下检查源代码管理，所以我经常觉得如果我犯了一个大错误，我就没有退路。我现在正在销毁我的应用程序，我脑子里有 100 个不同的线程。就像你读到的那些人一样，他们出于好奇将他们的汽车发动机拆开，然后意识到他们不知道如何将它们重新组装起来。
是否有任何好的资源可以讨论如何以增量和破坏性较小的方式进行重构？任何人都可以提供任何建议吗？还是大家都有这种感觉？
最佳答案
你描述的其实是不是 重构。
重构是对 的纪律严明的努力在不改变其功能的情况下改进代码的设计 ，以很小的 - 甚至是简单的 - 步骤完成，由单元测试保护 ，确保 每一步后系统都可以正常工作 .此外，它通常在更长的时间内以小增量完成，而不是在一个大的嗖嗖声中完成。
这不是对任何事情过于热心，只是为了澄清术语:-) 当我们以相同的方式理解相同的单词时，误解和沟通问题的可能性较小。
当然，如果你有时间一次做很多重构，那就更好了!但在你开始这样的努力之前，你绝对需要构建一套好的单元测试 理想情况下，它涵盖了您将要更改的代码部分中的所有功能。
既然你说的是“重大需求变更”，那么你所说的“重构”究竟是实现新功能，还是只是改进设计，为引入新功能做准备，目前还不清楚。我强烈建议将两个阶段分开:首先在不改变现有功能的情况下进行重构，使您的设计对正确位置的扩展更加开放 ，这样您就可以更轻松地合并所需的功能更改。
@Eric 链接的重构书是基础；我要添加 Refactoring to Patterns作者:Josh Kerievsky，这是关于重构的实际应用。
关于oop - 如何使重构更少 "destructive"？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/4817773/