第一章 重构：第一个案例
重构之前，首先检查自己是否有一套可靠的测试机制。这些测试必须有自我检验能力。
重构技术就是以微小的步伐修改程序。如果你犯下错误，很容易便可发现它。
任何一个傻瓜都能写出计算机可以理解的代码，唯有写出人类容易理解的代码，才是优秀的程序员。
代码应该表现自己的目的，这一点非常重要。
重构的节奏：测试、小修改、测试、小修改…正是这种节奏让重构得以快速而安全地前进。
第二章 重构原则
重构（名词）：对软件内部结构的一种调整，目的是在不改变软件可观察行为的前提下，提高其可理解性，降低其修改成本。
重构（动词），使用一系列重构首发，在不改变软件可观察行为的前提下，调整其结构。
添加新功能时，你不应该修改既有代码，只管添加新功能。通过测试，你可以衡量自己的工作进度。
重构时你就不能再添加新功能，只管改进程序结构。此时你不应该添加任何测试（除非发现先前遗漏的东西），只在绝对必要（用于处理接口变化）时才修改测试。
重构本来就不是一件应该特别拨出时间做的事情，重构应该随时随地进行。你不应该为重构而重构，你之所以重构，是因为你想做别的什么事，而重构可以帮助你把那些事做好。
添加功能时重构；修补错误时重构；复审代码时重构
是什么让程序难以修改？
- 难以阅读的程序，难以修改
- 逻辑重复的程序，难以修改
- 添加新行为时需要修改已有代码的程序，难以修改
- 带复杂条件逻辑的程序，难以修改
何时不该重构？
有时候你根本不应该重构，例如当你应该重新编写所有代码的时候。有时候既有代码写的太混乱，重构它还不如重新写一个来得简单。重写的一个清楚讯号就是：现有代码根本不能正常运作。而‘重构’之前，代码必须起码在大部分情况下正常运作。
重构的确能够提高生产力。如果你最后没有足够时间，通常就表示你其实早该进行重构。
重构与设计
初学编程时，浑浑噩噩地进行开发。然而很快我便发现，事先做好设计可以让我节省返工的高昂成本
第三章 代码的坏味道
- 重复代码
- 过长函数
- 过大的类
- 过长参数列（有了对象，你就不必把函数需要的所有东西以参数传递给它了。太长的参数列难以理解。）
- 发散式变化（我们希望一旦需要修改，就只在某一点处修改）
- 依恋情结（某个函数为了计算某个值，从另一个对象那儿调用了大部分函数）
- 过度耦合的消息链
- 异曲同工的类（两个函数做同一件事，却有着不同的函数名）
- 过多的注释（长长的注释之所以存在是因为代码很糟糕。当代码已经清楚的说明一切时，注释就多余了。当你感觉需要撰写注释时，请先尝试重构，试着让所有注释都变得多余。）
每当感觉需要以注释来说明点什么的时候，我们就把需要说明的东西写进一个独立函数中，并以其用途（而非实现手法）命名。哪怕替换后的函数调用动作比函数自身还长，只要函数名称能够解释其用途，我们也该毫不犹豫地那么做。关键不在于函数的长度，而在于函数“做什么”和“如何做”之间的语义距离。
条件表达式和循环常常也是提炼的信号。你应该将循环和其内的代码提炼到一个独立的函数中。
测试
编写测试代码时，我往往一开始先让他们失败。之所以这么做，是为了向自己证明：测试机制的确可以运行，并且的确测试了它该测试的东西。
