什么时候需要被重构

peter

2024 年 07 月 01 日

15 次浏览

暂无评论

1367字数

重构

> 坏味道是一切重构的起点，而识别坏味道不是靠个人审美，而要依赖通用的标准。

# 一、什么代码应该被重构？

## 1、违反高内聚，低耦合

当我们仔细阅读《重构》第三章时，我们会发现，**“低内聚”会直接引发的现象是“霰弹式修改（Shotgun Surgery）”**：

A、每当需要对某个事情做出修改时，你都必须在许多不同的类内做出许多小修改，那么就可以确定，你所面临的坏味道是霰弹式修改。当需要修改的代码分散在多处，你不但很难找到它们，也很容易忘记某个重要的修改。

**解决办法**：

* 对于“霰弹式修改”，解决的办法是使用“搬移函数”和“搬移字段”，把所有需要修改的代码放进同一个模块；

B、如果某个类经常因为不同的原因在不同的方向上发生变化，发散式变化就出现了。

**解决办法**：

* 对于“发散式变化”，解决的办法是首先用“提炼函数”将不同用途的逻辑分开，然后用“搬移函数”将它们分别搬移到合适的模块；

## 2、违反“迪米特原则”

“过长的消息链（Message Chains）”

如果你看到用户向一个对象请求另一个对象，而后者再次请求另一个对象，然后再请求另一个对象……这就是消息链。在实际代码中，你看到的可能是一长串取值函数，或者一长串临时变量。

**解决办法**：

* 对于“过长的消息链”，你应该使用“隐藏委托关系”；

“中间人（Middle Man）”

人们可能过度运用委托。你也许会看到某个类接口有一半的函数都委托给其他类，这样就是过度运用。

**解决办法**：

* 对于“中间人”，对症的疗法则是“移除中间人”，甚至直接“内联函数”。

`实际上，《重构》给出的 24 项“坏味道”（在《重构》第一版中是 22 项）已经形成了一个非常明确的代码质量检查清单`。

## 3、阅读和使用《重构》这本书的正确方法

![Untitled](https://s3-us-west-2.amazonaws.com/secure.notion-static.com/a65cbb69-8a5a-4b94-866e-2ca369144845/Untitled.png)

1、打开任意一段代码（可以是自己刚写完的或者马上要动手修改的）；

2、翻开《重构》第三章，遍历其中的每个坏味道：

```
 识别这段代码中是否存在上述坏味道；
```

如有，则遵循该坏味道所列的重构手法，对该段代码进行重构；

如无，则继续遍历代码。

上述过程不需要玄妙的理论和含混的代码美学，只需要机械的重复和简单的模式匹配。正因为此，重构才是一项完完全全具备可操作性、能够在任何遗留代码库上实践的技术。

# 二、培养对“坏味道”的判断力

* 每位实践者仍然“必须培养出自己的判断力，学会判断一个类内有多少实例变量算是太大、一个函数内有多少行代码才算太长”。
* 刻意练习。正所谓“台上一分钟，台下十年功”，缺乏在受控环境下的刻意练习，很难通过工作中的自然积累提升判断力。
* 从一开始就以合理的方式编程，从而使坏味道不要出现，我想这才是负责任的程序员应该采取的工作方式。

最后修改：2025 年 07 月 01 日

如果觉得我的文章对你有用，请随意赞赏

什么时候需要被重构

peter • 2024 年 07 月 01 日

发表评论 取消回复 使用cookie技术保留您的个人信息以便您下次快速评论，继续评论表示您已同意该条款

什么时候需要被重构

发表评论取消回复
使用cookie技术保留您的个人信息以便您下次快速评论，继续评论表示您已同意该条款