重构代码之代码的坏味道

1. 缺乏业务含义的命名

• 命名要能够描述出这段代码正在做的事
• 一个好名字应该描述意图，而非细节

2. 重复代码的提取

• 代码重复：提取方法，或者抽象
• 结构重复：类似静态代理，动态代理的处理方法，或者函数式编程提取函数
• 只要你看到 if 语句出现，而且 if 和 else 的代码块长得又比较像，多半就是出现了 这个坏味道

3. 不经意间写出的长函数

• 提取子函数
• 违反单一职责，抽取类

4. 大类的产生

• 职责不单一导致，根据业务分离关注点，拆分为多个职责单一的类
• 类中的字段未分组

5. 长参数列表

• 一个方法中的参数很长，可以将其封装成对象传递
• 动静分离，一个参数中可能会有动态的参数，也可能会有静态的参数，静态的参数需要抽离成关联关系
• 移除标记参数

6. 滥用控制语句

• if else if这些控制语句的产生往往意味着代码的坏味道。如果有多个if嵌套，可以用卫语句取代嵌套的条件表达式
• 不要使用else 语句。所有的else 语句可以用。如果只有一层else 可以先给条件语句赋值，然后再用if 语句。这样可以取消掉else.如果else嵌套过多，就可以用策略模式，多态的方法，抽离代码。

7. 长火车代码

string name = book.getAuthor().getName()

上面的代码很容易就被写出来。写出上述代码，必须对Book 类和 Author 类有充分的了解。那么这就破坏了封装的思想了。解决这种问题的方法是在Book类中提供一个方法，来隐藏委托关系

class Book{
    fun getAuthorName():String{
        return this.author.getName()
    }
}

8.变量的声明与赋值

来看一段代码:

BookStatus bookstatus = null;
CreateBookResponse response = createBook(request)
if(response.getCode()= 200){
    bookstatus = BookStatus.OK
}else{
    bookstatus = BookStatus.Error
}

上面的代码 bookstatus 经过了后面的业务逻辑后被赋值，这样会导致这个变量的值需要经过我们把业务完全搞懂后才能明白这个值是什么。

解决方法: 抽取方法赋值

CreateBookResponse response = createBook(request)
BookStatus bookstatus = getBookStatus()

fun getBookStatus(): BookStatus{
   .... response.getCode() 
}