系统设计 | 如何决定对遗留系统重构还是重写

在最近几年里，几乎没有全新的系统开发工作了，不是在修修补补就是对遗留系统进行改造，让其重新适应业务发展的需要。我参与过类似于遗留系统的改造有：

一个长期演进的大单体，人员规模增长，业务需求变得愈加复杂，我们不得不对其服务化。
一个已经运行了几十年的业务系统，无论是编程语言还是框架都不在能跟上现在的技术趋势，添加新的功能变得愈来愈复杂，相关的依赖包也没人在维护，甚至相关技术栈的开发人员都很难在市面上找到。
一个庞大系统中的一个组件，已经运行了很多年，因为某些原因（性能、安全）需要开发新的并将其替换掉。

在讨论后面的内容之前，我不知道这些是否从严格意义上来说是遗留系统，也不知道我的工作是重构或者重写。由于今天我们不得不面对一个问题，对于很难维护的系统，我们如何合理的决策，对其重构还是重写。

01 什么是遗留系统？

我找到了一些关于遗留系统的权威定义。

国际标准化组织（ISO）: ISO/IEC/IEEE 24765:2010 将遗留系统定义为“旧的方法、技术、计算机系统或应用程序，尽管有更新的技术或更高效的方法可供使用，但由于仍能满足用户需求而继续使用。”

根据IEEE，遗留系统是“依赖于过时或淘汰技术的系统，但仍对组织的运营至关重要。”

我识别到有两个关键要素：过时或者淘汰的技术，仍然需要继续使用和满足运营需要。

所以遗留系统的问题在于 “业务需求和技术过时直接的矛盾”。没有持续盈利的业务需要，也就没有改造遗留系统的意义了。所以非常有意思的是，虽然遗留系统被广大程序员避之不及，但遗留系统改造工作具有广大的市场空间。

在《重构》一书中, Martin Flower 对“重构”的理解是: 重构的对象是代码，工作在系统的内部，并不改变系统或者组件的外部行为，另外重构是一个持续的过程。

我们尝试给重写一个定义: 重写的对象往往是系统或者完整的组件，可能会导致相关接口升级或者修改，甚至在重写的过程中，会增加新的特性，或者废弃部分功能。

下面我整理了一个清单，对比这两者的差异，用于后续决策的考量：

我们的客户经常会为重构还是重写做出选择而头疼，这里尝试整理了一个参考问题清单，根据问题的结论作为决策参考。

补充问题，如何让领导对重写买单？

从上述的问题清单中，有两个启示：

技术决策背后往往会掺杂利益问题和价值判断。从业务方的角度来说，需要对比的是持续重构带来的成本和一次性投资重写的成本，这两者带来的成效哪一个更高？而对于技术人员来说，维护的便利性是优先考虑的要素，因为难以维护的项目可能会带来更多的而线上 Bug 和安全事件。
在众多考量点中，某些考量是决定性的。这些决定性的考量往往和公司业务有关，例如对于银行来说，安全和政策合规是第一要素，如果系统持续重构无法解决安全和政策合规问题，那么即使不得不加大投资，也能接受系统被重写；而对于互联网公司来说，除了安全和政策合规外，快速响应业务变更也很重要，因此对于重写更加积极。