1 提炼函数(Extract Function)
如果你需要花时间浏览一段代码才能弄清它到底在干什么，那么就应该将其提炼到个函数中，并根据它所做的事为其命名。以后再读到这段代码时，你一眼就能看到函数的用途，大多数时候根本不需要关心函数如何达成其用途（这是函数体内干的事）。
有些人担心短函数会造成大量函数调用，因而影响性能。但如今“由于函数调用影响性能”的情况已经非常罕见了。短函效常常能让编译器的优化功能运转更良好，因为短函数可以更容易地被缓存。应该始终遵循性能优化的一般指导方针，不用过早担心性能问题。
小函数得有个好名字才行，所以你必须在命名上花心思。
经常会看见这样的情况：在一个大函数中，一段代码的顶上放着一句注释，说明这段代码要做什么。在把这段代码提炼到自己的函数中时，这样的注释往往会提示一个好名字。
2 内联函数(Inline Function)
本书经常以简短的函数表现动作意图，这样会使代码更清晰易读。
但有时候你会遇到某些函数，其内部代码和函数名称同样清晰易读。也可能你重构了该函数的内部实现，使其内容和其名称变得同样清晰。
若果真如此，你就应该去掉这个函数，直接使用其中的代码。
间接性可能带来帮助，但非必要的间接性总是让人不舒服。
另一种需要使用内联函数的情况是：我手上有一群组织不甚合理的函数。可以将它们都内联到一个大型函数中，再以我喜欢的方式重新提炼出小函数。如果代码中有太多间接层，使得系统中的所有函数都似乎只是对另一个函数的简单委托，造成我在这些委托动作之间晕头转向，那么我通常都会使用内联函数。
当然，间接层有其价值，但不是所有间接层都有价值。通过内联手法，我可以找出那些有用的间接层，同时将无用的间接层去除。
3 提炼变量(Extract Variable)
表达式有可能非常复杂而难以阅读。这种情况下，局部变量可以帮助我们将表达式分解为比较容易管理的形式。
在面对一块复杂逻辑时，局部变量使我能给其中的一部分命名，这样我就能更好地理解这部分逻辑是要干什么。这样的变量在调试时也很方便，它们给调试器和打印语句提供了便利的抓手。
如果我考虑使用提炼变量，就意味着我要给代码中的一个表达式命名。一旦决定。要这样做，我就得考虑这个名字所处的上下文。
如果这个名字只在当前的函数中有意义，那么提炼变量是个不错的选择；但如果这个变量名在更宽的上下文中也有意义，我就会考虑以函数的形式将其暴露出来。
4 内联变量 (Inline Variable)
在一个函数内部，变量能给表达式提供有意义的名字，因此通常变量是好东西。但有时候，这个名字并不比表达式本身更具表现力。还有些时候，变量可能会妨碍重构附近的代码。若果真如此，就应该通过内联的手法消除变量。
5 改变函数声明(Change Function Declaration)
函数是我们将程序拆分成小块的主要方式。函数声明则展现了如何将这些小块组合在一起工作一可以说，它们就是软件系统的关节。和任何构造体一样，系统的好坏很大程度上取决于关节。
最重要的元素当属函数的名字。一个好名字能让我一眼看出函数的用途，而不必查看其实现代码。
对于函数的参数，道理也是一样。函数的参数列表阐述了函数如何与外部世界共处。函数的参数设置了一个上下文，只有在这个上下文中，我才能使用这个函数。修改参数列表不仅能增加函数的应用范围，还能改变连接一个模块所需的条件，从而去除不必要的耦合。
6 封装变量(Encapsulate Variable)
重构的作用就是调整程序中的元素。
函数相对容易调整一些，因为函数只有一种用法，就是调用。在改名或搬移函数的过程中，总是可以比较容易地保留旧函数作为转发函数（即旧代码调用旧函数，旧函数再调用新函数）。这样的转发函数通常不会存在太久，但的确能够简化重构过程。
如果想要搬移一处被广泛使用的数据，最好的办法往往是先以函数形式封装所有对该数据的访问。这样，我就能把“重新组织数据”的困难任务转化为“重新组织函数”这个相对简单的任务。
封装数据的价值还不止于此。封装能提供一个清晰的观测点，可以由此监控数据的变化和使用情况：我还可以轻松地添加数据被修改时的验证或后续逻辑。
我的习惯是：对于所有可变的数据，只要它的作用域超出单个函数，我就会将其封装起来，只允许通过函数访问。数据的作用域越大，封装就越重要。
面向对象方法如此强调对象的数据应该保持私有(private)，背后也是同样的原理。每当看见一个公开(public)的字段时，我就会考虑使用封装变量（在这种情况下，这个重构手法常被称为封装字段）来缩小其可见范围。一些更激进的观点认为，即便在类内部，也应该通过访问函数来使用字段—这种做法也称为“自封装”。
数据封装很有价值，但往往并不简单。到底应该封装什么，以及如何封装，取决于数据被使用的方式，以及我想要修改数据的方式。不过，一言以蔽之，数据被使用得越广，就越是值得花精力给它一个体面的封装。
7 变量改名(Rename Variable)
好的命名是整洁编程的核心。
如果变量名起得好的话，变量可以很好地解释一段程序在干什么。
但我经常会把名字起错，有时是因为想得不够仔细，有时是因为我对问题的理解加深了，还有时是因为程序的用途随着用户的需求改变了。
使用范围越广，名字的好坏就越重要。只在一行的lambda表达式中使用的变量，跟踪起来很容易，像这样的变量，我经常只用一个字母命名，因为变量的用途在这个上下文中很清晰。同理，短函数的参数名也常常很简单。
8 引入参数对象(Introduce Parameter Object)
我常会看见，一组数据项总是结伴同行，出没于一个又一个函数。这样一组数据就是所谓的数据泥团，我喜欢代之以一个数据结构。
将数据组织成结构是一件有价值的事，因为这让数据项之间的关系变得明晰。使用新的数据结构，函数的参数列表也能缩短。并且经过重构之后，所有使用该数据结构的函数都会通过同样的名字来访问其中的元素，从而提升代码的一致性。
但这项重构真正的意义在于，它会催生代码中更深层次的改变。一旦识别出新的数据结构，我就可以重组程序的行为来使用这些结构。我会创建出函数来捕捉围绕这些数据的共用行为一可能只是一组共用的函数，也可能用一个类把数据结构与使用数据的函数组合起来。这个过程会改变代码的概念图景，将这些数据结构提升为新的抽象概念，可以帮助我更好地理解问题域。
9 函数组合成类(Combine Functions into Class)
类，在大多数现代编程语言中都是基本的构造。
它们把数据与函数捆绑到同一个环境中，将一部分数据与函数暴露给其他程序元素以便协作。它们是面向对象语言的首要构造，在其他程序设计方法中也同样有用。
如果发现一组函数形影不离地操作同一块数据（通常是将这块数据作为参数传递给函数），我就认为，是时候组建一个类了。
类能明确地给这些函数提供一个共用的环境，在对象内部调用这些函数可以少传许多参数，从而简化函数调用，并且这样一个对象也可以更方便地传递给系统的其他部分。
除了可以把已有的函数组织起来，这个重构还给我们一个机会，去发现其他的计算逻辑，将它们也重构到新的类当中。
将函数组织到一起的另一种方式：函数组合成变换。具体使用哪个重构手法，要看程序整体的上下文。使用类似这样的一组函数不仅可以组合成一个类，而且可以组合成一个嵌套函数。通常我更倾向于类而非嵌套函数，因为后者测试起来会比较困难。如果我想对外暴露多个函数，也必须采用类的形式。
10 函数组合成变换(Combine Functions into ransform)
在软件中，经常需要把数据“喂”给一个程序，让它再计算出各种派生信息。这些派生数值可能会在几个不同地方用到，因此这些计算逻辑也常会在用到派生数据的地方重复。
我更愿意把所有计算派生数据的逻辑收拢到一处，这样始终可以在固定的地方找到和更新这些逻辑，避免到处重复。
一个方式是采用数据变换(transform)函数：这种函数接受源数据作为输入，计算出所有的派生数据，将派生数据以字段形式填入输出数据。
有了变换函数，我就始只需要到变换函数中去检查计算派生数据的逻辑。如果代码中会对源数据做更新，那么使用类要好得多；
从道理上来说，只用提炼函数也能避免重复，但孤立存在的函数常常很难找到，只有把函数和它们操作的数据放在一起，用起来才方便。引入变换（或者类）都是为了让相关的逻辑找起来方便。
11 拆分阶段(Split Phase)
每当看见一段代码在同时处理两件不同的事，我就想把它拆分成各自独立的模块，因为这样到了需要修改的时候，我就可以单独处理每个主题，而不必同时在脑子里考虑两个不同的主题。
如果运气够好的话，我可能只需要修改其中一个模块，完全不用回忆起另一个模块的诸般细节。
最简洁的拆分方法之一，就是把一大段行为分成顺序执行的两个阶段。可能你有一段处理逻辑，其输入数据的格式不符合计算逻辑的要求，所以你得先对输入数据做一番调整，使其便于处理。也可能是你把数据处理逻辑分成顺序执行的多个步骤，每个步骤负责的任务全然不同。
在大型软件中，类似这样的阶段拆分很常见。一块代码，只要我发现了有益的将其拆分成多个阶段的机会，同样可以运用拆分阶段重构手法。如果一块代码中出现了上下几段，各自使用不同的一组数据和函数，这就是最明显的线索。将这些代码片段拆分成各自独立的模块，能更明确地标示出它们之间的差异。
