加个“星标”，每天上午09:25，干货推送！
来源：juejin.cn/post/
关于重构为什么要重构什么是重构代码的坏味道坏代码的问题什么是好代码如何重构SOLID原则设计模式代码分层命名规范重构技巧质量如何保证测试驱动开发TDD的开发周期两个基本的原则分层测试点关于重构为什么要重构
项目在不断演进过程中，代码不停地在堆砌。如果没有人为代码的质量负责，代码总是会往越来越混乱的方向演进。当混乱到一定程度之后，量变引起质变，项目的维护成本已经高过重新开发一套新代码的成本，想要再去重构，已经没有人能做到了。
造成这样的原因往往有以下几点：
编码之前缺乏有效的设计成本上的考虑，在原功能堆砌式编程缺乏有效代码质量监督机制对于此类问题，业界已有有很好的解决思路：通过持续不断的重构将代码中的“坏味道”清除掉。
什么是重构重构一书的作者MartinFowler对重构的定义：
重构（名词）：对软件内部结构的一种调整，目的是在不改变软件可观察行为的前提下，提高其可理解性，降低其修改成本。重构（动词）：使用一系列重构手法，在不改变软件可观察行为的前提下，调整其结构。
根据重构的规模可以大致分为大型重构和小型重构：
大型重构：对顶层代码设计的重构，包括：系统、模块、代码结构、类与类之间的关系等的重构，重构的手段有：分层、模块化、解耦、抽象可复用组件等等。这类重构的工具就是我们学习过的那些设计思想、原则和模式。这类重构涉及的代码改动会比较多，影响面会比较大，所以难度也较大，耗时会比较长，引入bug的风险也会相对比较大。
小型重构：对代码细节的重构，主要是针对类、函数、变量等代码级别的重构，比如规范命名和注释、消除超大类或函数、提取重复代码等等。小型重构更多的是使用统一的编码规范。这类重构要修改的地方比较集中，比较简单，可操作性较强，耗时会比较短，引入bug的风险相对来说也会比较小。什么时候重构新功能开发、修bug或者代码review中出现“代码坏味道”，我们就应该及时进行重构。持续在日常开发中进行小重构，能够降低重构和测试的成本。
代码的坏味道代码重复
实现逻辑相同、执行流程相同方法过长
方法中的语句不在同一个抽象层级逻辑难以理解，需要大量的注释面向过程编程而非面向对象过大的类
类做了太多的事情包含过多的实例变量和方法类的命名不足以描述所做的事情逻辑分散
发散式变化：某个类经常因为不同的原因在不同的方向上发生变化散弹式修改：发生某种变化时，需要在多个类中做修改严重的情结依恋
某个类的方法过多的使用其他类的成员数据泥团/基本类型偏执
两个类、方法签名中包含相同的字段或参数应该使用类但使用基本类型，比如表示数值与币种的Money类、起始值与结束值的Range类不合理的继承体系
继承打破了封装性，子类依赖其父类中特定功能的实现细节子类必须跟着其父类的更新而演变，除非父类是专门为了扩展而设计，并且有很好的文档说明过多的条件判断
过长的参数列
临时变量过多
令人迷惑的暂时字段
某个实例变量仅为某种特定情况而设置将实例变量与相应的方法提取到新的类中纯数据类
仅包含字段和访问（读写）这些字段的方法此类被称为数据容器，应保持最小可变性不恰当的命名
命名无法准确描述做的事情命名不符合约定俗称的惯例过多的注释
坏代码的问题难以复用系统关联性过多，导致很难分离可重用部分难于变化一处变化导致其他很多部分的修改，不利于系统稳定难于理解命名杂乱，结构混乱，难于阅读和理解难以测试分支、依赖较多，难以覆盖全面什么是好代码代码质量的评价有很强的主观性，描述代码质量的词汇也有很多，比如可读性、可维护性、灵活、优雅、简洁。这些词汇是从不同的维度去评价代码质量的。其中，可维护性、可读性、可扩展性又是提到最多的、最重要的三个评价标准。
要写出高质量代码，我们就需要掌握一些更加细化、更加能落地的编程方法论，这就包含面向对象设计思想、设计原则、设计模式、编码规范、重构技巧等。
如何重构SOLID原则4_SOLID原则.png
单一职责原则一个类只负责完成一个职责或者功能，不要存在多于一种导致类变更的原因。
单一职责原则通过避免设计大而全的类，避免将不相关的功能耦合在一起，来提高类的内聚性。同时，类职责单一，类依赖的和被依赖的其他类也会变少，减少了代码的耦合性，以此来实现代码的高内聚、松耦合。但是，如果拆分得过细，实际上会适得其反，反倒会降低内聚性，也会影响代码的可维护性。
开放-关闭原则添加一个新的功能，应该是通过在已有代码基础上扩展代码（新增模块、类、方法、属性等），而非修改已有代码（修改模块、类、方法、属性等）的方式来完成。
开闭原则并不是说完全杜绝修改，而是以最小的修改代码的代价来完成新功能的开发。
很多设计原则、设计思想、设计模式，都是以提高代码的扩展性为最终目的的。特别是23种经典设计模式，大部分都是为了解决代码的扩展性问题而总结出来的，都是以开闭原则为指导原则的。最常用来提高代码扩展性的方法有：多态、依赖注入、基于接口而非实现编程，以及大部分的设计模式（比如，装饰、策略、模板、职责链、状态）。
里氏替换原则子类对象（objectofsubtype/derivedclass）能够替换程序（program）中父类对象（objectofbase/parentclass）出现的任何地方，并且保证原来程序的逻辑行为（behavior）不变及正确性不被破坏。
子类可以扩展父类的功能，但不能改变父类原有的功能
父类中凡是已经实现好的方法（相对于抽象方法而言），实际上是在设定一系列的规范和契约，虽然它不强制要求所有的子类必须遵从这些契约，但是如果子类对这些非抽象方法任意修改，就会对整个继承体系造成破坏。
接口隔离原则调用方不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。接口隔离原则提供了一种判断接口的职责是否单一的标准：通过调用者如何使用接口来间接地判定。如果调用者只使用部分接口或接口的部分功能，那接口的设计就不够职责单一。
依赖反转原则高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节，细节应该依赖抽象。
迪米特法则一个对象应该对其他对象保持最少的了解
合成复用原则尽量使用合成/聚合的方式，而不是使用继承。
单一职责原则告诉我们实现类要职责单一；里氏替换原则告诉我们不要破坏继承体系；依赖倒置原则告诉我们要面向接口编程；接口隔离原则告诉我们在设计接口的时候要精简单一；迪米特法则告诉我们要降低耦合。而开闭原则是总纲，告诉我们要对扩展开放，对修改关闭。
设计模式设计模式：软件开发人员在软件开发过程中面临的一般问题的解决方案。这些解决方案是众多软件开发人员经过相当长的一段时间的试验和错误总结出来的。每种模式都描述了一个在我们周围不断重复发生的问题，以及该问题的核心解决方案。
创建型：主要解决对象的创建问题，封装复杂的创建过程，解耦对象的创建代码和使用代码结构型：主要通过类或对象的不同组合，解耦不同功能的耦合行为型：主要解决的是类或对象之间的交互行为的耦合代码分层模块结构说明
server_main：配置层，负责整个项目的module管理，maven配置管理、资源管理等；server_application：应用接入层，承接外部流量入口，例如：RPC接口实现、消息处理、定时任务等；不要在此包含业务逻辑；server_biz：核心业务层，用例服务、领域实体、领域事件等server_irepository：资源接口层，负责资源接口的暴露server_repository：资源层，负责资源的proxy访问，统一外部资源访问，隔离变化。注意：这里强调的是弱业务性，强数据性；server_