当属于下列情况时，你不该重构

　　• 对于你来说，它的逻辑看起来过于复杂，你没有花时间去分析它。

　　• 你不理解为什么前任程序员要这样编写。

　　• 你着手的是一个很重要的系统，而且时间很紧。

　　• 你是团队里的新成员，或新接触这个项目，或这种语言。

　　当属于下列情况时，你可以重构

　　• 现有的代码对它要实现的功能显得过于复杂，并且你分析过它。

　　• 修改后的代码远比现存的代码逻辑要清晰。

　　• 你有足够的时间，人手，财力来支持对项目进行回归测试。

　　• 现有的代码陈旧无效率。

　　• 无人认领的，写的很烂的代码都属于此类。

　　• 跟你的一位同事谈论对这部分程序进行重构的好处和存在的风险，你们两个都赞成重构。

　　如何降低重构的风险

　　权衡一下对一段代码进行重构的利与弊，找出降低风险的方法。调试一段你经过重构但却使产品崩溃的代码，这对你来说将会是在这个行业中最有压力的事情。

　　• 使用自动化的回归测试，快速的验证你的修改。这非常重要，如果没有准备自动化测试，你应该在做任何修改前建好它。

　　• 尽量让你的重构处于很短的开发周期，产品更新发布周期也尽可能短。

　　• 把你重构的代码和其它程序隔离开，这样能让你更容易找到出问题的地方。

　　• 为你的重构活动准备测试计划，包括回归测试，功能测试，反向测试，负载测试，性能测试和用户确认测试。

　　• 投入全部精力来研究其中的逻辑，不要分心做其它事情。

　　• 在需要的地方使用设计模式。不要为了设计模式而增加设计模式。设计模式应该用在合适的时间和合适地方。

　　小粒度重构

　　当你在开封一个方法时，如果你发现其中有一部分可以改进，那你就该考虑它，改进它。整洁的代码是我们需要的，因为写的很烂的代码我们到处可见。和你的同事讨论它们，当有人要修改你的代码时不要固守己见。重构，然后回归测试，然后才提交代码。没有人希望自己提交的代码会弄垮系统。

　　程序员的职业素养

　　忍住你的欲望，不要试图重构你不理解的代码。多问问题，努力能清楚他们为什么要把程序写成这样。也许他们有很好的理由。如果你找到一段很古老的代码，很有可能它们是按照古老的方式写的。每天都在新增的API，模式，需求和新领会都会让这些老的方式显得陈旧。不断努力学习新的技术，但不要为了要使用这些技术而过于热心的在重构中使用它们。