到底是重构，还是重写？

Hi，我是阿昌，今天学习记录的是关于到底是重构，还是重写？的内容。

到底是重构，还是重写？这是一个困扰着很多团队的问题。

重构吧，遗留系统积重难返，重构之路遥遥无期，三年、五年时间，可能也只是刚开了个头，还不如重写。

但重写就真的比重构好吗？遗留系统中最难获取的就是业务知识。

当问起一块业务时，得到的回答往往是：“没有文档”、“没人知道”或者“只能看代码”……没有业务，或者说没有需求，怎么可能构建出来一个新的系统呢？那到底应该如何应对呢？除了重构和重写，还有没有其他方式呢？

一、遗留系统现代化的五种策略

Gartner 在 19 年曾经有一篇报道，提出了遗留系统现代化的七种方案。把这七种方案做了整合，把它们整理成后面这五种策略。

它们各有各的特点，而且分别对应不同场景，要根据项目自身情况选择不同的策略或组合。

然后，再应用后面要讲的模式来落地。

1、Encapsulate

第一种策略是 Encapsulate，也就是将遗留系统中的数据或者功能封装成 API，供外部调用。

在为什么要对遗留系统进行现代化？里提到过，遗留系统中蕴含着丰富的数据资产，但是因为技术和工具落后，导致它难以与新系统集成，这些数据被封印在遗漏系统中，成了数据孤岛。

比如早期的银行或民航软件，很多都是部署在大型机上的。企业非常希望开发手机 App，这样才能更好地为客户服务，但却很难访问到主机上的这些数据。同样地，遗留系统中还有一些功能十分重要，其他外部系统需要这些能力来构建业务。

比如一些公文流转的工作流，可能构建在基于 Lotus Notes 的办公系统中，但如果企业想要开发移动办公 App，并在 App 中复用这套工作流，也是困难重重。

问题虽然棘手，但事到临头，工程师们总要想办法应对。结合刚才说的情况，可以封装这些数据和功能，形成 API，供这些移动 App 或其他外部系统使用。

如果遗留系统本身就是基于 Web 的，可以在 Web 系统上直接构建 API；如果不是，可以选择构建一个全新的 Web API 来部署并提供服务。这样做的好处是，以较低的成本和风险，尽可能满足外部系统的需求。无需对遗留系统做较大的修改，只是增加一些 API 而已。

遗留系统本身不会被优化，但它可以通过这些 API 对外提供能力。还有一种情况，也建议你使用封装的策略，那就是当有一个第三方系统，希望扩展它的功能，但只能访问它的数据库，却无法修改代码的时候。这时有些团队采用的方式就是直接连它的数据库，并在已有的系统中基于这些数据构建新的功能。

不建议你这么做，直接连数据库固然简单，但由于可以访问它所有的表和列，距离混乱也就剩一步之遥了。

建议基于这个第三方系统的数据库构建一个 Web API，来向其他的系统提供你想提供的数据和功能，而不是暴露全部的数据。

2、Replatform

第二种策略是 Replatform，也就是替换运行时平台。

这种策略不需要对代码大动干戈，只需要改动很小一部分。到了新的平台后，软件的功能和特性仍然保持不变。

比如，很多银行或民航软件还是基于 COBOL 的主机系统，把它们从大型机上迁移到 Linux 或 Windows 环境，就会甩掉昂贵的主机成本。

再比如，早年间开始构建的系统，由于种种原因，很多是基于商业软件的，想升级，就要花一大笔预算。很多企业为了节省这部分开支，会尽量避免升级，也导致系统最终变成了遗留系统。

可以通过 Replatform 策略来解除对商业软件的依赖，例如用 Tomcat 来替换 WebLogic。或者像.NET 这种技术栈，也十分有必要从.NET Framework 迁移到.NET Core 或者.NET 5。而 Python 从 2 升级到 3、JDK 的大版本升级等等，也都属于 Replatform。

在使用 Replatform 时，只需要对代码做少量更改，以适配新的平台。这样，只通过较小的成本就可以降低基础设施的成本，并提高性能。
还有一种迁移认为也可以看做是 Replatform，虽然它并不是替换运行时平台。

那就是迁移代码版本管理工具。比如你把代码从 SVN 迁移到 Git 中，不需要修改任何功能代码，但却可以享受新的代码管理平台带来的好处。

3、Rehost

第三种策略是 Rehost，也就是将应用程序或组件部署到其他基础设施中，如虚拟主机、容器或云。

这种策略完全不需要修改代码，而只需要迁移部署的环境，甚至都不需要重新编译，因此这种迁移方法也有个很形象的别名，叫做“lift and shift”，就是原封不动地拎起来，转移到别的地方去。

举个例子来说明，如果你的公司有一个 SAP 的 ERP 系统，可以将它从本地的数据中心迁移到 AWS 或 GCP 中。Rehost 可以让你在完全不修改已有系统的情况下，快速上云，体验云环境带来的弹性、安全性和高性能，并且迁移过程也能做到很平滑。

然而由于没有任何适配，也就无法充分利用云原生的优势，因此还需要对系统内部的代码和架构做进一步调整，比如将单体架构拆分为可以独立运维的微服务。

4、Refactor/Rearchitect

第四种策略是 Refactor 和 Rearchitect，它们是指在不改变系统外部行为的前提下，对代码或架构进行调整、优化，以偿还拖欠已久的技术债务、改善非功能需求、提升系统健康度。

Refactor 主要是指代码级别的重构，比如你可能用 Sonar 等代码扫描工具，扫描出了很多代码坏味道、缺陷或隐患，修复这些问题的过程就属于 Refactor。这和我们平时说的代码重构基本上是一个意思。
Rearchitect 是指架构级别的重构，它包含两层意思。
- 第一层比较好理解，就是指从单体架构到分布式架构的这种架构调整。
- 第二层是指不改变部署单元之间的关系，而是对单个或多个部署单元内部进行模块化或分层重构。由于这种模块化和分层也会涉及很多代码的调整，所以这种 Rearchitect 往往会和 Refactor 同时进行。

5、Rebuild/Replace

第五种策略是 Rebuild 和 Replace，都是指对遗留系统进行替换。它们两个替换的范围和程度不同。

Rebuild 可能是对应用程序的某个组件或某个服务的重新设计或重写，但会保留其原有的业务范围和业务规则。
Replace 是指彻底淘汰应用程序的所有组件，去构建或购买新的软件，同时会考虑添加新的业务需求或移除某些旧的业务需求。

在为什么要对遗留系统进行现代化？提到过，遗留系统中的业务知识是严重缺失的，不仅没有遗留下来的文档供我们查阅，也没有任何一个人能说清楚全部的业务细节。

在这样的基础上实施 Rebuild 或 Replace，风险和成本都是相当高的，但相对来说，收益也是最高的，一旦替换成功，就可以彻底摆脱原来的遗留系统了。

下图是对上面五种策略的一个总结，你可以从中看出它们的收益、风险和成本（用面积表示）：

在这里插入图片描述

6、其他策略

除了上面的几种策略以外，对于遗留系统来说还有一些应对策略可以选择。

不过由于不涉及到代码、架构或运行环境的变更，没有把它们作为遗留系统现代化的策略。

其中一种是 Retain，即保持系统当前的状态不做任何修改或更新。

对于尚可满足使用的遗留系统来说，这无疑是风险和成本最低的策略。

在以假设驱动为指引说过，使用人数不多、需求很少、只需要一两个人维护的遗留系统，就可以使用这种策略。

还有一种是 Retire，就是评估完工作量、使用情况和业务价值之后，选择完全停止使用的一种策略。有的时候系统已经没有什么人用了，或者类似的功能在其他系统中可以替代，就可以选择让这个旧系统彻底退休了。

二、你应该选择什么样的策略？

面对如此眼花缭乱的策略，恐怕更加无所适从了吧？

到底是 Replatform 还是 Rehost？是 Refactor 还是 Rebuild？是 Rearchitect 还是 Replace？

其实，还是要依据目标和系统现状做判断。先看最终目标，企业遗留系统现代化的四个目标，即业务敏捷、运营效率、客户洞见、系统韧性与弹性。

对于业务敏捷来说，Replatform 和 Rehost 通过替换运行时环境和上云可以提升部署频率，特别是 Rehost 可以显著提升系统在遇到故障时的恢复时间；

Refactor/Rearchitect 通过改善代码和架构的质量，可以缩短需求交付周期，减少线上问题数量；

Rebuild/Replace 由于在某种程度上做了替换，也可以大幅度提升业务的响应力和交付质量。

对于运营效率来说，Refactor/Rearchitect 和 Rebuild/Replace 都可以提升价值流效率。而要想改善客户洞见，最有效的方式还是 Rebuild/Replace。

在系统韧性与弹性方面，Rehost 显然是不二之选。我们要结合当前遗留系统的现状和想要提升的目标，做综合判断，对于不同的模块，也可以选择不同的策略组合，来实现一个完整的业务目标。比如遗留系统中的有些业务，需要提供 7x24 小时的高可用服务，类似银行转账、保险报案等模块。但这些模块很有可能还位于单体的“大泥球”中，和其他模块有着剪不断、理还乱的关系。为了支撑这些需求，可以先采用 Rearchitect 的模块化策略，结解耦模块之间的关系；

然后再用 Rearchitect 的服务化策略，将这些模块拆分成独立的服务；最后再用 Rehost 策略将这些服务部署到云上，以提升系统的可用性。

当然，如果由于系统耦合严重，模块化改造很难实施，也可以选择用 Rebuild 策略重写这一部分模块。再比如一个部署在 WAS v6 上的 Java Web 遗留系统，由于只支持 Java EE 1.4，技术栈严重落后，已经很难在市场上招到人来维护了。

这时，可以先选择 Replatform 策略，将 WAS 替换为较新版本的 Tomcat，以摆脱昂贵的商业软件；

然后再次使用 Replatform 升级 Java 的版本，包括所依赖的第三方工具，这样就完成了整个技术栈的升级。

如果企业认为当前遗留系统已经彻底无法满足业务的需要，且具备足够的资源来构建新的系统，就可以使用 Replace 策略来彻底替换旧系统。

同时，在遗留系统并不是很大，但重要性又相对很高的情况下，也可以考虑 Rebuild/Replace。

这里一直没有提 Encapsulate 这种策略，是因为它有自己独特的适用场景，也就是与其他外部系统集成的时候。