如何更好地重构和组织后端代码

Hi，我是阿昌，今天学习记录是关于如何更好地重构和组织后端代码的内容。

如果说在气泡上下文中开发新的需求，类似于老城区旁边建设一个新城区，那么在遗留系统中开发新的需求，就类似于在老城区内部开发新的楼盘。

这就必然要涉及到拆迁的问题。拆迁终归是一个声势浩大的工程，居民要先搬到别的地方，再拆除旧的建筑，盖起新的楼宇，一番折腾之后，老居民才能搬进新家。

不过软件的好处就在于它是“软”的，不需要这么费劲儿。

可以很容易地复制、删除和添加新的代码，轻松地实现一个架构的变迁。

一、修缮者模式

绞杀植物模式适合于用新的系统和服务，替换旧的系统或旧系统中的一个模块。

在旧系统内部，也可以使用类似的思想来替换一个模块，只不过这个模块仍然位于旧系统中，而不是外部。把这种方式叫做 修缮者模式。

在这里插入图片描述

在修缮时，通过开关隔离旧系统待修缮的部分，并采用新的方式修改。

在修缮的过程中，模块仍然能通过开关对外提供完整功能。

这就好比是在老城区中修路，如果断路施工对交通的影响就太大了。

更常见的做法是修缮其中的半条路，留另外半条来维持交通。不过，这必然会造成一定的拥堵。但在软件中就好办多了，可以将道路（待修缮的模块）“复制”出来一份，以保障通行正常。等原道路修缮好之后，再删除掉复制出来的道路即可。

用修缮者模式去修复过一个性能问题。一个 API 的请求特别慢，在本地修好后，在生产环境改观不大。

推测这应该是数据分布导致的问题，本地环境的数据分布无法准确模拟生产环境。但当时的安全策略不允许访问生产数据库。

于是，接下来做调优时，并没有直接修改这个 API，而是将 API 复制了一份出来，一个用来维持老的功能，一个用来性能调优。

同时添加了一个针对这个 API 的 Filter，根据开关来决定要调用哪个 API。通过收集调优 API 中的日志，不断地优化，直到解决性能问题。

这时再清理掉旧 API、Filter 和开关。这样做的好处是，由于你无法预测修缮过程中会产生哪些问题，这种通过开关保留回退余地的方法，显然是更灵活的。

如何实现前端的增量演进和随时回退，其实也是这种修缮者模式的思想。

将所有要修改的页面复制出来一份，然后再加入开关，就可以放心地重构页面了。

在没有单元测试的情况下，通过修缮者的方式来重构的。把代码复制出来，重构完之后，通过开关在调用端切换，以完成 A/B 测试，从而实现安全地重构。

// 旧方法
public List<int[]> getThem() {
　List<int[]> list1 = new ArrayList<int[]>();
　for (int[] x : theList)
　　 if (x[0] == 4)
　　　 list1.add(x);
　return list1;
}
// 新方法
public List<Cell> getFlaggedCells()  {
  return gameBoard.stream().filter(c -> c.isFlagged()).collect(toList());
}
// 调用端
List<int[]> cells;
List<Cell> cellsRefactored;
if (toggleOff) {
  cells = getThem();
  // 其他代码
}
else {
  cellsRefactored = getFlaggedCells();
  // 其他代码
}

二、抽象分支

这种优雅的方式就是，把要重构的方法重构成一个方法对象，然后提取出一个接口，待重构的方法是接口的一个实现，重构后的方法是另一个实现。按这种方式重构之后的代码如下所示：

public interface CellsProvider {
  List<int[]> getCells();
}

public class OldCellsProvider implements CellsProvider {
  @Override
  public List<int[]> getCells() {
    List<int[]> list1 = new ArrayList<int[]>();
    for (int[] x : theList)
      if (x[0] == 4)
        list1.add(x);
    return list1;
  }
}
public class NewCellsProvider implements CellsProvider {
  @Override
  public List<int[]> getCells() {
    return gameBoard.stream().filter(c -> c.isFlagged()).map(c -> c.getArray()).collect(toList());
  }
}

在调用端，只需要通过工厂模式，来根据开关得到 CellIndexesProvider 的不同实现，其余的代码都保持不变。在通过 A/B 测试之后，再删除旧的实现和开关。

这种方法不但可以进行安全地重构，还可以用新的实现替换旧的实现，完成功能或技术的升级。把这种模式叫做抽象分支（Branch by Absctration）。

当进行大的技术改动时，通常需要花费较长的时间。比如用 MyBatis 替换 Hibernate，或用 Kafka 替换 RabbitMQ。

传统的做法是，在当前的产品代码分支上创建一个新的分支，大规模去重写。

这个分支发布之前要经历很长一段时间，直到最后全部修改完成后，才能把分支合并到产品代码分支上。

更糟糕的是，这样做合并时的代码冲突会非常严重，而且架构调整后，首次上线大概率会出问题，交付风险非常高，无法做到增量演进。

为了解决这样的问题，Martin Fowler 提出了抽象分支模式。

可以在不创建真实分支的情况下，通过技术手段，将大的重构项目分解成多个小步骤，每个小步骤都不会破坏功能，都是可以交付的，这样就可以逐步完成架构的调整。

在这里插入图片描述

它的基本步骤是这样的。先为旧实现创建一个抽象层，让旧的模块去实现这个抽象层。

注意，这里的抽象层并不一定是接口，有可能是一系列接口或抽象类。

然后，让部分调用端代码依赖这个抽象层，而不是旧的模块。

同样要注意，这个替换是逐步进行的，不是一次性全部替换掉。

等全部调用端都依赖抽象层后，开始编写新的实现，并让部分模块使用新的实现。

这个过程也是逐步进行的，一方面可以更好地验证新实现，另一方面也可以随时回退。

当全部调用端都使用新的实现后，再删除旧的实现。

有的时候你需要让新旧实现同时存在，对不同的调用端提供不同的实现，这也是很常见的情况。

由于新代码一直可以工作，因此你可以不断提交、不断交付、不断验证。

在实际工作中，抽象分支的运用还是非常广泛的。一个技术改动，在初始化 Redis 的时候，改为从配置文件中读取密码，而不是从数据库中读取密码。

对于这样一个替换，可能直接三下五除二就完成了，但领悟了抽象分支之后，发现可以用更加优雅的方式实现这个替换。一篇博客，可以当做加餐。

三、扩张与收缩模式

有的时候要修改的是接口本身（这里的接口是指方法的参数和返回值），这时候就不太容易通过抽象分支去替换了。

以前返回的是 List，而现在想打破这个接口，返回 List。

因为 List 仍然存在严重的基本类型偏执的坏味道，而且本来已经提取了 Cell 类，又通过 getArray 返回数组，简直是多此一举。

这时可以使用扩张 - 收缩（expand-contract）模式，也叫并行修改（Parallel Change）模式。它一般包含三个步骤，即扩张、迁移和收缩。

这里的扩张是指建立新的接口，它相比原来旧的代码新增了一些东西，因此叫做“扩张”；而收缩是指删除旧的接口，它比之前减少了一些东西，因此叫“收缩”。

一般来说，它会在类的内部新建一些方法，以提供新的接口（即扩张），然后再逐步让调用端使用新的接口（即迁移），当所有调用端都使用新的接口后，就删除旧的接口（即收缩）。

拿刚才这个例子来说，提取完方法对象后的代码如下所示：

public class CellsProvider {
  public List<int[]> getCells() {
    List<int[]> list1 = new ArrayList<int[]>();
    for (int[] x : theList)
      if (x[0] == 4)
        list1.add(x);
    return list1;
  }
}

可以在这个方法对象中进行扩张，新增一个方法，以提供不同的接口：

public class CellsProvider {
  public List<int[]> getCells() {
    // 旧方法
  }
  public List<Cell> getFlaggedCells() {
    return theList.stream().filter(c -> c.isFlagged()).collect(toList());
  }
}