项目在不断演进过程中，代码不停地在堆砌。如果没有人为代码的质量负责，代码总是会往越来越混乱的方向演进。当混乱到一定程度之后，量变引起质变，项目的维护成本已经高过重新开发一套新代码的成本，想要再去重构，已经没有人能做到了。

造成这样的原因往往有以下几点：

1. 编码之前缺乏有效的设计

2. 成本上的考虑，在原功能堆砌式编程

3. 缺乏有效代码质量监督机制

对于此类问题，业界已有有很好的解决思路：通过持续不断的重构将代码中的“坏味道”清除掉。

什么是重构

重构一书的作者Martin Fowler对重构的定义：

重构（名词）：对软件内部结构的一种调整，目的是在不改变软件可观察行为的前提下，提高其可理解性，降低其修改成本。
重构（动词）：使用一系列重构手法，在不改变软件可观察行为的前提下，调整其结构。

根据重构的规模可以大致分为大型重构和小型重构：

大型重构：对顶层代码设计的重构，包括：系统、模块、代码结构、类与类之间的关系等的重构，重构的手段有：分层、模块化、解耦、抽象可复用组件等等。这类重构的工具就是我们学习过的那些设计思想、原则和模式。这类重构涉及的代码改动会比较多，影响面会比较大，所以难度也较大，耗时会比较长，引入bug的风险也会相对比较大。

小型重构：对代码细节的重构，主要是针对类、函数、变量等代码级别的重构，比如规范命名和注释、消除超大类或函数、提取重复代码等等。小型重构更多的是使用统一的编码规范。这类重构要修改的地方比较集中，比较简单，可操作性较强，耗时会比较短，引入bug的风险相对来说也会比较小。什么时候重构 新功能开发、修bug或者代码review中出现“代码坏味道”，我们就应该及时进行重构。持续在日常开发中进行小重构，能够降低重构和测试的成本。

代码的坏味道

代码重复

• 实现逻辑相同、执行流程相同

方法过长

• 方法中的语句不在同一个抽象层级

• 逻辑难以理解，需要大量的注释

• 面向过程编程而非面向对象

过大的类

• 类做了太多的事情

• 包含过多的实例变量和方法

• 类的命名不足以描述所做的事情

逻辑分散

• 发散式变化：某个类经常因为不同的原因在不同的方向上发生变化

• 散弹式修改：发生某种变化时，需要在多个类中做修改

严重的情结依恋

• 某个类的方法过多的使用其他类的成员

数据泥团/基本类型偏执

• 两个类、方法签名中包含相同的字段或参数

• 应该使用类但使用基本类型，比如表示数值与币种的Money类、起始值与结束值的Range类

不合理的继承体系

• 继承打破了封装性，子类依赖其父类中特定功能的实现细节

• 子类必须跟着其父类的更新而演变，除非父类是专门为了扩展而设计，并且有很好的文档说明

过多的条件判断

过长的参数列

临时变量过多

令人迷惑的暂时字段

• 某个实例变量仅为某种特定情况而设置

• 将实例变量与相应的方法提取到新的类中

纯数据类

• 仅包含字段和访问（读写）这些字段的方法

• 此类被称为数据容器，应保持最小可变性

不恰当的命名

• 命名无法准确描述做的事情

• 命名不符合约定俗称的惯例

过多的注释

坏代码的问题

• 难以复用

• 系统关联性过多，导致很难分离可重用部分

• 难于变化

• 一处变化导致其他很多部分的修改，不利于系统稳定

• 难于理解

• 命名杂乱，结构混乱，难于阅读和理解

• 难以测试

• 分支、依赖较多，难以覆盖全面

什么是好代码

代码质量的评价有很强的主观性，描述代码质量的词汇也有很多，比如可读性、可维护性、灵活、优雅、简洁。这些词汇是从不同的维度去评价代码质量的。其中，可维护性、可读性、可扩展性又是提到最多的、最重要的三个评价标准。

要写出高质量代码，我们就需要掌握一些更加细化、更加能落地的编程方法论，这就包含面向对象设计思想、设计原则、设计模式、编码规范、重构技巧等。