重构改善既有的代码设计（重构原则）

重构：对软件内部结构的一种 调整，目的是再 不改变软件的可观察行为的前提下，提升其可理解性，下降其修改为本。

---

两顶帽子

添加新功能 添加新功能时不该该修改既有代码，只管添加新功能，经过测试
重构 重构时你就不能再添加功能，只管改进程序结构，此时你不该该添加任何测试，只在绝对必要（用以处理接口变化）时才修改测试

为什么重构

• 重构改进软件设计
• 重构使软件更容易理解¹
• 重构帮助找到bug
• 重构提升编程速度²

什么时候重构

• 三次法则：

  • 第一次作某件事时只管去作;第二次作相似的事会产生反感第三次再作相似的事，你就应该重构。（事不过三，三则重构）
• 添加功能时重构
• 修补错误时重构

重构的难题

• 数据库重构

• 修改接口

  • 让旧接口调用新接口，当你要修改某个函数的名称时请留下旧函数，让它调用新函数。千万不要复制函数实现，那会让你陷入重复代码的泥淖中难以自拔。你还应该使用java中depreciation注解，将旧接口标记为@deprecated。

• 难以经过重构手法完成设计的改动

  • 先想像重构的状况。考虑选设计方案时，我会问本身：将某个设计重构为另外一个设计的难度又多大？看上去很简单，我就没必要太担忧选择是否得当，因而我就会选择最简单的设计，哪怕他不能覆盖全部潜在的需求也不要紧，但若是预先看不到简单的重构办法，我就会在设计上投入更多的力气。
• 什么时候不应重构
  现有代码根本不能正常运做。重构以前，代码必须起码可以在大部分状况下正常运做 若是项目已近最后的期限，你也应该避免重构，若是项目已经很是接近最后期限，你不该该再分心于重构，由于已经没有时间了。重构可以提升生产力若是最后你没有足够时间，一般就表示你其实早该进行重构。

重构与设计

• 若是选择重构，问题的重点就改变了，你仍然作预先设计，可是没必要必定找出正确的解决方案，此刻的你只须要获得一个足够合理的解决方案就够了。
• 有了重构，你就能够经过一条不一样的途径来应付变化带来的风险。你仍旧须要思考潜在的变化，仍旧须要考虑灵活的解决方案。可是你没必要再主意实现这些解决方案而是应该问问本身："把一个简单的解决方案重构成这个灵活的方案又多大难度？"若是答案是“至关容易”，那么就只须要实现目前的简单方案就好了。

间接层和重构（间接层的价值）

• 容许逻辑共享

  • 好比说一个子函数再两个不一样的地点被调用，或超类中的某个函数被全部子类共享

• 分开解释意图和实现

  • 你能够选择每一个类和函数的名字，这给你一个解释本身意图的机会。类或函数内部则解释实现了这个意图的作法。若是类和函数内部又以更小单元的意图来编写，你所写的代码就能够描述其结构中的大部分重要信息

• 隔离变化

  • 极可能我在两个不一样的地点使用同一对象，其中一个地点我想改变对象行为，但若是修改了它，我就要冒同时影响两处的风险。为此我作出一个子类，并在须要修改出引用这个子类。如今，我能够修改这个子类而没必要承担午一中影响另外一处的风险。

• 封装条件逻辑

  • 对象有一种奇妙的消息机制：多态消息，能够灵活而清晰地表达条件逻辑。将条件逻辑转化为消息形式，每每能下降代码的重复，增长清晰度并提升弹性。

---

1. 什么是难以理解的程序：难以阅读的程序，难以修改；逻辑重复的程序，难以修改；添加新行为时须要修改已有的代码的程序难以修改带；复杂条件逻辑的程序，难以修改。 ↩
2. 咱们但愿程序：容易阅读；全部逻辑都旨在惟一地点指定；新的改动不会危机现有行为；尽量简单表达条件逻辑。 ↩