重构应该变得像空气和水一样普通，在不改变软件可观察行为的前提下改变其内部结构。
如果你编写的是一个永远不需要修改的程序，那么剪剪贴贴还好，但是如果程序要保存很长时间，而且还可能需要修改，那么复制粘贴行为就会造成潜在的威胁
永远不要依靠复制粘贴解决问题，那样只会让你的代码越来越不可控，这是真的教训
如果你发现自己需要微程序添加一个特性，而代码结构使你无法很方便地达成目的，那就先重构那个程序，使得添加特性更加容易进行，然后再添加特性
进行重构的时候 需要依赖测试，让它告诉我们是否引入了bug；好的测试是重构的根本，花时间建立一个优良的测试机制是完成值得的，因为当你测试程序时，好的测试会给你必要的安全保障。测试机制在重构的领域时很重要的；
重构前先检查自己是否有一套可靠的测试机制，这些测试必须有自我检验能力
代码块越小，代码的功能就愈容易管理，代码的处理和移动就更轻松
- 找到代码的逻辑泥团，任何不会被修改的变量都可以被当成参数传入，若一个变量会被修改，就可以把它当成返回值
重构就是以微小的步伐修改程序，如果你犯下错误，很容易便可以发现它
更改变量名称是值得的行为吗？绝对是，好的代码应该清楚表达哦资的功能，变量名称是关键。如果为了提高代码的清晰度，需要修改某些东西的名字，那就大胆去做吧
任何一个傻瓜都能写出计算机可以理解的代码，唯有写出人类容易理解的代码才是优秀的程序员。
代码应该表现自己的目的
函数应该放在他所使用的数据的所属对象内
应该尽量除去这一类的临时变量，临时变量往往会引发问题，他们会导致大量参数被传来传去，你很容易跟丢他们，长长的函数更容易如此，当然这样做也付出了性能的代价，因为有些时候会被重复计算一些值，但是这种情况很容易被优化的
去除临时变量，他们只在自己的函数中有效，所以他们会助长冗长而复杂的函数。
除非我进行评测，否则我无法确定循环的执行时间，也无法知道这个循环是否精彩使用以至于影响系统的整体性能，重构时你不必担心这些，优化时的你才应该担心这些，但是那个时候你已经处于一个比较有利的地位，有更多的选择可以完成有效优化。
最好不要在另一个对象的属性基础上运用switch语句，如果不得不使用，那应该在对象自己的数据上使用，而不是在别人的数据上使用
一部影片可以在生命周期内修改自己的分类，一个对象却不能在生命周期内修改自己所属的类，不过这里有个解决办法：state模式【Gang Of Four】，加入一个price层进行子类化操作
所有重构的行为都是使得程序的责任分配更加合理，代码的维护更轻松，风格更迥异于过程化的风格，但是若你习惯了重构后的风格，你将很难再满足于结构化的风格了。
重构的节奏：测试、小修改、测试、小修改…，这种节奏让重构得以快速安全地进行
