您现在的位置是:首页 >技术交流 >Day957.重构“烂代码” -遗留系统现代化实战网站首页技术交流
Day957.重构“烂代码” -遗留系统现代化实战
重构“烂代码”
Hi,我是阿昌
,今天学习记录的是关于重构“烂代码”
的内容。
一、基于坏味道的重构
在重构时,要尽量先去识别《重构》中总结的二十几种坏味道,再用书中对应的重构手法去重构。可能会质疑,要不要这么教条啊?这其实并不是教条。
Martin Fowler 已经“阅码无数”,甚至可能比我吃的饭都多。他总结出来的坏味道已经足够典型,对应的重构手法也足够好用。
尽管重构起来挑战重重,但攻克它们又令人上瘾、着迷、欲罢不能。
这样安排,是为了授之以渔(即重构的方法),而不光是授之以鱼(即重构好的方法)。
二、倚天剑:拆分阶段
拆分阶段(Split Phase)。这是 Martin Fowler 在《重构(第 2 版)》中新提出的一种重构手法。
当第一次看到这个手法的介绍时,简直茅塞顿开(当然,第一次看到《重构》中的很多内容时,都是这个状态)。
它解决了在面临遗留代码时最头疼的问题。
遗留代码最大的问题就是方法过长。方法长了之后,前后几代开发人员不停往里塞东西,有的加在这里,有的加在那里,导致最后谁都无法分清到底方法做了几件事情。方法长了就不是单一职责(SRP)了,但更要命的是,由于代码过于混乱,甚至说不清楚到底有哪些职责。
拆分阶段就像倚天剑一样,轻巧地把方法到底做了几件事情给拎清楚,把相关的代码组织到一起。
比如,大多数情况下,一个方法都在处理这样的三个阶段:
- 第一,校验、转换传入的数据;
第二,根据传入或转换后的数据,完成业务处理;
第三,准备要返回的数据并返回。其中第二个阶段如果过于复杂,还可以拆分成更多的小步骤。
一个例子。以下代码来自一个拆分阶段的重构 Kata,它出自《重构(第 2 版)》的第 1 章,作者对原来的代码做了一些简化,使之更适合拆分阶段的重构练习。
可以在GitHub上找到完整的代码。
public class TheatricalPlayers {
public String print(Invoice invoice) {
var totalAmount = 0;
var volumeCredits = 0;
var result = String.format("Statement for %s
", invoice.customer);
NumberFormat format = NumberFormat.getCurrencyInstance(Locale.US);
for (var perf : invoice.performances) {
var play = perf.play;
var thisAmount = 40000;
if (perf.audience > 30) {
thisAmount += 1000 * (perf.audience - 30);
}
var thisCredits = Math.max(perf.audience - 30, 0);
if ("comedy".equals(play.type)) thisCredits += Math.floor((double) perf.audience / 5);
totalAmount += thisAmount;
volumeCredits += thisCredits;
}
result += String.format("Amount owed is %s
", format.format(totalAmount / 100));
result += String.format("You earned %s credits
", volumeCredits);
return result;
}
}
它计算了演出的总费用以及观众量积分(volume credits,根据到场的观众数量来计算的积分,下次客户再请剧团演出的时候,可以用这个积分获得折扣),并且对这两项数据进行格式化并返回。
看到这样的描述,估计第一反应就是,它违反了单一职责原则(SRP)。
没错,一个方法承担了计算总费用、计算观众量积分和格式化信息这三个职责。
然而更喜欢用《重构》中介绍的坏味道发散式变化(divergent change)来评价它。
一个类或方法应该只有一个引起它变化的原因,而对于这个方法来说,显然有三个。
如果计算费用的逻辑发生变化,比如观众的基数从 30 改成了 50;
如果计算积分的逻辑发生变化,比如演出悲剧也有相应的积分;
如果格式化的逻辑发生变化,比如用 HTML 来输出清单,你都需要修改这个方法。引起它变化的原因,不是一个,而是三个。
对于这个坏味道,《重构》的建议是,如果不同的变化方向形成了先后顺序,就用拆分阶段手法将它们分开。我们来看看该怎么操作。
首先,在开始正式重构之前,我建议你先运行一下所有的测试,确保通过。
再仔细观察这段代码很多变量的声明和使用的位置离得非常远。这是遗留代码的典型特点。
-
一方面,一些古老的编程语言或编程风格,以及某些大学课程,要求你把方法内的所有变量都声明在方法开头。
-
另一方面,由于代码经手的人太多,很多人会有意无意将自己的代码插入到变量的声明和使用之间。
向于给局部变量更小的作用域,也就是在使用它之前再声明。先把 result 和 format 两个变量的声明往下挪,挪到 result 使用之前。
仅此一步,其实已经完成了拆分阶段的部分内容,把格式化部分的逻辑择了出来。别忘了运行测试。
虽然只有这一步,几乎可以 100% 确认没有问题,但仍然需要运行一下测试,养成好习惯。
public class TheatricalPlayers {
public String print(Invoice invoice) {
var totalAmount = 0;
var volumeCredits = 0;
for (var perf : invoice.performances) {
var play = perf.play;
var thisAmount = 40000;
if (perf.audience > 30) {
thisAmount += 1000 * (perf.audience - 30);
}
var thisCredits = Math.max(perf.audience - 30, 0);
if ("comedy".equals(play.type)) thisCredits += Math.floor((double) perf.audience / 5);
totalAmount += thisAmount;
volumeCredits += thisCredits;
}
var result = String.format("Statement for %s
", invoice.customer);
NumberFormat format = NumberFormat.getCurrencyInstance(Locale.US);
result += String.format("Amount owed is %s
", format.format(totalAmount / 100));
result += String.format("You earned %s credits
", volumeCredits);
return result;
}
}
第二步,来看看 for 循环里面吧。play 变量也和使用它的地方差了 6 行的距离,一定二话不说,也往下移。但是等等,再仔细观察一下,其实只有一个地方在使用这个 play,干脆不用移动了,直接内联
(inline)吧。
注意,说的移动一行代码和内联,包括后面的提取方法和移动方法,在大多数 IDE 中都是有快捷键的。强烈建议记住并熟练运用这些快捷键,它们可以使事半功倍。
第三步,计算 thisAmount 的代码已经集中在了一起,这也是拆分阶段的阶段性成果。不要迟疑,把它们提取成一个方法,彻底和下面的代码划清界限。我们来看看,现在的代码变成了什么样子:
public String print(Invoice invoice) {
var totalAmount = 0;
var volumeCredits = 0;
for (var perf : invoice.performances) {
int thisAmount = getThisAmount(perf);
var thisCredits = Math.max(perf.audience - 30, 0);
if ("comedy".equals(perf.play.type)) thisCredits += Math.floor((double) perf.audience / 5);
totalAmount += thisAmount;
volumeCredits += thisCredits;
}
// format代码
}
第四步,把 totalAmount 的累加代码上移,让使用 thisAmount 和声明 thisAmount 的代码挨在一起。
thisAmount 也只有这一处调用,完全可以内联。
可能正发愁这个变量名不知道怎么改好,这样一内联,它就不见了,真是一了百了。
第五步,重复上面的第三、四步,把计算 thisCredits 的方法提取出来,并内联 thisCredits。
这时 for 循环内部,只剩短短的两行代码了。
for (var perf : invoice.performances) {
totalAmount += getThisAmount(perf);
volumeCredits += getThisCredits(perf);
}
是不是已经很清爽了?但其实还有改进空间,不要停止脚步,继续。变量 totalAmount 和 valumeCredits 的声明和使用还是分离的,而且它们在循环内部赋值,在循环后面使用,这样的变量似乎只能在循环前面声明。
第六步,复制一下这个 for 循环,分别删掉两个 for 中的 volumeCredits 和 totalAmount 的赋值语句,用两个 for 循环分别计算 totalAmount 和 volumeCredits。
对这一步你可能有异议,本来一个循环变为了两个,性能变差了呀。的确,性能是变差了那么一点点,但这一点点性能损失与它所带来的可读性提升相比,根本不值一提。
第七步,把 totalAmount 和 volumeCredits 的声明和各自的 for 循环移到一起,形成下面这样的形式:
public String print(Invoice invoice) {
var totalAmount = 0;
for (var perf : invoice.performances) {
totalAmount += getThisAmount(perf);
}
var volumeCredits = 0;
for (var perf : invoice.performances) {
volumeCredits += getThisCredits(perf);
}
var result = String.format("Statement for %s
", invoice.customer);
var format = NumberFormat.getCurrencyInstance(Locale.US);
result += String.format("Amount owed is %s
", format.format(totalAmount / 100));
result += String.format("You earned %s credits
", volumeCredits);
return result;
}
到这一步,基本完成了拆分阶段的重构。
代码本来是一团乱麻,被倚天剑劈成了三段,分别负责计算 totalAmount、计算 volumeCredits 和格式化输出结果。代码已经相当清爽了。
拆分阶段不过就是重新组织代码,把跟某个逻辑相关的语句,从原先分散的各处拎出来,统统合并在一起。
可以用空行隔开不同阶段,也可以抽取出方法,这样就能让原方法显得更简洁一些。
因此,第八步,把各个阶段提取成单独的方法,彻底完成重构。
public String print(Invoice invoice) {
int totalAmount = getTotalAmount(invoice);
int volumeCredits = getVolumeCredits(invoice);
return getResult(invoice, totalAmount, volumeCredits);
}
总结一下重构这段代码的八个步骤,如下图:
把一个长方法拆分成多个阶段,并抽取成小的方法,这样做不但能使代码异常整洁,而且在需要修改的时候,只需找到相关的小方法,而完全不需要去关心其他小方法内的细节,从而降低了认知负载
。
拆分阶段不仅适用于代码拆分,而且也可以用于存储过程和函数的拆分。
展示了倚天剑,是时候掏出屠龙刀了,它可以将职责不相关的代码彻底斩断关系。
三、屠龙刀:方法对象
方法对象(Method Object) 是极限编程和 TDD 之父 Kent Beck 在《实现模式》中提出的一种模式。
Kent Beck 甚至直言,这是他最喜爱的模式之一。所谓方法对象,就是指只包含一个方法的对象,这个方法就是该对象主要的业务逻辑。
如果你不知道如何隔离不同的职责,就可以“无脑”地使用方法对象模式,将不同职责都提取到不同的方法对象中。
仍然以上面介绍的代码为例来介绍方法对象。
拆分阶段完成之后的完整代码如下:
public class TheatricalPlayers {
public String print(Invoice invoice) {
int totalAmount = getTotalAmount(invoice);
int volumeCredits = getVolumeCredits(invoice);
return getResult(invoice, totalAmount, volumeCredits);
}
private int getTotalAmount(Invoice invoice) {
var totalAmount = 0;
for (var perf : invoice.performances) {
totalAmount += getThisAmount(perf);
}
return totalAmount;
}
private int getThisAmount(Performance perf) {
var thisAmount = 40000;
if (perf.audience > 30) {
thisAmount += 1000 * (perf.audience - 30);
}
return thisAmount;
}
private int getVolumeCredits(Invoice invoice) {
var volumeCredits = 0;
for (var perf : invoice.performances) {
volumeCredits += getThisCredits(perf);
}
return volumeCredits;
}
private int getThisCredits(Performance perf) {
var thisCredits = Math.max(perf.audience - 30, 0);
if ("comedy".equals(perf.play.type)) thisCredits += Math.floor((double) perf.audience / 5);
return thisCredits;
}
private String getResult(Invoice invoice, int totalAmount, int volumeCredits) {
var result = String.format("Statement for %s
", invoice.customer);
var format = NumberFormat.getCurrencyInstance(Locale.US);
result += String.format("Amount owed is %s
", format.format(totalAmount / 100));
result += String.format("You earned %s credits
", volumeCredits);
return result;
}
}
代码的坏味道仍然是发散式变化,只不过从方法级别变成了类级别,当三个阶段的任何一个逻辑发生变化的时候,你都需要修改这个类。
要做的就是把 getTotalAmount、getVolumeCredits 和 getResult 三个方法都移动到不同的方法对象中。
我最擅长的就是 Copy&Paste 了。先别急着按 Ctrl(Cmd)+ C,IDE 普遍提供了强大的重构工具支持,如果不能物尽其用,简直就是暴殄天物了。
完全可以全都使用重构工具来自动完成这些重构,甚至都不需要碰鼠标。
在这里就以 Mac 版的 IntelliJ IDEA 来演示一下,如何只用键盘就安全地实现移动方法的重构。
先来移动 getTotalAmount 这个方法。由于它还调用了 getThisAmount,所以必须连带着把它也移走。
为了避免这个麻烦,可以选择先把 getThisAmount 内联,这样就只需要移动一个方法了。
可以把光标放到 getThisAmount 的方法定义处或者调用处,然后按 Cmd+Opt+N,在弹出的对话框中选择“Inline all and remove the method”。
下一步,按下 Opt+F1,唤出选择视图的菜单,再按回车选择第一个 Project View,这时焦点正好在 TheatricalPlayers 类上。
可以按 Cmd+N 在相同的包内创建一个新类,名字就叫 TotalAmountCalculator 吧。
Kent Beck 在书中介绍方法对象时说,可以用方法名的变形作为类名。
如果方法名叫 complexCalculation,那么类名就可以叫 ComplexCalculator。
这里的方法叫做 getTotalAmount,按同样的思路应该叫 TotalAmountGetter,但这个名字并不好,因为 getTotalAmount 这个名字本身就不好,其实应该叫 calculateTotalAmount。
创建完类之后,IDE 会帮我们打开这个类,然而现在并不打算对这个类做修改。
可以按 Ctrl+Tab 跳回到 TheatricalPlayers 类中,把光标放到 getTotalAmount 方法签名上,按 Cmd+F6 来修改它的签名,将刚刚创建的 TotalAmountCalculator 作为方法的参数,在参数默认值的文本框中,可以填 new TotalAmountCalculator()。
按下回车,方法的签名就改好了。为什么要把新建的类作为方法参数呢?方法内又没有用到,这不是多此一举吗?
把光标放到 getTotalAmount 的方法名上,按下 F6,会弹出移动方法的对话框,要选择一个对象来移动你的方法。
由于想把方法移动到新建的 TotalAmountCalculator 中,所以当然要选这个。
按下回车,getTotalAmount 方法就被神奇地移动到了 TotalAmountCalculator 中。
现在应该明白了为什么要把 TotalAmountCalculator 放到方法参数中了吧?
因为要移动方法时,需要选择一个位置,这个位置就是这个方法所依赖的类。
放到方法参数中就相当于让它依赖了 TotalAmountCalculator,这样才能在后续移动方法时,选择 TotalAmountCalculator 作为移动的目标。
接下来,可以用同样的方式来移动 getVolumeCredits 和 getResult 方法,这里就不一一演示了。
完成之后的代码如下:
public String print(Invoice invoice) {
int totalAmount = new TotalAmountCalculator().getTotalAmount(invoice);
int volumeCredits = new VolumeCreditsCalculator().getVolumeCredits(invoice);
return new ResultFormatter().getResult(invoice, totalAmount, volumeCredits);
}
由于是在方法中直接构造的这些 DOC,可以把它们提取成接缝,通过构造函数进行注入。
再做一些重命名,把看着不爽的方法名通通改掉。
public class TheatricalPlayers {
private TotalAmountCalculator totalAmountCalculator;
private VolumeCreditsCalculator volumeCreditsCalculator;
private ResultFormatter resultFormatter;
public TheatricalPlayers(TotalAmountCalculator totalAmountCalculator, VolumeCreditsCalculator volumeCreditsCalculator, ResultFormatter resultFormatter) {
this.totalAmountCalculator = totalAmountCalculator;
this.volumeCreditsCalculator = volumeCreditsCalculator;
this.resultFormatter = resultFormatter;
}
public String print(Invoice invoice) {
int totalAmount = totalAmountCalculator.calculate(invoice);
int volumeCredits = volumeCreditsCalculator.calculate(invoice);
return resultFormatter.format(invoice, totalAmount, volumeCredits);
}
}
到这里,方法对象的重构就全部完成了。
它就像屠龙刀一样,彻底劈开了不同职责之间的联系,让它们各自位于自己的方法对象里。
在重构了大量遗留代码之后发现,虽然不同代码最终的样子不尽相同,但过程中似乎都包含了方法对象。
有些可能会进一步重构成行为型的设计模式,有些就干脆以方法对象为终点。
可以说,方法对象,是设计模式的中间步骤。
用快捷键秀操作的过程就到此为止了。
创建了两个关于快捷键的小测验,一个是Mac 版,一个是Windows 版,可以刻意练习一下。
这样做的好处是,每一个步骤都是 IDE 自动完成的,是比较安全的。
即使在没有测试的情况下,也能相对安全地完成重构。
当然,这可不是鼓励你在没有测试的情况下就去重构,这只是万不得已的情况。
用快捷键来操作,也是 IntelliJ IDEA 的正确打开方式,它可以大大提高你的开发效率
,让手速能够跟上你的思维。
如果熟练的话,整个重构过程不超过 1 分钟就能完成,省去了各种上下文切换的成本,比如键鼠切换、Tab 页切换等。
四、重构结束了吗?
有人可能认为重构已经结束了,但如果对代码有洁癖,就不能容忍坏味道的存在。
虽然提取出了三个方法对象,但代码仍然有问题。
下面再提供两种不同的重构方向。
可以来比较一下。
五、重构到策略模式
仔细观察 TotalAmountCalculator 和 VolumeCreditsCalculator,它们的方法签名非常类似,都是接受一个 Invoice 参数,返回一个 int。
这种坏味道叫做异曲同工的类(Alternative Classes with Different Interfaces),可以提取接口,让这两个类实现同一个接口:
public interface InvoiceCalculator {
int calculate(Invoice invoice);
}
TheatricalPlayers 将变成:
public class TheatricalPlayers {
private InvoiceCalculator totalAmountCalculator;
private InvoiceCalculator volumeCreditsCalculator;
private ResultFormatter resultFormatter;
public TheatricalPlayers(InvoiceCalculator totalAmountCalculator, InvoiceCalculator volumeCreditsCalculator, ResultFormatter resultFormatter) {
this.totalAmountCalculator = totalAmountCalculator;
this.volumeCreditsCalculator = volumeCreditsCalculator;
this.resultFormatter = resultFormatter;
}
// print方法
}
现在,不同的 calculator 都实现了同一个接口,貌似重构到了策略模式
。
看过《重构与模式》的人可能会暗喜,重构到设计模式可是重构的最高境界啊,代码貌似向着“整洁”的方向又迈进了一大步。
然而真的是这样吗?先来看看另一种重构思路。
六、重构到领域模型
看看 TotalAmountCalculator 这个方法对象,它只依赖 Invoice 类,并且本身没有任何数据。
这种大量依赖外部数据,而不依赖自己内部数据的坏味道,叫做依恋情结
(Feature Envy)。
可以直接将方法移动到 Invoice 内部。
用上面学到的快捷键,按一下 F6 就可以搞定。移动之后的 Invoice 类如下所示:
public class Invoice {
// 其他代码
int calculate() {
var totalAmount = 0;
for (var perf : performances) {
var thisAmount = 40000;
if (perf.audience > 30) {
thisAmount += 1000 * (perf.audience - 30);
}
totalAmount += thisAmount;
}
return totalAmount;
}
}
这时这个方法再叫 calculate 就不合适了,把它改回 getTotalAmount,如果不喜欢 get 为前缀的名字,也可以叫 calculateTotalAmount。
还会发现,移动到 Invoice 中来之后,这个方法就只依赖 Performance 了,Invoice 不过是遍历了多个 Performance 而已。
可以提取计算单个 Performance 的 Amount 的方法,看看会发生什么。
int calculateTotalAmount() {
var totalAmount = 0;
for (var perf : performances) {
int thisAmount = getThisAmount(perf);
totalAmount += thisAmount;
}
return totalAmount;
}
private int getThisAmount(Performance perf) {
var thisAmount = 40000;
if (perf.audience > 30) {
thisAmount += 1000 * (perf.audience - 30);
}
return thisAmount;
}
会发现 getThisAmount 方法只依赖 Performance,这又是依恋情结坏味道。
同样的,可以把方法移动到 Performance 内来消除。
移动完之后,calculateTotalAmount 变为:
int calculateTotalAmount() {
var totalAmount = 0;
for (var perf : performances) {
int thisAmount = perf.calculateAmount();
totalAmount += thisAmount;
}
return totalAmount;
}
这时你还可以充分发挥 Java stream 的语法特性,将 for 循环也消除掉:
int calculateTotalAmount() {
return performances.stream().mapToInt(Performance::calculateAmount).sum();
}
同样的,VolumeCreditsCalculator 方法也存在依恋情结坏味道,可以用同样的方式来重构。
都完成后,TheatricalPlayers 类的 print 方法将如下所示:
public String print(Invoice invoice) {
int totalAmount = invoice.calculateTotalAmount();
int volumeCredits = invoice.calculateVolumeCredits();
return resultFormatter.getResult(invoice, totalAmount, volumeCredits);
}
这时,可以将 totalAmount 和 volumeCredits 内联,这样方法就剩下了一行。
它的职责就只剩下了格式化结果,因为计算 totalAmount 和 volumeCredits 的逻辑已经被隔离在了 Invoice 中。
那么当前方法和 ResultFormatter 的职责也重叠了,我们可以把这个 getResult 方法也内联掉。
public String print(Invoice invoice) {
var format = NumberFormat.getCurrencyInstance(Locale.US);
var result = String.format("Statement for %s
", invoice.customer);
result += String.format("Amount owed is %s
", format.format(invoice.calculateTotalAmount() / 100));
result += String.format("You earned %s credits
", invoice.calculateVolumeCredits());
return result;
}
把重构出来的三个方法对象,居然又全部消除掉了!
为什么产生了“消消乐”一样的效果呢?这是因为把计算的逻辑都放到了 Invoice 和 Performance 对象中,就没有必要引入其他的算法类(方法对象)了。这种把数据行为都放在对象中的模式,叫做领域模型模式
。
比较一下上面提到的两种重构方向,觉得哪种更适合当前的代码呢?
答案是第二种。
第一种重构虽然看上去像是“策略模式”,但实际上策略接口的两个实现类并不是相互替换的关系,而是“毫无关系”。
所有行为型模式的共同特点是,不同的行为可以根据某些条件相互替换,直白点说就是,要有 if/else,才能体现出这些替换。
而代码中的 TotalAmountCalculator 和 VolumeCreditsCalculator 虽然都叫 calculator,但没有 if/else,它们在原方法中是顺序执行的,不能相互替换。必须对所有代码坏味道和模式非常熟悉,才能找到正确的重构方向。重构到设计模式固然美好,但并不一定就是最终目标,有时候可能会用错设计模式,有时候会过度设计。
重构到一个刚刚好的状态,没有明显的坏味道,就足够了。
七、总结
重构手法和模式还有很多很多,之所以认为这两个特别实用,是因为在重构了大量遗留代码后,发现拆分阶段和方法对象是必不可少的中间步骤。当通过这两种方式完成了初步重构之后,还要审视一下代码,根据坏味道实现下一步的重构。
方法对象的时候,穿插了如何使用快捷键来完成重构。可能会觉得记住额外的快捷键属于外在认知负载,其实不然。它们能够提高你的工作效率,而且一旦记住并且熟练掌握,就能一劳永逸。
这种知识属于内在认知负载,是完成工作必须具备的技能。重构手法也好,快捷键也罢,都不是什么奇技淫巧,而是像玄铁重剑一样,重剑无锋,大巧不工。它们应该融化在每一个开发人员的血液里。