您的位置:知识库 » 软件设计

重构 — 勿以善小而不为

作者: 张逸  发布时间: 2012-07-04 13:04  阅读: 3399 次  推荐: 6   原文链接   [收藏]  

  重构最大的敌人不是技巧与能力,而是懒惰,或者说是态度。许多细小的重构看似无足轻重,例如方法重命名、提取方法。即使重构了,似乎对代码的结构也没有太大的影响,于是就决定淡然处之,心里想“事情还未到不可挽回的地步,实现功能要紧,至于重构,还是以后再做吧!”这样一想,于是就会滋生得过且过的想法,等到代码开始变得一团糟时,重构已经变得无比困难了。此时需要的重构技巧,将百倍难于发现坏味道之初。

  在我参加的前一个项目中,我们定义了一个处理OrderSet的Controller。刚刚开始开发时,对于OrderSet的操作并不多,主要是Search与Count操作。OrderSet分为WithDetails与WithoutDetail两种类型。为了实现的简单,我们将这两种类型的操作都放在一个Controller中。随着操作的逐渐增多,这个Controller就变得越来越庞大,逐渐变得臃肿起来。每当我需要调用或者修改Controller时,我都在想:“嗯,这个代码太糟糕了,什么时候给它重构一下。”想是这么想,却一直扮演着说话的巨人,行动的矮子。即使兴起这样的念头,又因为其他的工作将此念头浇灭。直到有一天,这个Controller的代码已经到了忍无可忍的地步,我和我的Pair终于达成一致意见,决定对此代码进行手术。我们花费了近一天的时间对Controller以及相关的Repository进行了彻底的重构。重构前后的代码天差地别,我终于可以不用像吃了苍蝇那般看着代码恶心了。这种重构后体验到的愉悦简直无与伦比,最关键是结果令人满意,重构后的代码变得更可读,更简单,也更容易增加新的功能。

  如今工作的项目,需要对遗留系统进行迁移。首要的任务是为此系统编写BDD测试,以期搭建迁移的测试保护网,并能够形成可读与可工作的测试用例文档。在开始接触这个任务时,客户方的开发人员已经基本搭建好了初步的框架。当我们在面对不良代码时,第一个浮现在脑海中的念头是“重构”,然而考虑到时间因素,随之又强迫自己灭了这个念头,因为我们需要考虑项目的进度。我们总是在这样的取舍之中艰难前进,终于,在系统需要增加一个新消息的测试时,我强烈地感受到重构的迫在眉睫。即使代码有诸多破窗,修补了一扇,总强过听之任之。经过接近一天多的重构(当然还包括run tests以及build花费的时间),结果令人满意。回顾这个过程,我发现在发现坏味道时,如果能及时地对代码进行重构,并保证重构的小步前进,并不会阻碍开发进度,相反还能够在一定程度改善代码质量,提高代码的可读性、可重用性以及可扩展性。所谓“勿以善小而不为”,千万不要因为小重构对代码质量的影响微乎其微而轻视她,或者忽略她,又或者推迟到忍无可忍再想到重构。重构并非最后的救命稻草,而是随时保持我们正确前进的一把尺子。

  说完了重构的重要性,让我再来粗略地介绍这个重构过程。

  我们的测试程序主要针对Message的发送、接收与验证。业务的处理则由部署在JBoss上的应用来处理。我们需要设定期望的Message,在发送请求到远程系统后,接收返回的消息,并验证消息以及数据库是否符合我们的期望。重构的起因在于我们需要编写新的测试覆盖之前从未测试过的消息,其类型为SO08。如果沿用之前的实现,我们就需要在测试步骤中增加MessageType的分支,根据消息类型对返回的消息进行检查。

  检查的逻辑事实上已经被抽象为MessageChecker接口,并为各种类型的消息建立了不同的MessageChecker子类。MessageCheckFactory则这些子类的工厂,负责根据类型创建对应的子类对象。这样的设计是完全合理的。然而,问题出现在MessageReceiver,它提供了接收消息的方法,通过传入的消息类型、队列名称等参数,返回消息。这个返回值被定义为MessageReader。

  MessageReader正是问题的症结。我一直强调的面向对象设计中一个重要概念就是所谓”对象的自治“,即对象的职责是自我完备的,它能够对自己拥有的数据负责,具备了“智能”处理的行为特征。MessageReader违背了这一原则,它是愚笨的对象,仿佛“坐拥宝山而不知”的笨伯,虽然拥有消息的值,却不知道该如何处理这些消息。简而言之,它提供的方法只能对XML格式的消息进行读取,却不具有真正的业务行为。于是在测试步骤中,就产生了这样的代码(省略了部分实现代码):

private void checkPropagationQueueByName(String name, Queue queue, MessageType messageType) {
    MessageReader reader = messageReceiver.getMessageFor(messageType, identifier, queue);
    String messageText = reader.toString();
    if (messageType == SO05) {
        messageCheckFactory.checkerFor(messageType, getExpectedSO05ResponseFor(name), messageText);
    }
    if (messageType == SO07) {
        checkSO07Response(name, messageType, messageText)
    }
    if (messageType == SO08) {
    messageCheckFactory.checkerFor(messageType, getExpectedSO08ResponseFor(name), messageText)
        .checkResponse();
    }
} 

  不幸的是,这样的逻辑处理在其他测试步骤中同样存在。我注意到,之所以要处理分支,是因为系统需要判断返回的消息是否符合期望,以实现测试目标。这个检查的逻辑根据不同的消息类型会有不同的处理逻辑(其中,主要逻辑则委派给由MessageCheckFactory创建的MessageChecker对象)。从接口来看,它们都需要接收返回的消息与期望的消息。以SO05为例,它需要返回的消息messageText,以及由getExpectedSO05ResponseFor(name)方法返回的期望的消息。对于SO07而言,实现方法稍显复杂,所以提取了一个私有方法checkSO07Response()来处理。

  毫无疑问,我清楚地嗅到了代码的坏味道。重构势在必行。一方面,这个分支的处理是不合理的,随着消息类型的增多,这条分支语句会越来越长。关键是这种处理接收消息的逻辑不止存在这一处,这种没有封装的实现方式可能导致出现重复代码,违背了DRY原则。另一方面,则是对ExpectedMessage的处理。它分散在多个测试步骤中,有的放在AddUpdateCustomerSteps,有的则被提取到AbstractSteps类。从职责分配的角度看,测试步骤本身并不应该承担创建或获取ExpectedMessage的职责。

  重构的目标就是MessageReceiver接口。我首先查看了MessageReceiver的实现类与调用者,发现其实现类只有一个,即DefaultMessageReceiver。调用者则非常多,调用的方法为getMessageFor()。事实上,这个方法正是我要操刀手术的目标方法。我希望它能够返回ResponseMessage自治对象,而非MessageReader。这意味着我们既需要修改方法的签名,同时还需要修改实现。修改方法签名会影响到调用的依赖点。在依赖点较多的情况下,这种重构需要谨慎处理。

  我以为,在重构时首先需要明确重构的目的是什么,然后还需要理清楚整个重构的步骤,最后有条不紊地实施重构。显然,我们的目的是希望消除分支语句,并以统一的方式对各种类型的返回消息进行处理。根据对自治对象的分析,这意味着需要赋予ResponseMessage以行为,使得它自身就能够处理对ExpectedMessage的验证。由于创建ExpectedMessage的逻辑是分散的,因此,我们需要首先对这部分功能进行重构。以getExpectedSO05ResponseFor(name)方法的重构为例。该方法的实现如下所示:

private MessageReader getExpectedSO05ResponseFor(String name) {
    MessageWriter writer;
    if (scenarioContext.hasExpectedMessage() &&
            scenarioContext.getExpectedMessage().getMessageType() == SO05) {
        writer = scenarioContext.getExpectedMessage();         
    } else {
        writer = transformerFactory.transformerFor(scenarioContext.getRequestMessage(), SO05)
                .forCustomer(name)
                .transform();
    }
 
    writer.selectBlock(SO05_MESSAGE_HEADER);
    writer.setFieldValue(MESSAGE_HEADER.USER_ID, null);
    writer.selectBlock(SO05_PROFILE);
 
    String identifier = storyContext.getCustomerIdentifier(name);
    writer.setFieldValue(PROFILE.PROFILE_ID, identifier);
    String customerVersion = scenarioContext.getCustomerVersion();
    writer.setFieldValue(PROFILE.USER_COUNT, customerVersion);
 
    if (writer.selectBlockIfExists(SO05_INDIVIDUAL)) {
        writer.setFieldValue(INDIVIDUAL_CUSTOMER_TYPE, null);
    }
 
    return messageFactory.readFor(SO05, writer.toString());
} 

  我们需要定义一个专门的对象来承担这一职责,因此,我引入了一个新对象ExpectedMessageFactory。通过采用Move Method手法(快捷键为F6,指IntelliJ下的快捷键,下同)可以完成这一重构。若要通过IDE自动帮助我们完成这一重构,就首先需要将该方法定义为static方法。然而,观察该方法的实现,它调用了许多字段值,例如scenarioContext,transformFactory等。由于这些字段并非static的,一旦将方法设置为static,使用这些字段就会提示错误。因此,在进行Move Method重构之前,需要首先将该方法调用的字段提取为参数,即运用Extract Parameter重构手法(快捷键为Ctrl+Alt+P)。如果该方法还调用了其他方法,则需要分析了解这些方法存在多少依赖,从职责上看是否也需要转移?如果只有重构的目标方法调用了它,则可以将方法内联(快捷键位Ctrl+ALT+N)。

  做好这些准备工作后,就可以移动方法了。所有的这些手法,IDE都提供了自动重构的工具,所以并不须要担心这样的重构会引入新的问题。转移了方法后,原来的依赖点就自动改为对静态方法的调用。由于我们还需要再将其修改为非静态方法,此时,我们需要手动地修改所有原来对静态方法的调用。同时,对于当初为了移动方便而提取出来的参数,在移动到新类后,还需要恢复其原有地位,即将这些参数再提取为字段(快捷键为Ctrl+ALT+F)。之所以要这样做,一方面可以减少方法的参数,使得方法变得更为简洁,另一方面也可以提高类的内聚性。在转移了方法后,我还对原方法进行了Extract Method重构(快捷键为Ctrl+ALT+M):

private MessageReader getExpectedSO05ResponseFor(String name) {
    MessageWriter writer = initializeExpectedMessage(name, SO05);
    setSO05MessageHeader(writer);
    setSO05Profile(name, writer);
    setSO05Individual(writer);
 
    return messageFactory.readFor(SO05, writer.toString());
}
 
private MessageWriter initializeExpectedMessage(String name, MessageType messageType) {
    MessageWriter messageWriter;
    if (scenarioContext.hasExpectedMessage() &&
            scenarioContext.getExpectedMessage().getMessageType() == messageType) {
        writer = scenarioContext.getExpectedMessage();         
    } else {
        writer = transformerFactory.transformerFor(scenarioContext.getRequestMessage(), messageType)
                .forCustomer(name)
                .transform();
    }
 
    return messageWriter;
}
 
private void setSO05MessageHeader(MessageWriter writer) {
    writer.selectBlock(SO05_MESSAGE_HEADER);
    writer.setFieldValue(MESSAGE_HEADER.USER_ID, null);
}
 
private void setSO05Profile(String name, MessageWriter writer) {
    writer.selectBlock(SO05_PROFILE);
 
    String identifier = storyContext.getCustomerIdentifier(name);
    writer.setFieldValue(PROFILE.PROFILE_ID, identifier);
    String customerVersion = scenarioContext.getCustomerVersion();
    writer.setFieldValue(PROFILE.USER_COUNT, customerVersion);
}
 
private void setSO05Individual(MessageWriter writer) {
    if (writer.selectBlockIfExists(SO05_INDIVIDUAL)) {
        writer.setFieldValue(INDIVIDUAL_CUSTOMER_TYPE, null);
    }
} 

  通过对方法的提取,一方面以能表达功能意图的方法名提高代码的可读性,另一方面还能通过这种重构发现可能重用的方法,例如上面代码片段中的initializeExpectedMessage(),就是在经过提取方法的重构后,才发现其实对于SO07消息而言,同样存在相同的初始化逻辑。

private MessageWriter getExpectedSO07WriterFor(String name) {
    MessageWriter writer = initializeExpectedMessage(name, SO07);
    setSO07Details(name, writer);
    setSO07Blocks(name, writer);
    return writer;
} 

  在完成对ExpectedMessage创建功能的重构后,接下来就可以考虑处理MessageReceiver了。看起来,我们必须修改getMessageFor()方法的签名。一种稳妥的做法是暂时保留该方法,然后引入一个新方法,并在新方法中调用getMessageFor()方法。不过,这种方式需要我们手动地去修改所有依赖点;另一种做法则是先通过提取方法的方式,将原有getMessageFor()的所有实现提取到一个私有方法中,然后再直接利用修改方法签名的重构手法(快捷键为Ctrl+F6),直接修改getMessageFor()。这样做的好处是IDE工具可以直接帮助你修改所有的依赖点,同时还能够保留原有的实现。为了更好地表达方法的意图,我还对该方法进行了更名重构(快捷键为Shift+F6),将其重命名为getResponseMessage()。由于方法的返回值发生了变化,所以依赖该方法的地方都会出现返回值类型不吻合的提示。在IntelliJ中,我们可以很容易地找到这些提示位置,并直接通过Alt+Enter根据工具给出的提示,来改变返回值类型。

  改变了返回值类型并不意味着完事大吉,因为后面对该返回类型的调用,即前面提到的那段分支语句,仍然是不一致的。原来使用的是MessageReader对象,现在变成ResponseMessage对象了。这就需要我们手动地修改这些调用。当然,也有一种取巧的办法,就是将这些代码结合Extract Method与Move Method重构手法,再转移到我们引入的ResponseMessage中,因为在我们之前的分析中,已经明确这些分支判断逻辑应该封装到ResponseMessage对象。最终的重构结果为:

public abstract class ResponseMessage {
    public ResponseMessage(MessageReader messageReader) {
        this.messageReader = messageReader;
    }
 
    public void check(MessageReader expectedMessage) {
        messageCheckFactory.checkerFor(getMessageType(), expectedMessage, getMessageText()).checkResponse();
    }
 
    protected abstract MessageType getMessageType();
}
 
public class SO05ResponseMessage extends ResponseMessage {
    public SO05ResponseMessage(MessageReader messageReader) {
        super(messageReader);
    }
 
    @Override
    protected MessageType getMessageType() {
        return MessageType.SO05;
    }
}
public class DefaultMessageReceiver {
    public ResponseMessage getResponseMessage(MessageType type, String identifier, GCISQueue queue) {
        MessageReader messageReader = getMessageFor(type, identifier, queue);
        return createResponseMessage(type, messageReader, identifer);
    }
 
    private MessageReader getMessageFor(MessageType type, String identifier, GCISQueue queue) {
        MessageReader reader = getCachedMessageFor(type, identifier, queue);
        while (reader == null) {
            reader = getMessageFromQueueFor(type, identifer, queue);
        }
        return reader;
    }
 
    private ResponseMessage createResponseMessage(MessageType messageType, MessageReader messageReader, String identifer) {
        ResponseMessage message = null;
        switch (messageType) {
            case SO05:
                message = new SO05ResponseMessage(messageReader);
                break;
            case SO07:
                message = new SO07ResponseMessage(messageReader);
                break;
            case SO08:
                message = new SO08ResponseMessage(messageReader);
                break;
        }
 
        message.setMessageCheckFactory(messageCheckFactory);
        return message;
    }
}
 
//调用者
public class AddUpdateProductSystemCustomerSteps extends AbstractCustomerExpectationSteps {
    private void checkPropagationQueueByName(String name, Queue queue, MessageType messageType) {
        ResponseMessage responseMessage = messageReceiver.getMessageFor(messageType, identifier, queue);
    }
} 

  掌握重构的技巧并不难,关于在于你必须要有好的嗅觉,能够及时发现代码的坏味道。然而,即使你拥有高超的重构技艺,如果未能养成随时重构的好习惯,又能如何?换言之,重构能力体现的是你的专业技能,而重构习惯体现的则是你的职业素养。你是否愿意为追求高质量的卓越代码而为之付出时间和精力呢?你能否以好的结果来说服客户尊重你的重构成果呢?我觉得,对卓越软件的追求,不仅限于自己,同时也需要将此理念灌输给客户,并使得客户愿意为之付费。从软件成本来看,这种对高质量软件的追求或许违背了短期利益,但绝对符合软件开发的长期利益。

  所以,在下决心打磨代码质量之前,还是先找好重构这块磨刀石,并放到自己随时伸手可及的工具箱中吧。

6
0
标签:重构

软件设计热门文章

    软件设计最新文章

      最新新闻

        热门新闻