选择在何处重构

洪流学堂，让你快人几步。
本篇内容来自洪流读书会精选内容。

上次我们从重构带给我们什么、何时重构两个方面为大家进一步解读了重构的原则。今天我们看一看应该在何处重构？代码需要重构时会有什么迹象，或者说我们如何嗅出代码里的那些坏味道？

在此我总结了22种代码需要重构时的迹象，也可以说是22种坏味道。今天我们先来了解一下前6种吧！

选择在何处重构

神秘命名

第一种，当代码中出现神秘的命名时。

整洁代码最重要的一环就是好的名字，所以我们深思熟虑如何给函数、模块、变量和类命名，使它们能清晰地表明自己的功能和用法。很多人经常不愿意给程序元素改名，觉得不值得费这个劲，但好的名字能节省未来用在猜谜上的大把时间。

改名不仅仅是修改名字而已，如果你想不出一个好名字，说明背后很可能潜藏着更深的设计问题。为一个恼人的名字所付出的纠结，常常能推动我们对代码进行精简。

重复代码

第二种，当你发现重复代码时。

如果你在一个以上的地点看到相同的代码结构，那么可以肯定：**设法将它们合二为一，程序会变得更好。**注意在阅读到重复代码时，要留意其间细微的差异。如果要修改重复代码，你必须找出所有的副本来修改。

最单纯的重复代码就是“同一个类的两个函数含有相同表达式”。这时候需要做的就是采用提炼函数提炼出重复的代码，然后让这两个地点都调用被提炼出的那一段代码。

过长函数

第三种，当你看到一个来历不明的过长函数，又找不到注释时。

每当感觉需要以注释来说明点什么的时候，我们就把需要说明的东西写进一个独立函数里，并以其用途（而非实现手法）命名。我们可以对一组甚至短短一行代码做这件事，哪怕替换后的函数调用动作比函数自身动作还长，只要函数名称能解释其用途，我们也该毫不犹豫地那么做。关键不在于函数的长度，而在于函数“做什么”和“如何做”之间的语义距离。

百分之九十九的场合里，要把函数变短，只需使用提炼函数。找到函数中适合集中在一起的部分，将它们提炼出来形成一个新函数。

全局数据

第四种，当你遇见一些全局数据时。

全局函数的问题在于，从代码库的任何一个角落都可以修改它，而且没有任何机制可以探测出到底哪段代码做出了修改。一次又一次，全局数据造成了那些诡异的bug，而问题的根源却在遥远的别处，想要找到出错的代码难于登天。全局数据最显而易见的形式就是全局变量，但类变量和单例也有这样的问题。

我们采用的防御手段是封装变量，先把全局数据用一个函数包装起来并开始控制对它的访问，随后将这个函数搬移到一个类或模块中，只允许模块内的代码使用它，从而尽量控制其作用域。

可变数据

第五种，当遇到可变数据时。

如果变量作用域只有几行代码，即使其中的数据可变，也不是什么大问题；但随着变量作用域的扩展，风险也随之增大。可以使用函数组合成类或者函数组合成变换来限制需要对变量进行修改的代码量。如果一个变量在其内部结构中包含了数据，通常最好不要直接修改其中的数据，而是用将引用对象改为值对象的方法令其直接替换整个数据结构。

发散式变化

第六种，遇到发散式变化时。

如果某个模块经常因为不同的原因在不同的方向上发生变化，发散式变化就出现了。当你看着一个类说：“呃，如果新加入一个数据库，我必须修改这3个函数；如果新出现一种金融工具，我必须修改4个函数。”这就是发散式变化的征兆。

数据库交互和金融逻辑处理是两个不同的上下文，将它们分别搬移到各自独立的模块中，能让程序变得更好：每当要对上下文做修改时，我们只需要理解这个上下文，而不必操心另一个。“每次只关心一个上下文”这一点一直很重要，在如今这个信息爆炸、脑容量不够用的年代就愈发紧要。当然，往往只有在加入新数据库或者新金融工具后，你才能发现这个问题。在程序刚开发出来还在随着软件系统的能力不断演进时，上下文边界通常不是那么清晰。

如果发生变化的两个方向自然地形成了先后次序（比如说，先从数据库取出数据，再对其进行金融逻辑处理），就可以用拆分阶段将两者分开，两者之间通过一个清晰的数据结构进行沟通。如果两个方向之间有更多的来回调用，就应该先创建适当的模块，然后运用搬移函数把处理逻辑分开。如果函数内部混合了两类处理逻辑，应该先用提炼函数将其分开，然后再做搬移。如果模块是以类的形式定义的，就可以用提炼类来做拆分。

小结

今天我们了解了6种代码需要重构时的迹象，即我们需要在这些迹象出现的地方进行重构。下次我将带大家了解剩下的16种！

扩展阅读

• 为什么要重构
• 重构的原则
• 重构的原则（下）
• 选择在何处重构（下）

【扩展学习】在洪流学堂公众号回复读书会可以阅读本系列所有文章

---

我是大智（vx：zhz11235），你的技术探路者，下次见！

别走！点赞，收藏哦！

好，你可以走了。