6.2 Inline Method

紧随Extract Method之后，作者也说了，间接层有其价值，但不是所有间接层都有价值。

6.4 Replace Temp with Query

说到性能问题，在重构时可以降低性能问题的优先级，因为很多情况下不会造成影响。如果性能真的出了问题，也可以在优化时期解决它。如果代码组织良好，往往能帮助发现更有效的优化方案。当然，如果性能真的是在受到了很大的影响，可以再恢复回去。

10.4 Separate Query from Modifier

任何有返回值的函数，都不应该有看得到的副作用。

6.1 Extract Method

提炼（extracting）代码，使每个函数的粒度变小，有着很多好处：函数复用的机会变大；可读性强；函数的override更容易等。

作者说：即使想要提炼的代码非常简单，简单到知识一条消息或一个函数调用，只要新函数的名称能够以更好的方式昭示代码意图，也应该提炼它。

在嵌入式环境里，尤其是空间资源有限的条件下，对Extract Method方法的运用可能需要做一点调整。

单纯使函数粒度变小的提炼需要慎重，除非实际已有复用的代码段。

由于编译器的优化，无法准确预估单纯的提炼一段代码对编译出的二进制代码体积有变大或是变小的影响，更难估计对运行期空间的影响和执行效率的影响。

我的体验是，如果想要提炼一段代码，先试一下，如果大大提高代码的可读性，又没有显著增加代码体积，可行；如果代码段已有“复用”，根据“事不过三，三则重构”的原则，可为，即便会增大代码体积，只要在可以接受的范围内；如果增加了代码体积，这个成本换取的可读性不合算，不为。

至于怎样才是显著增加代码体积，要根据不同工程的情况来判断了。

继续改进一些遗留问题。

3.2

原文：
Since the early days of programming people have realized that the longer a procedure is, the more difficult it is to understand.
Older languages carried an overhead in subroutine calls, which deterred people from small methods.
Modern OO languages have pretty much eliminated that overhead for in-process calls.

翻译：
很久以前程序员就已认识到：程序愈长愈难理解。
早期的编程语言中，“子程序调用动作”需要额外开销，这使得人们不太乐意使用small method。
现代OO语言几乎已经完全免除了进程内的“函数调用动作额外开销”。

现代OO语言里函数调用没有开销了么？

嵌入环境GUI模块，统一接口的一个实践。

如果你发现自己需要为程序添加一个特性，而代码结构使你无法很方便地那么做，那就先重构那个程序，使特性的添加比较容易，然后再添加特性。

重构的第一个步骤：为即将修改的代码建立一组可靠的测试环境。

每次修改的幅度小，任何错误都很容易发现。重构以微小的步伐修改程序，如果犯下错误，很容易便可发现。

重构的一个重要方向是消除重复代码。

重构应该随时随地进行。

事不过三，三则重构。