3、难以通过重构手法完成的设计改动

　　通过重构，可以排除所有设计错误吗？是否存在某些核心设计决策，无法以重构手法修改？在这个领域里，我们的统计数据尚不完整。当然某些情况下我们可以很有效地重构，这常常令我们倍感惊讶，但的确也有难以重构的地方。比如说在一个项目中，我们很难（但还是有可能）将「无安全需求（no security requirements）情况下构造起来的系统」重构为「安全性良好的（good security）系统」。

　　这种情况下我的办法就是「先想象重构的情况」。考虑候选设计方案时，我会问自己：将某个设计重构为另一个设计的难度有多大？如果看上去很简单，我就不必太担心选择是否得当，于是我就会选最简单的设计，哪怕它不能覆盖所有潜在需求也没关系。但如果预先看不到简单的重构办法，我就会在设计上投入更多力气。不过我发现，这种情况很少出现。

　　4、何时不该重构？

　　有时候你根本不应该重构 — 例如当你应该重新编写所有代码的时候。有时候既有代码实在太混乱，重构它还不如从新写一个来得简单。作出这种决定很困难，我承认我也没有什么好准则可以判断何时应该放弃重构。

　　重写（而非重构）的一个清楚讯号就是：现有代码根本不能正常运作。你可能只是试着做点测试，然后就发现代码中满是错误，根本无法稳定运作。记住，重构之前，代码必须起码能够在大部分情况下正常运作。

　　一个折衷办法就是：将「大块头软件」重构为「封装良好的小型组件」。然后你就可以逐一对组件作出「重构或重建」的决定。这是一个颇具希望的办法，但我还没有足够数据，所以也无法写出优秀的指导原则。对于一个重要的古老系统，这肯定会是一个很好的方向。

　　另外，如果项目已近最后期限，你也应该避免重构。在此时机，从重构过程赢得的生产力只有在最后期限过后才能体现出来，而那个时候已经时不我予。Ward Cunningham对此有一个很好的看法。他把未完成的重构工作形容为「债务」。很多公司都需要借债来使自己更有效地运转。但是借债就得付利息，过于复杂的代码所造成的「维护和扩展的额外开销」就是利息。你可以承受一定程度的利息，但如果利息太高你就会被压垮。把债务管理好是很重要的，你应该随时通过重构来偿还一部分债务。

　　如果项目已经非常接近最后期限，你不应该再分心于重构，因为已经没有时间了。不过多个项目经验显示：重构的确能够提高生产力。如果最后你没有足够时间，通常就表示你其实早该进行重构。

　　代码坏味道

　　1、重复的代码。

　　如果你在一个以上的地点看到相同的程序结构，那么可以肯定：设法将他们合二为一。

　　2、过长的函数。

　　越短的函数会存活的时间更长，存活的更好。

　　3、过长的类。

　　如果想利用单一的类做很多的事情，那么该类的内部会出现很多的instance变量，重复代码就要接踵而至了。

　　4、过长的参数列。

　　太长的参数列难以理解，太多的参数会造成前后不一致，不易使用，一旦你需要更多的数据，就不得不修改它。

　　5、发散式变化。

　　一旦我修改软件，我希望只在一处修改就好，如果不能做到这点，该坏味道就出现了。

　　6、烟雾弹式修改。

　　一旦软件进行修改，你必须去对多个类的内部做小修改，该坏味道出现了。

　　7、依恋情结。

　　函数对某个类的兴趣高过对自己所处之host类的兴趣，坏味道出现了。