为什么要重构？如何重构？这个宝典请一定收藏！ _重构

来源：/post/
关于重构为什么要重构
1_代码重构漫画.jpeg
项目在不断演进过程中，代码不停地在堆砌。如果没有人为代码的质量负责，代码总是会往越来越混乱的方向演进。当混乱到一定程度之后，量变引起质变，项目的维护成本已经高过重新开发一套新代码的成本，想要再去重构，已经没有人能做到了。
造成这样的原因往往有以下几点：
编码之前缺乏有效的设计
成本上的考虑，在原功能堆砌式编程
缺乏有效代码质量监督机制
对于此类问题，业界已有有很好的解决思路：通过持续不断的重构将代码中的“坏味道”清除掉。
什么是重构
重构一书的作者对重构的定义：
重构（名词）：对软件内部结构的一种调整，目的是在不改变软件可观察行为的前提下，提高其可理解性，降低其修改成本。重构（动词）：使用一系列重构手法，在不改变软件可观察行为的前提下，调整其结构。
根据重构的规模可以大致分为大型重构和小型重构：
大型重构：对顶层代码设计的重构，包括：系统、模块、代码结构、类与类之间的关系等的重构，重构的手段有：分层、模块化、解耦、抽象可复用组件等等。这类重构的工具就是我们学习过的那些设计思想、原则和模式。这类重构涉及的代码改动会比较多，影响面会比较大，所以难度也较大，耗时会比较长，引入bug的风险也会相对比较大。
小型重构：对代码细节的重构，主要是针对类、函数、变量等代码级别的重构，比如规范命名和注释、消除超大类或函数、提取重复代码等等。小型重构更多的是使用统一的编码规范。这类重构要修改的地方比较集中，比较简单，可操作性较强，耗时会比较短，引入bug的风险相对来说也会比较小。什么时候重构新功能开发、修bug或者代码中出现“代码坏味道” ，我们就应该及时进行重构。持续在日常开发中进行小重构，能够降低重构和测试的成本。
代码的坏味道
2_代码常见问题.png
方法过长
过大的类
逻辑分散
严重的情结依恋
数据泥团/基本类型偏执
不合理的继承体系
过多的条件判断
过长的参数列
临时变量过多
令人迷惑的暂时字段
纯数据类
不恰当的命名
过多的注释
坏代码的问题
难于变化
难于理解
难以测试
什么是好代码
3_代码质量如何衡量.jpg
代码质量的评价有很强的主观性，描述代码质量的词汇也有很多，比如可读性、可维护性、灵活、优雅、简洁。这些词汇是从不同的维度去评价代码质量的。其中，可维护性、可读性、可扩展性又是提到最多的、最重要的三个评价标准。
要写出高质量代码，我们就需要掌握一些更加细化、更加能落地的编程方法论，这就包含面向对象设计思想、设计原则、设计模式、编码规范、重构技巧等。
如何重构 SOLID原则
原则.png单一职责原则
一个类只负责完成一个职责或者功能，不要存在多于一种导致类变更的原因。
单一职责原则通过避免设计大而全的类，避免将不相关的功能耦合在一起，来提高类的内聚性。同时，类职责单一，类依赖的和被依赖的其他类也会变少，减少了代码的耦合性，以此来实现代码的高内聚、松耦合。但是，如果拆分得过细，实际上会适得其反，反倒会降低内聚性，也会影响代码的可维护性。