代码重构 & 代码中的坏味道

时间:2020-12-16 04:39:07

1.重构

1.1 为什么要重构

1.1.1 改进程序设计

程序员为了快速完成任务,在没有完全理解整体架构之前就开始写代码,
导致程序逐渐失去自己的结构。重构则帮助重新组织代码,重新清晰的体现
程序结构和进一步改进设计。

1.1.2 提高程序可读性

容易理解的代码很容易维护和增加新功能。代码首先是写给人看的,
然后才是计算机看的。
  重构是一个Code Review 和反馈的过程。在另一个时段重新审视代码,
会容易发现问题和加深对代码的理解。

1.2 利用重构技术开发软件时会把时间分配给两种行为:

1.2.1 重 构

重构时你就不能再添加功能,只管改进程序结构。

1.2.2 添加新功能

添加新功能时,不应该修改既有代码,只管添加新功能。

1.3 何时重构

1.3.1 增加新功能时一重构

增加功能前需要理解修改的代码,如果发现代码不易理解且无法轻松增加功能,
此时就需要对代码进行重构。

1.3.2 修补错误时一重构

通过重构改善代码结构,能够帮助你找出BUG原因。

1.3.3 Review 代码时一重构

有经验的开发人员Review代码时能够提出一些代码重构的建议。

1.4 何时不该重构

1.4.1 代码实在太混乱,重构还不如重写

1.4.2 项目即将结束时避免重构


2.代码的坏味道

2.1 重复的代码(Duplicated Code)

重构方法:
2.1.1 重复代码在同一个类中的不同方法中,则直接提炼为一个方法。
2.1.2 如果重复代码在两个互为兄弟的子类中,则将重复的代码提到父类中。
2.1.3 如果代码类似,则将相同部分构成单独函数,或者用 Template Method 设计模式。

2.1.4 重复代码出现在不相干的类中,则将代码提
炼成函数或者放在独立的类中

2.2 过长的函数(Long Method)

是面向结构程序开发带来的 “后遗症”,过长的函数降低可读性。
重构方法:
  将独立的功能提炼成新函数。

2.3 过大类(Large Class)

过大的类使得责任不清晰。
重构方法:
  将过大的类的功能拆分成多个功能单一的小类。

2.4 过长的参数列表(Long Parameter List)

过长的参数列难以理解,而且容易传错参数。
重构方法:
  将参数列表用参数对象替换。

***2.5 发散式变化(Divergent Change)

一个类由于不同的原因而被修改
重构方法:
  将类拆分成多个,每个类只因为一种变化而修改。  
eg:一个包含有多个业务逻辑的代码,尽量拆分成多个功能相对独立的小类

***2.6 霰弹式修改(Shotgun Surgery)

与发散式变化相反,遇到变化时需要修改许多不同的类。
重构方法:
  将类似的功能放到一个类中

2.7 依恋情结(Feature Envy)

函数对某个类的兴趣高过对自己所处的类,通常是为了取其他类中的数据。(类中方法的界限)
重构方法:
  将相关的功能移动到它感兴趣的类中。

2.8 数据泥团(Data Clumps)

在多个地方看到相同的数据项。
eg:多个类中相同的变量,多个函数中相同的参数列表,并且这些数据总是一起出现。
重构方法:
  将这些数据项,独立到类中。

2.9 分支语句(Swtich Statements)

大量的分支,条件语句导致过长的函数,最后导致代码可读性差。
重构方法:
  将分支变成子类,或者使用State 和 Strategy模式。

2.10 过度耦合的消息链(Message Chains)

一个对象请求另一个对象,后者又请求另外的对象,然后继续。。。。,形成耦合的消息链。
重构方法:
  公布委托对象供调用。

2.11 过多的注释(Comments)

代码有着长长的注释,但注释之所以多是因为代码很糟糕
重构方法:
  写上必要的注释,尽量让代码不用注释就比较易读。

3.重构实战(TODO)

参考:
重构:改善既有代码的设计