代码之丑

1- 命名

坏味道：

• 命名过于宽泛，不能精确描述；一个好的名字应该描述意图，而非细节；
• 有技术术语命名：
• 违反英文语法规则的命名；
• 不准确的英语词汇；
• 英语单词拼写错误；

总结： 用业务语言写代码

 

2- 重复代码

 

3-  长函数

?

1 2 3 4 5 6 7

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 3 4 5

  变化频率相同，封装成一个类；   变化不同的话： 1- 静态不变的，可以成为软件结构的一部分； 2- 多个变化频率的，可以封装成几个类；

6- 滥用控制语句：if else for switch

7- 缺乏封装

优点：可以封装散落的代码，这点我到非常赞同作者的观点，有时候进行重构代码的时候，存在这种已经封装好的方法，确实比较容易进行重构，而不是去找散落在项目中的各种代码；

例如：mybatisPlus确实给我们的使用提供的灵活性，但大量的Wrappers散落，如果进行重构，确实会造成大量的人力浪费；

?

1 2 3

作者的观点就是setter和getter方法会破坏封装，建议用方法代替，不要把成员变量暴露出去；   以对象取代基本类型，意思就是用及时使用get，也要copy一个新的对象，而不使用原始的对象；

　　

8- 变量声明与赋值分离

     宗旨：变量尽量一次性赋值，尽量是用final，不要用null进行过度。

• 提到了一个观点，变量一次性初始化，而不要多次，例如以下代码就是有臭味的

?

1 2 3 4 5 6

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- 依赖混乱

• 缺少防腐层
  ?

  1	例子：<br>springboot一般由 Controller层  和  Service层；<br>此时，写了一个接口，请求参数为Request，我们习惯会把Request直接拿到Service层去使用；<br>作者的观点是，Request应该属于Controller，不应该拿到Service层去使用；<br><br>解决办法，把Request中的值copy到另外一个对象，然后放到Service层去使用。

 个人感觉，作者太矫枉过正了，为了优化而优化。

我感觉，代码中 A---B----A这样的循环依赖才是重中之重，而作者却一点也没有介绍。

 

10- 不一致

• 命名不一致；
• 方案不一致；
• 代码不一致；

11- 落后的代码

宗旨：使用新的代码特性来代替之前的代码逻辑，例如用Optional类进行null空指针等校验。

 

12- 新需求破坏了代码，怎么办？

• 接口，我们对外提供得越少越好；
• 改动实体要谨慎；

 

课程总结：个人感觉这个专栏的没有达到个人的预期，不会再看第二遍。可以去看《重构》这本书代替。