代码之丑
1- 命名
坏味道：
- 命名过于宽泛，不能精确描述；一个好的名字应该描述意图，而非细节；
- 有技术术语命名：
- 违反英文语法规则的命名；
- 不准确的英语词汇；
- 英语单词拼写错误；
总结： 用业务语言写代码
2- 重复代码
3- 长函数
CheckStyle配置函数方法的长度是20行
<module name="MethodLength">
<property name="tokens" value="METHON_DEF" />
<property name="max" value="20" />
<property name="countEmpty" value="false" />
</module>
4- 大类
大类产生的原因：
- 职责不单一
- 字段不分组
5- 长参数的列表
方法：
- 把参数列表封装成对象
- 动静分离
变化频率相同，封装成一个类； 变化不同的话： 1- 静态不变的，可以成为软件结构的一部分； 2- 多个变化频率的，可以封装成几个类；
6- 滥用控制语句：if else for switch
7- 缺乏封装
优点：可以封装散落的代码，这点我到非常赞同作者的观点，有时候进行重构代码的时候，存在这种已经封装好的方法，确实比较容易进行重构，而不是去找散落在项目中的各种代码；
例如：mybatisPlus确实给我们的使用提供的灵活性，但大量的Wrappers散落，如果进行重构，确实会造成大量的人力浪费；
作者的观点就是setter和getter方法会破坏封装，建议用方法代替，不要把成员变量暴露出去； 以对象取代基本类型，意思就是用及时使用get，也要copy一个新的对象，而不使用原始的对象；
8- 变量声明与赋值分离
宗旨：变量尽量一次性赋值，尽量是用final，不要用null进行过度。
- 提到了一个观点，变量一次性初始化，而不要多次，例如以下代码就是有臭味的
demo1:
final String status = null; if (条件) { status = "STATUS.A"; } else { status = "STATUS.B"; }
解决办法，把状态赋值抽象成一个方法
demo2:
Client client = null;
try {
client = new Client;
} catch(){
} finally {
if (client!=null) {
client.close();
}
}
解决办法： try语法糖
- 在能够使用final的地方尽量使用final
9- 依赖混乱
- 缺少防腐层
例子：
springboot一般由 Controller层 和 Service层；
此时，写了一个接口，请求参数为Request，我们习惯会把Request直接拿到Service层去使用；
作者的观点是，Request应该属于Controller，不应该拿到Service层去使用；
解决办法，把Request中的值copy到另外一个对象，然后放到Service层去使用。
个人感觉，作者太矫枉过正了，为了优化而优化。
我感觉，代码中 A---B----A这样的循环依赖才是重中之重，而作者却一点也没有介绍。
10- 不一致
- 命名不一致；
- 方案不一致；
- 代码不一致；
11- 落后的代码
宗旨：使用新的代码特性来代替之前的代码逻辑，例如用Optional类进行null空指针等校验。
12- 新需求破坏了代码，怎么办？
- 接口，我们对外提供得越少越好；
- 改动实体要谨慎；
课程总结：个人感觉这个专栏的没有达到个人的预期，不会再看第二遍。可以去看《重构》这本书代替。
