一、前言
重构(名词)：对软件内部结构的一种调整，目的是在不改变软件可观察行为的前提下，提高其可理解性，降低其修改成本。
重构(动词)：使用一系列重构手法，在不改变软件可观察行为的前提下，调整其结构。
根据重构的规模可以大致分为大型重构和小型重构：
大型重构： 对顶层代码设计的重构，包括：系统、模块、代码结构、类与类之间的关系等的重构，重构的手段有：分层、模块化、解耦、抽象可复用组件等等。这类重构的工具就是我们学习过的那些设计思想、原则和模式。这类重构涉及的代码改动会比较多，影响面会比较大，所以难度也较大，耗时会比较长，引入bug的风险也会相对比较大。
小型重构： 对代码细节的重构，主要是针对类、函数、变量等代码级别的重构，比如规范命名和注释、消除超大类或函数、提取重复代码等等。小型重构更多的是使用统一的编码规范。这类重构要修改的地方比较集中，比较简单，可操作性较强，耗时会比较短，引入bug的风险相对来说也会比较小。什么时候重构 新功能开发、修bug或者代码review中出现“代码坏味道”，我们就应该及时进行重构。持续在日常开发中进行小重构，能够降低重构和测试的成本。
二、代码的坏味道
2.1、代码重复
实现逻辑相同、执行流程相同
2.2、方法过长
方法中的语句不在同一个抽象层级逻辑难以理解，需要大量的注释面向过程编程而非面向对象
2.3、过大的类
类做了太多的事情包含过多的实例变量和方法类的命名不足以描述所做的事情
2.4、逻辑分散
发散式变化：某个类经常因为不同的原因在不同的方向上发生变化散弹式修改：发生某种变化时，需要在多个类中做修改
2.5、严重的情结依恋
某个类的方法过多的使用其他类的成员
2.6、数据泥团/基本类型偏执
两个类、方法签名中包含相同的字段或参数应该使用类但使用基本类型，比如表示数值与币种的Money类、起始值与结束值的Range类
2.7、不合理的继承体系
继承打破了封装性，子类依赖其父类中特定功能的实现细节子类必须跟着其父类的更新而演变，除非父类是专门为了扩展而设计，并且有很好的文档说明
2.8、过多的条件判断
2.9、过长的参数列
2.10、临时变量过多
2.11、令人迷惑的暂时字段
某个实例变量仅为某种特定情况而设置将实例变量与相应的方法提取到新的类中
2.12、纯数据类
仅包含字段和访问(读写)这些字段的方法此类被称为数据容器，应保持最小可变性
2.13、不恰当的命名
命名无法准确描述做的事情命名不符合约定俗称的惯例
2.14、过多的注释
坏代码的问题
难以复用：系统关联性过多，导致很难分离可重用部分难于变化一处变化导致其他很多部分的修改，不利于系统稳定难于理解命名杂乱，结构混乱，难于阅读和理解难以测试分支、依赖较多，难以覆盖全面
三、什么是好代码
代码质量的评价有很强的主观性，描述代码质量的词汇也有很多，比如可读性、可维护性、灵活、优雅、简洁。这些词汇是从不同的维度去评价代码质量的。其中，可维护性、可读性、可扩展性 又是提到最多的、最重要的三个评价标准。
要写出高质量代码，我们就需要掌握一些更加细化、更加能落地的编程方法论，这就包含面向对象设计思想、设计原则、设计模式、编码规范、重构技巧等。
SOLID原则
3.1、单一职责原则：
一个类只负责完成一个职责或者功能，不要存在多于一种导致类变更的原因。
单一职责原则通过避免设计大而全的类，避免将不相关的功能耦合在一起，来提高类的内聚性。同时，类职责单一，类依赖的和被依赖的其他类也会变少，减少了代码的耦合性，以此来实现代码的高内聚、松耦合。但是，如果拆分得过细，实际上会适得其反，反倒会降低内聚性，也会影响代码的可维护性。
3.2、开放-关闭原则：
添加一个新的功能，应该是通过在已有代码基础上扩展代码(新增模块、类、方法、属性等)，而非修改已有代码(修改模块、类、方法、属性等)的方式来完成。
开闭原则并不是说完全杜绝修改，而是以最小的修改代码的代价来完成新功能的开发。
很多设计原则、设计思想、设计模式，都是以提高代码的扩展性为最终目的的。特别是 23 种经典设计模式，大部分都是为了解决代码的扩展性问题而总结出来的，都是以开闭原则为指导原则的。最常用来提高代码扩展性的方法有：多态、依赖注入、基于接口而非实现编程，以及大部分的设计模式(比如，装饰、策略、模板、职责链、状态)。
3.3、里氏替换原则：
子类对象(object of subtype/derived class)能够替换程序(program)中父类对象(object of base/parent class)出现的任何地方，并且保证原来程序的逻辑行为(behavior)不变及正确性不被破坏。
子类可以扩展父类的功能，但不能改变父类原有的功能
父类中凡是已经实现好的方法(相对于抽象方法而言)，实际上是在设定一系列的规范和契约，虽然它不强制要求所有的子类必须遵从这些契约，但是如果子类对这些非抽象方法任意修改，就会对整个继承体系造成破坏。
3.4、接口隔离原则：
调用方不应该依赖它不需要的接口;一个类对另一个类的依赖应该建立在最小的接口上。接口隔离原则提供了一种判断接口的职责是否单一的标准：通过调用者如何使用接口来间接地判定。如果调用者只使用部分接口或接口的部分功能，那接口的设计就不够职责单一。
3.5、依赖反转原则：
高层模块不应该依赖低层模块，二者都应该依赖其抽象;抽象不应该依赖细节，细节应该依赖抽象。
3.6、迪米特法则：
一个对象应该对其他对象保持最少的了解
3.7、合成复用原则：
尽量使用合成/聚合的方式，而不是使用继承。
单一职责原则告诉我们实现类要职责单一;里氏替换原则告诉我们不要破坏继承体系;依赖倒置原则告诉我们要面向接口编程;接口隔离原则告诉我们在设计接口的时候要精简单一;迪米特法则告诉我们要降低耦合。而开闭原则是总纲，告诉我们要对扩展开放，对修改关闭。
四、设计模式
设计模式：软件开发人员在软件开发过程中面临的一般问题的解决方案。这些解决方案是众多软件开发人员经过相当长的一段时间的试验和错误总结出来的。每种模式都描述了一个在我们周围不断重复发生的问题，以及该问题的核心解决方案。
创建型：主要解决对象的创建问题，封装复杂的创建过程，解耦对象的创建代码和使用代码结构型：主要通过类或对象的不同组合，解耦不同功能的耦合行为型：主要解决的是类或对象之间的交互行为的耦合
五、命名小技巧
5.1、命名规范
一个好的命名应该要满足以下两个约束：
准确描述所做得事情格式符合通用的惯例
如果你觉得一个类或方法难以命名的时候，可能是其承载的功能太多了，需要进一步拆分。
约定俗称的惯例：
类命名
类名使用大驼峰命名形式，类命通常使用名词或名词短语。接口名除了用名词和名词短语以外，还可以使用形容词或形容词短语，如 Cloneable，Callable 等，表示实现该接口的类有某种功能或能力。
方法命名
方法命名采用小驼峰的形式，首字小写，往后的每个单词首字母都要大写。和类名不同的是，方法命名一般为动词或动词短语，与参数或参数名共同组成动宾短语，即动词 + 名词。一个好的函数名一般能通过名字直接获知该函数实现什么样的功能。
