2.4 怎么对经理说
怎么向别人解释，重构不影响效率
：客观来讲，重构会影响近期的开发效率，但是就长远看来，重构是一种高效的开发形态。
计算机科学是这样一门科学：它相信所有问题都可以通过增加一个间接层来解决。
通俗来讲，间接层的意义是，本来需要东奔西走去解决的一件事，现在只要派一个人就好。
间接层的价值
：
-
允许逻辑共享
。比如函数可用于不同的地方；超类中的方法被所有子类共享。 -
分开解释意图和实现
。如果类和方法内部以很小单元的意图来编写，那么每一个方法都可以用很简洁的话来表述。 -
隔离变化
。如果只有一个类，那么我有可能会在两个不同地点使用这么一个类对象，此时，当我想要更改一个地点中这个类的行为时，就要冒同时影响两处的风险，为此可以做出一个子类，在修改处引用这子类，此时我们就将职能隔离开了。 -
封装条件逻辑
。多态，可以灵活而清晰地表达条件逻辑。将类似于switch语句转化成多个类的形式，往往能降低代码的重复，增加清晰度和弹性。
2.5 重构的难题
数据库重构难题
：绝大多数商用程序都与它们背后的数据库结构紧密耦合，这是数据库结构难以修改的原因之一。另一个原因是数据迁移——数据库结构的改变会让你不得不迁移所有数据。
解决这个问题的办法之一是，在对象模型和数据库模型之间插入一个分隔层，这就可以隔离两个模型各自的变化。这样的分隔层会增加系统复杂度，但可以带给你很大的灵活度。
修改接口难题
：许多重构手法会修改接口，当要修改的接口被那些‘找不到，即便找到也不能修改’的代码使用时，接口的修改会成为问题。（此时就该考虑
引入外加函数
（7.7 Introduce Foreign Method）和
引入本地扩展
（7.8 Introduce Local Extension））
引入外加函数
（7.7 Introduce Foreign Method）：在本地自定义一个方法，接收参数后，方法内先进行处理，然后方法内调用那些不能修改的接口，这就使得——从外部看修改了结构，但实际功能并未改变。
引入本地扩展
（7.8 Introduce Local Extension）：建立一个新类，使它包含那个接口的函数。
引入外加函数适合于只修改几个方法的情况，而引入本地扩展则是修改一大堆方法的情况才会使用。
什么时候不该重构？
当现有代码不能稳定运作时，应该重新编写。
当项目临近最后期限，也应避免重构。（磨刀不误砍柴工，但也得分时候）
2.6 重构与设计
永远不要过度设计，不要过于追求代码的灵活性。（灵活性意味着有些东西现在用不着，也许以后也用不着）
设计初期要做的，只是提出一套可行方案，至于之后的改进，则交给重构去做。
2.7 重构与性能
虽然重构可能使软件运行更慢，但它也使软件的性能优化更容易。除了对性能有严格要求的实时系统，其他任何情况下“编写快速软件”的秘密就是：
先写出可调的软件，然后去调整它，最后达到足够速度。
三种编写软件的方法
-
时间预算法
。通常用于性能要求极高的实时系统。如果使用这种方法，就意味着在设计过程中要做好预算，给每个组件预先分配一定资源——包括时间和执行轨迹。每个组件绝对不能超出自己的预算，就算拥有组件之间调度预配时间的机制也不行。 -
持续关注法
。这要求程序员在任何时间做任何事都应设法保持系统的高性能。但这很难，通常事与愿违，因为性能改善一旦被分散到程序各角落，每次改善都只不过是一次小小的坐井观天。 -
综合统计法
。采用这种方法时，需要编写构造良好的程序，不需要对性能投以特别的关注，直至进入性能优化阶段（往往是后期），一旦进入此阶段，再按照某个特定程序来调整程序性能。
第二种不建议，第一种和第三种视情况而定。
2.8 重构起源何处
略？
第三章 代码的坏味道
优秀的程序员，就像一名猎人，穿梭在茂密的丛林中，寻找着一闪而过的猎物。精准、高效、灵敏，这是生存的法则，我们，作为猎人，绝不能被困住，我们要解决它们。
没有任何量度规矩比得上一个见识广博者的直觉。我们只会告诉你一些迹象，它会指出“这里有一个可以用重构解决的问题”。你必须培养出自己的判断力，学会判断一个类内有多少实例变量算是太大、一个函数内有多少行代码才算太长。
3.1 重复代码（Duplicated Code）
重复代码的表现形式
：
- 同一个类中两个方法含有相同的表达式。
- 两个互为兄弟的子类内含相同表达式