《重构 改善既有代码的设计》 读书笔记（八）

2.4 怎么对经理说

怎么向别人解释，重构不影响效率：客观来讲，重构会影响近期的开发效率，但是就长远看来，重构是一种高效的开发形态。

计算机科学是这样一门科学：它相信所有问题都可以通过增加一个间接层来解决。

通俗来讲，间接层的意义是，本来需要东奔西走去解决的一件事，现在只要派一个人就好。

间接层的价值：

1. 允许逻辑共享。比如函数可用于不同的地方；超类中的方法被所有子类共享。

2. 分开解释意图和实现。如果类和方法内部以很小单元的意图来编写，那么每一个方法都可以用很简洁的话来表述。

3. 隔离变化。如果只有一个类，那么我有可能会在两个不同地点使用这么一个类对象，此时，当我想要更改一个地点中这个类的行为时，就要冒同时影响两处的风险，为此可以做出一个子类，在修改处引用这子类，此时我们就将职能隔离开了。

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 重构与性能

虽然重构可能使软件运行更慢，但它也使软件的性能优化更容易。除了对性能有严格要求的实时系统，其他任何情况下“编写快速软件”的秘密就是：先写出可调的软件，然后去调整它，最后达到足够速度。

三种编写软件的方法

1. 时间预算法。通常用于性能要求极高的实时系统。如果使用这种方法，就意味着在设计过程中要做好预算，给每个组件预先分配一定资源——包括时间和执行轨迹。每个组件绝对不能超出自己的预算，就算拥有组件之间调度预配时间的机制也不行。

2. 持续关注法。这要求程序员在任何时间做任何事都应设法保持系统的高性能。但这很难，通常事与愿违，因为性能改善一旦被分散到程序各角落，每次改善都只不过是一次小小的坐井观天。

3. 综合统计法。采用这种方法时，需要编写构造良好的程序，不需要对性能投以特别的关注，直至进入性能优化阶段（往往是后期），一旦进入此阶段，再按照某个特定程序来调整程序性能。

第二种不建议，第一种和第三种视情况而定。

2.8 重构起源何处

略？

第三章 代码的坏味道

优秀的程序员，就像一名猎人，穿梭在茂密的丛林中，寻找着一闪而过的猎物。精准、高效、灵敏，这是生存的法则，我们，作为猎人，绝不能被困住，我们要解决它们。

没有任何量度规矩比得上一个见识广博者的直觉。我们只会告诉你一些迹象，它会指出“这里有一个可以用重构解决的问题”。你必须培养出自己的判断力，学会判断一个类内有多少实例变量算是太大、一个函数内有多少行代码才算太长。

3.1 重复代码（Duplicated Code）

重复代码的表现形式：

• 同一个类中两个方法含有相同的表达式。
• 两个互为兄弟的子类内含相同表达式