重构代码很危险，它会给测试工作增加巨大的负担。除非你的程序需要重构，一定不要轻易重构代码。我这里所说的并不是把一个for循环改成while循环，或把一个StringBuffer改成StringBuilder，我说的是大动作，例如重写一个方法，一个函数，甚至整个类或包。如果你缺乏对一个方法或一个类的了解，那你重构它的条件就不充分。即使你有一个天才的计划，你也需要和团队一起设计其中重大的修改。

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

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

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

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

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

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

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

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

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

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

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

• 
  

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

如何降低重构的风险

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

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

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

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

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

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

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

小粒度重构

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

下面是一些比较有深度的阅读材料。

• 重构:改善既有代码的设计

• 代码整洁之道

• Working Effectively with Legacy Code

• 程序员的职业素养

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

---

本文来自外刊IT评论网(www.aqee.net)，原始地址：如何避免重构带来的危险

建议继续学习：

1. 抵制代码重写    (阅读：4258)
2. 什么是重构，什么不是重构    (阅读：3491)
3. 前端重构实践（一） —— 性能优化    (阅读：3187)
4. 实践中的重构    (阅读：3051)
5. 网站重构到底是什么，网站重构到底要多久    (阅读：2926)
6. 关于重构和重写    (阅读：2589)
7. 重构发现：指针操作问题    (阅读：2403)
8. 网页重构应该避免的10大 CSS 糟糕用法    (阅读：2256)
9. 实战遗留代码    (阅读：1804)
10. 代码重构方向原则指导    (阅读：1637)