一个故事

在进入这个话题前，我们先讲一个故事。

开发同学从另一个团队接手了新的系统有一段时间了，但是平时都是加全新的功能，对已有的功能还没有完全熟悉。
这一天，我们的产品同学提了一个需求：我们需要在原来这个功能上新增一个东西，很简单，简单来说就是……。

开发同学听完需求后，发现这块功能并没有深入了解过，于是回去认真研究了下相关的产品功能，感觉改动不大，实现简单，于是信誓旦旦地对产品同学回复道：妥妥儿的，且看我一天搞定。

开发同学马不停蹄地打开IDE，一番摸索，很快找到相关功能所在的类，双击打开，IDE突然一阵卡顿。
开发同学有顿感不妙，仔细一看，一个庞大、难以理解的代码充斥着整个屏幕。

自己定的时间，含泪也得改完。

最后，开发同学在度日如年中，颤抖地完成了代码的提交，心里面却默默祈祷这次的改动不要引发其他问题。

不幸的是，最后还是出了故障。

不好的预感

墨菲定律：你越担心一件坏事发生，它就越可能发生。

上面故事中的场景，有没有一种似曾相识的感觉？

我们在平时工作中，是不是经常面临着时间紧迫，但必须修改的场景？

上线后，有没有问题全靠运气……

面对遗留系统，需要加入新的逻辑时，我们迫切需要一些具体的指导方案，能够安全地修改原有代码。

以下这些方法是你应该尝试的的方案：

• 使用TDD
• 使用新的方法
• 使用新的类
• 使用包裹方法
• 使用包裹类
• 安全消除重复代码

安全地修改方法

使用TDD

TDD（测试驱动开发）非常适合用于编写新的方法/类。

修改步骤

• 编写一个失败测试用例
• 让它编译通过
• 让测试通过
• 测试通过后再进行重构

使用TDD能够让我们更多时间去思考如何设计。

注意，我们一次操作只关注一件事情：重构或者编码。

我们大脑可不比计算机，如果同时处理多个事情，不仅仅降低效率，还容易引起问题。

使用新的方法

适用场景

若我们需要添加的代码连续出现在一个地方，使用新的方法来实现是一个好的做法。

修改步骤

确定修改点

public void scan(String x) {
    String result = x + x;
    display.show(result);

    // TODO 新增功能
    ...
}

插入新方法调用并注释

public void scan(String x) {
    String result = x + x;
    display.show(result);

    // TODO formatResult()
    ...
}

确定入参以及返回值

public void scan(String x) {
    String result = x + x;
    display.show(result);

    // TODO String result = formatResult(result)
    ...
}

测试驱动开发新的方法

@Test
public void testFormatResultWithLowerCase() {
    String result = new Demo().formatResult("x");
    Assert.assertEquals("X", result);
}

@Test
public void testFormatResultWithUpperCase() {
    String result = new Demo().formatResult("X");
    Assert.assertEquals("X", result);
}

在写单元测试时，我们必须注意，每次只测试一种行为。

然后不断完善代码，保证测试全部通过。

protected String formatResult(String result) {
    return result.toUpperCase();
}

去除注释，启用新方法

public void scan(String x) {
    String result = x + x;
    display.show(result);

    String result = formatResult(result)
    ...
}

protected String formatResult(String result) {
    return result.toUpperCase();
}

优点

• 新旧代码清晰隔离
• 新代码可以得到充分测试

缺点

• 原有方法依旧没有得到测试
• 新旧代码职责可能不清晰，导致进一步的混乱

使用新的类

适用场景

• 新功能是全新职责
• 新功能难以在原有类测试

修改步骤

修改步骤与新的方法基本一致，区别在于新特性在新的类实现。

我们需要记住，始终坚持TDD方式。

最终效果如下：

public class ScanResultFormatter {

    public String format(String result) {
        // 更多复杂的格式化逻辑
        return newResult;
    }
}

public void scan(String x) {
    String result = x + x;
    display.show(result);

    String result = scanResultFormatter.format(result)
    ...
}

优点

所有特性实现都在新的类完成，我们可以更加安全地进行改动，以及进行更加优雅地设计，让代码更容易测试。

缺点

若新功能职责不清晰时使用新的类，可能使系统更加复杂和混乱。

使用包裹方法

适用场景

有时候，我们新增的功能与原来的逻辑并没有必然联系，仅仅是因为它们需要在一块执行，如果我们强行把功能塞到原有方法中，会使得原有方法职责混乱不清。

这个时候，使用新生方法/类就可能不太合适，手段外，使用包裹方法是另一个好的选择。

修改步骤

确定修改点

public void scan(String x) {
    // TODO 新增功能

    String result = x + x;

    display.show(result);
   
    ...
}

将原有逻辑重命名

private String handleAndShowResult(String x) {
        String result = x + x;

    display.show(result);
}

创建新方法，与原有方法一致，保持签名

public String scan(String x) {
}

新方法调用重命名后的原方法

public String scan(String x) {
    handleAndShowResult(x);
}

增加特性方法

新方法依旧使用TDD方法

public String scan(String x) {
    addSomething(x);
    handleAndShowResult(x);
}

protected void addSomething(String x) {
    ...
}

另一种修改步骤

不想改变原有行为，可以新增一个方法

public void scanWithAddSomthing(String x) {
    addSomething(x);
    scan(x);
}

优点

• 新代码可以得到充分测试
• 显式地使新功能独立于既有功能，不会跟另一意图的代码互相纠缠在一起。

缺点

• 添加的新特性无法跟旧特性的逻辑“交融”在一起。
• 得为原方法中的旧代码起一个新名字。

使用包裹类

适用场景

• 添加的行为是完全独立的，并且我们不希望让低层或者不相关的行为污染现有类。
• 原类已经够大了，不想一直在上面加功能。

本质与使用包裹方法一样，但是通过包裹类，我们可以更加优雅地添加新特性。

修改步骤

确定修改点

新建类，接受修改类参数

public class WrapATDDemo {

    private Demo demo;

    public WrapATDDemo(Demo demo) {
        this.demo = demo;
    }

    public void scan(String x) {
        addSomething(x);
        demo.scan(x);
    }

    public void addSomething(String x) {
        ...
    }
}

使用TDD为包裹类实现新特性

替换原来使用旧类的地方为包裹类

new WrapATDDemo(new Demo()).scan();

优点

• 不会污染原有方法
• 能够帮助发现类的特性，抽象为接口或者抽象类
• 可以通过组合，得到各种复杂的新功能

扩展

没错，这就是设计模式中的装饰模式。

Java中常用的各类输入输出流就是装饰模式的经典实现。

安全消除重复代码

我们在修改代码时，往往会发现大量的重复代码，不巧的是，我们需要使用这些代码来实现新的功能。

摆在我们面前有两个选择：

• 复制粘贴，一切尽在掌握之中。
• 开始重构。音乐在哪里？都起来high！

保持现状，会让系统继续腐烂；激进地重构，可能产生未知的问题。

我们需要一个安全的手段来消除这些重复代码。

修改步骤

使用TDD编写代码

• 复制粘贴实现功能
• 测试通过后再进行重构

重构

• 不急于设计最终的完美类
• 从抽离独立小块重复代码开始
• 即使是小小的重复块也不要忽略
• 编写公共类
  • 相同流程，提供抽象类
  • 相同代码，独立职责类
• 命名
  • 尽量使用全称，而非缩写
  • 新类/方法具有明确的含义

优点

消除重复是锤炼设计的强大手段，它可以使设计变得更灵活，同时让修改代码更容易。

故事的最后

开发同学决定开始编写测试，但一开始的时候是很糟糕的，他觉得写测试时间比写代码还多，感觉做了浪费了好多时间。

但是慢慢地，他开始发现，那些杂乱无章的遗留系统中出现了越来越多更好的代码，并且修改代码也变得越来越容易，bug也越来越少，这时，他仿佛觉得这么做又是值得的。

虽然编写测试花上了一些时间，但大部分情况下最终还是节省了时间，似乎不用再为每一次上线所祈祷，那些不起眼的的测试代码，仿佛安静却坚定地守护着那些美好的事情。