随着程序的演化，我们有必要重新思考早先的决策，并重写部分代码。这一过程非常自然。代码需要演化；它不是静态的事物。
重写、重做和重新架构代码合起来，称为重构。
当你遇到绊脚石 --- 代码不在合适，你注意到有两样东西其实应该合并或是其他任何对你来说是"错误"的东西 --------
不要对改动犹豫不决。应该现在就做。如果代码具备以下特征，你都应该考虑重构代码：
1. 重复。 你发现了对DRY原则的违反。
2.非正交的设计 。 你发现有些代码或设计可以变得更为正交。
3.过时的知识。 事情变了，需求转移了，你对问题的了解加深了 。 代码需要跟上这些变化。
4.性能。 为改善性能，你必须把功能从系统的一个区域转移到另一个区域。
重构你的代码 --------- 四处移动工能，更新先前的决策，事实上市痛苦管理的一次练习。让我们面对它，四处改动源码
可能相当痛苦：它几乎已经在工作，现在事实上却要被撕毁了。许多开发者不愿意，只是因为代码不完全正确就撕毁了代码。
但是在现实的工作中，时间压力常常被用作不进行重构的借口。但这个借口并不成立：现在没能进行重构，沿途修正问题将
需要投入多得多的时间，那是将需要考虑更多的依赖关系。我们会有更多的时间可用吗。我想应该没有。
我们可用用医学上的比喻来向老板解释这一原则:把需要重构的代码当做一个"肿瘤"。切除它需要进行侵入性的外科手术
你现在可用手术，趁它还小的时候把它取出。你也可以等它增大扩散 ------- 但那是再切除它就会更昂贵、更危险。等得久
一点，“病人” 就可能会丧命。
怎样就行重构
就其重构的核心而言，重构就是重新设计。你或你们团队的其他人设计的任何东西可以根据新的事实、更深的理解、变化
需求、等等，重新进行设计。但如果你无节制的撕毁大量代码，你可能会发现自己处在比一开始更糟的位置上。
重构是一项需要慎重、深思熟虑、小心进行的活动。关于怎样进行利大于弊的重构， Martin Fowler 给出了以下提示。
1.不要试图在重构的同时增加工能。
2. 在开始重构之前，确保你拥有良好的测试。尽可能经常运行这些测试。这样，如果你改动破坏了任何东西，你就能很快知道。
3.采取短少、深思熟虑的步骤：把某个字段从一个类移往另一个，把两个类似的方法融合进超类中。重构常常涉及到进行许
多局部改动 ，继而产生更大规模的改动。如果你使你的步骤保持短小，并在每个步骤后进行测试，你将能够避免长时间
的调试。
确保对模块做出剧烈的改动， 比如以一种不兼容的方式更改了其接口或功能，会破坏构建，这也很有帮助。也就是说，这
些代码的客户应该无法通过编译。于是你可以很快找到这些老客户，并做出必要的改动，让他们及时更新。
所以，下次你看到不怎么合理代码是，即要修正它，也要修正依赖它的每样东西。要管理痛苦：如果它现在有损害，但以后
的损害会更大，你也许最好一劳永逸地修正它。不要容忍破窗户。
以上是<<程序员修炼之道>>本书中对代码重构的讲解。