Clean Code（整洁代码）
总结的口诀
- 大虫虫是魔鬼
-大类，大函数，大参数列表；重复代码，重复造轮子；魔鬼数字硬编码，常量应该统一定义，集中管理，便于理解和统一替换。 - 小虫抽风
- 一个小钦差
- 大重重是魔鬼
- 长虫发现数据链
-长类，长函数，长参数列表; 发散式变化，散弹式修改；switch惊悚现身，基本类型偏执；数据泥团，幼稚的数据类；过度耦合的消息链，依恋情节。 - 好莱坞的迪米特喜欢组合而不是继承
小技巧
-
将业务代码和非业务代码（操作日志，错误处理）分离
-
异常代替错误码
-
代码的组织逻辑，相关相似的代码放在一起，变量定义靠近第一次使用的地方
-
常量应该统一定义，集中管理; 避免魔鬼数字和硬编码。
-
拒绝重复代码， 使用优秀开源方法，不要重复造轮子
-
函数要短小优美，大函数提取函数，大类
-
尽可能使用枚举
-
针对接口编程，而不是实现编程。成员变量，参数，返回值，局部变量，尽量定义为接口。
-
定义类和方法时，优先使用泛型，通配符
-
容器类设置容量
-
优先返回空集合，空对象，而不是null。
-
懒加载，需要时再创建，对象的创建要紧挨着变量的使用，避免创建无用的对象
-
不要使用参数做临时变量
-
变量的参数不要太多，嵌套不要太深
-
数据库往返次数，使用批量操作代替循环操作
-
卫语句
设计原则
- SOLID
- 依赖倒置
客户拥有抽象接口，它的服务者从这些抽象接口中派生，底层模块实现了在高层模块声明并被高层模块调用的接口 - 好莱坞原则
- 你不要找我，我会找你 。 高层组件对待底层组件的方式：别调用我们，我们会调用你
- 应用场景：观察者模式,以通知替代轮询
- 工厂模式
Ioc依赖注入,DI控制反转设计的基础，所有组件都是被动的，初始化和调用都由容器负责
代码的坏味道
-
Duplicated Code(重复的代码)
将重复的代码提取成为函数，分别调用 -
Long Method(过长方法)
细化步骤，分解成小函数 -
Large Class(过大类)
细化类的职责，分解成职责单一的类 -
Long Parameter List(过长参数列)
将不属于一个对象但有细微联系的数据提成一个对象，然后将这些属于一个对象的数据以对象当参数 -
Divergent Change(发散式变化)
细化类的职责，分解成职责单一的类 -
Shotgun Surgery(霰弹式修改)
将发生变的函数和字段提取到一个类或者新类当中 -
Feature Envy(依恋情结)
拆分函数，将过多引用其它类的变量的函数移过去 -
Data Clumps(数据泥团)
将这些常一起出现的数据提取到一个类当中 -
Primitive Obsession(基本类型偏执)
将应该被放在一起的基本类型字段用对象代替 -
Switch Statements(switch惊悚现身)
利用面向对象的多态性和状态、策略等设计模式来处理
好的习惯
-
bean职责要单一
-
类名显示出类型，helper business bean
-
不可将主流程与辅助流程混合在一起
抽象与接口
-
从抽象类和接口语义来看：
抽象类表示的是一种A是B的关系
接口表示的是一种A有B的行为的关系 -
从实践的角度来看，使用抽象类或者接口，我们可以考虑几个问题：
优先使用接口，因为接口是一种完全的抽象且接口允许多实现
你抽象出来的核心模块中，有没有实例字段？
你抽象出来的核心模块中，需不需要普通方法？
你抽象出来的核心模块中，需不需要构造函数进行必要的传参？
设计模式
-
模板模式简单说就是代码设计人员定义好整个代码处理流程，将变化的地方抽象出来，交给子类去实现。有两个难点：
（1）主流程必须定义得足够宽松，保证子类有足够的空间去扩展
（2）主流程必须定义得足够严谨，保证抽离出来的部分都是关键的部分 -
代理模式
功能上讲：
被代理对象功能没有变化，还是那个功能；装饰器模式，被装饰对象的功能是增强了的
从语义的角度来说：
装饰器模式强调的是给对象增加功能
代理模式强调的是控制对象的访问
抽象、封装变化
- 找出易变化的部分，合理抽象。
- 用抽象构建框架、用实现扩展细节
- 面向接口编程的思想：
- 在java中，抽象指的是接口或者抽象类，细节就是具体的实现类，使用接口或者抽象类的目的是制定好规范和契约，而不去涉及任何具体的操作，把展现细节的任务交给他们的实现类去完成。
- 好处：可以降低类之间的耦合性，提高系统的稳定性，降低修改程序造成的风险。
- 实际编程中，最好做到如下3点：
低层模块尽量都要有抽象类或接口，或者两者都有。
变量的声明类型尽量是抽象类或接口。
使用继承时遵循里氏替换原则
如果依赖的是一个稳定的具体类，那么可以直接依赖它
- 编程的关键根本就不是编程语言，而在于背后的思想，能不能分层，抽象，分而治之，能不能把变化的部分和不变的部分给隔离开，能不能让各个功能独立地变化和扩展， 需认真学习，积极思考，多加实践
代码的可读性
-
代码的可读性，可维护性。可读的代码可维护性高。代码的模块化有助于提高代码的可维护性，高内聚低耦合的代码可维护性高
-
函数的作用:实现代码的复用;实现代码的模块化，提高可读性，可维护性;实现对代码的封装和抽象，隐藏实现细节，暴露业务接口
-
整个流程中的抽象是在同一个层次上的，比较清晰易于理解
-
架构的本质是管理复杂性，抽象、分层、分治和演化思维是工程师 / 架构师应对和管理复杂性的四种最基本武器。
重构代码
-
一个小钦差
-
一：单一职责，只做一件事儿，做好这件事儿；同一抽象层次；要么做什么，要么回答什么；只有一个导致变化的原因。
-
拆，将不同语义的功能拆分到不同的类中，单一职责。将变量，方法置于哪个类中，将变量方法拆分到哪个类中。语法，语义，意图，功能
常用设计模式
-
工厂模式，静态工厂，简单工厂，抽象工厂。
-
构建器模式
-
单例模式
-
策略模式
-
模板方法
-
观察者模式
-
特殊对象模式
-
中介者模式
-
生产者～消费者模式
反模式
-
上帝类，一个类集齐所有功能。
-
黄金大锤，只有一把锤子，看到什么都是钉子。
通用原则
-
不要重复自己，消除重复
-
封装，信息隐藏，过度封装会导致客户端调用的灵活性降低，需要平衡封装的程度。token是外部传入还是内部生成，sql语句是内部生成还是外部传入
-
使用函数，最好是小函数
-
相关的代码放在一起
-
日志最好集中打印
-
小虫抽风
面向接口编程
面向接口编程，『接口』在面向对象的设计中，是属于抽象层面的东西，那什么时候需要抽象呢？一定是两种及以上事物拥有共同的一些特征时，才能形成抽象（自底向上），或者从高层定义一些抽象特征，由两种或以上事物来体现这个特州，这种抽象才有意义（自顶向下）。
最佳实践
异常代替错误码
变量的定义靠近第一次使用的地方，流程要流畅
代码可读性，依靠的是代码语义、意图；不知道POJO的意义，以及语义化的涵义；只是感觉Map，String好灵活好喜欢。
尽管方法都短小简洁，但是代码的可读性依然不强，分析后发现是由于代码分层不清晰导致的。编码时，喜欢将需要的方法都写到一个类中，导致类混杂了很多功能，掺杂了不同的语义。应该通过抽象与分层将不同语义的功能，抽离到不同的类中。
消除重复
写好注释
语法与语义要保持一致，代码与功能要保持一致
类和方法的设计优先考虑泛型
契约式设计，防御式编程有利于编写安全可靠的代码，入参的合法性检验，与处理前的净化
站在客户的角度，审视自己的接口设计。自己设计的类对他人的影响，他人是否按照你的预想使用你的类。每个类既是服务的提供者，也是服务的享受者。
将相关的数据项绑定到一个类中，便于统一管理，如复制，创建，传参数，比较。rest，ftp，email
代码的位置，代码应该在哪个类中；代码的顺序，变量应该定义在靠近使用的地方，语句的顺序调整
将多个方法的变量设置为成员变量，避免方法间传来传去。
变量和类名的命名，命名要准确，多加限定词
精确的动词
-
简单的返回数据/内存中获取，getFullName
-
从远程获取/其他微服务，query