了解重构

了解重构

什么是重构？

“重构”一词想必大家耳熟能详，就是整理代码呗，可事实上并不是这样的。重构旨在不改变调用者行为的前提下，对内部逻辑进行调整优化，从而提高其理解性，降低其修改成本。

何时重构？

重构并不是单独抽出时间集中处理的，而是当你想要做某个功能时，应该随手把需要重构的地方重构了。

怎么重构？

抽象重复逻辑

重复代码是最核心常见的预警信息，如果有两个或两个以上的重复逻辑的代码，就应该考虑将其合并。例如，同一类或不同类中的方法如果存在逻辑相同的部分，就应该把相同部分抽象为独立的方法或类。

分解长方法

当很多人阅读别人数百行甚至上千行的代码后，让人怀疑人生。为方便理解，最好的方式是把长方法分解为若干小方法，搭配上易理解的方法名，便可以像自然语言一样理解代码。

减少参数

有一种习惯非常不好，就是把所有要用到的变量当做方法的参数，这样会加剧代码的理解难度，对内容的拓展极其困难，当需要更多数据时，不得不修改所有方法的参数，牵一发动全身。如果把对象作为参数，把需要用到的数据都放进对象里，就可以有效解决参数过长的问题。

方法出轨

你要是发现一个方法频繁的调用某一个类，它很可能给你戴了绿帽子，不如忍痛割爱，放其自由吧，把方法归并到它喜欢的类，也许他们在一起生活更为合适，你一定会找到一个适合的人。

抽取变化

如果新加入一个业务类型（例如支付渠道、数据库类型等）时，需要改动很多地方才能实现，这就意味着还有改进的空间，可以将引起变化的原因抽出来做为配置，并将变化的方法放置到一个类中，这样不仅可以做到修改一处就应对变化，还可以很清晰的知道方法会受到影响。

组合工具类

一款语言包含很多基本类型与内置方法，但不能满足所有需求，比如金额单位转换、时间数组格式转换、UUID生成等简单又容易忽略的小功能，如果这些功能出现的频率很高，规则改变会带来一连串的修改，这时可以考虑将这些小功能抽象为工具方法，并将这些方法组合为工具类。

意淫的功能

有些逻辑以为将来会有一些变化，于是安插了很多钩子方法应对非必要的特殊情况，这样往往提高了系统复杂性和理解成本，如果安插的钩子都能被用到且有价值，那么就使用，否则还是不要放在代码里阻碍视线了。

减少switch

假如现在要做一个支持微信、支付宝、招行等渠道的支付平台，需要对接不同渠道，因为不同渠道对接方式不同，就需要用switch来根据类型选择对应渠道的对接方式，但是很多地方都可能用到这个switch，一旦新渠道加入就要满世界的找哪里用到了switch。

可以将switch语句移植为独立的方法，将这些方法组成基类，case语句调用子类对应的方法，具体实现让子类去完成，这样支付渠道的增加和变更只需要修改一个类即可。

去掉无用类

创建的每一个类，对于其他人来讲都是有理解成本的，如果曾经为某个变化所添加的类，在实际场景中并没有发生变化，那么就把这个类去掉吧，我们需要真正有价值、理解成本低的系统。

一个类会设置一些为特殊情况设置的变量，这些变量不一定都会被使用，经手你代码的人还要猜测当时设置这些变量的目的，非常让人头大，不如把这些变量和相关方法单独放在一个类中，屏蔽具体细节，需要的功能通过方法来表达，会使功能扩展更高效。

去掉“幽灵类”

项目中偶尔会出现一些“幽灵类”，这些类没有做什么实际工作，只是负责调用其它的类，不如把这个“中间人”去掉，让实际要调用的那个类与调用者发生关系。

抽象相同类为基类

如果两个类，其中某几个方法作用相同，名称不同，那就可以通过修改名称或移植方法的方式将两个相似的类保持一致，然后把两个类抽象出基类，以便扩展。

增加注释

注释多并不是一件坏事，它是重构的领路人，当你感觉需要为某段代码写上注释时，这意味着你认为这段代码不容易被他人理解，也侧面证明了这就是重构发出的预警信号，所以当想要写注释时，就先重构，争取让注释都变得多余。