架构设计之系统重构

Posted 2022-09-14 技术能量站

1、前言

1.1 现在所写的每一行代码，都是未来的遗留系统

有些系统虽然刚开发不久，但你工作起来还是有各种不爽，比如：

• 代码质量一言难尽，改个需求或做维护经常加班，让你恨不得推翻重写；
• 架构混乱，模块之间职责不明，一个需求需要修改四五个服务；
• CI/CD 运转不畅，经常莫名其妙地挂掉，每次升级、上线都一拖再拖；
• 团队结构不稳定，人员变动频繁；大家都在拼命开发新需求，没人关心技术债；

如果以上问题你都自信满满，那我就要拿出杀手锏了。

你的代码有测试吗？你平时开发新需求时会写测试吗？你在修改 bug 时会补测试吗？经过这样的灵魂三问，你还有自信坚持说自己的系统不是遗留系统吗？

《修改代码的艺术》一书的作者 Michael Feathers 说过，“没有测试的代码都是遗留代码”。在我们越来越强调软件系统质量内建的今天，仍然有很多系统甚至很多刚刚开发的新系统，由于各种原因不写测试。有的说工期太紧，没时间写；有的说系统原来就没测试，我新加的这么几行代码没必要写。其实每种借口都禁不起推敲，都是在为自己不会写测试来打马虎眼。

软件系统本身就是一个不断熵增的过程，代码逐渐从有序变得无序。如果没有测试的严防死守，熵增的过程就会慢慢加快，代码很快就会变得混乱不堪。

1.2 为什么要对遗留系统进行现代化

不知道你是否跟曾经的我一样，身处一个遗留系统的漩涡之中，每天为毫无头绪的代码和混乱不堪的架构发愁。一个新的需求来了，都不知道从哪儿开始改起，即便看似简单的需求都要很久才能上线。

我想我们是不是得先明确一下，到底什么样的系统才能称之为遗留系统呢？它存在哪些问题，复杂在哪里？

关于遗留系统的误区

请你先思考这样一个问题：假如一个系统七八年了，它是不是个遗留系统？

系统的时间长等同于就是遗留系统，这是很多人的一个误区。虽然大多数遗留系统确实是存在的时间很长，但并不等于时间长的都是遗留系统。

遗留系统的特点

• 首先就是代码质量差。我们说优秀的代码都是相似的，而糟糕的代码则各有各的糟糕之处。
  我曾治理过一个有着 6000 行代码的单个方法，至今印象深刻。其中包含 6 个大的 if/else 块，每个块中大概有 1000 行左右的代码，这 6 个 1000 行的代码只有十分细小的差别。显然是开发人员为了偷懒，不敢在原代码上改动，于是复制出来加入自己的逻辑。他倒是图省事儿了，但是对于维护人员来说简直是噩梦。正所谓编码一时爽，维护火葬场。
• 其次是架构，这也是遗留系统的重灾区。
  一个软件架构的作用，是要解决多个业务模块之间的协作问题。但如果架构混乱，多个模块之间往复调用，数据也是随意访问，模块之间的边界就会变得模糊，数据所有权也会变得含糊。试想一下，如果一张表被 10 个模块访问，谁能说得清这张表到底属于哪个模块呢？

下图是一家银行的核心应用系统模块之间的交互图，我想没有一个人愿意工作在这样的系统上吧？

综合来看，代码和架构的质量差会导致遗留系统的维护成本相当高昂。这里的维护就包括：新需求的添加、线上 Bug 的修改，以及为了维护系统运行所需投入的软硬件和人力等。

1.3 什么是遗留系统

说了这么多，我们似乎已经有了一个很具体的关于遗留系统的画像了，参考如下：

那是不是可以进一步抽象一下概念了呢？

在计算机领域，遗留系统是一种使用旧的方法和技术的、过时的，却仍旧在使用的计算机系统。

1.4 遗留系统重构的价值

原因有很多。首先，可能是成本太高了，企业不愿意投入资源去改进；也可能是因为积重难返，根本改不动。而遗留系统往往都是企业的核心业务系统，支撑着整个企业的业务运营，这样的系统就算问题再多，也是不可替代的。

其次，遗留系统蕴含了大量的数据资产。遗留系统中的数据虽然很难与其他系统进行集成，但这部分数据的价值又是巨大的。企业的新系统常常不得不在这些数据的基础之上去构建，其他系统要想获得遗留系统中的数据，就必须对遗留系统进行修改，所以很多团队为了避免修改代码就会去寻求数据库层面的复制和同步，这也是一个选择。

另外，遗留系统中还藏匿着丰富的业务知识。由于业务人员长期使用并且养成了习惯，很多软件系统已经与业务融为一体，很难区分哪些是真正的业务，哪些是系统的设计。而由于系统历时太久，已经失去了能够正确描述系统现状的文档，所以到最后只有遗留系统的代码才能够准确表达系统的行为，以及与之对应的业务知识。

系统改造，有可为有可不为，而对于遗留系统来说，结合其现代化价值，看上去更像是一种不得不为。所谓现代化，其实就是从代码、架构、DevOps 和团队结构这四个方面来对遗留系统进行治理。

既然不能对遗留系统听之任之，我们就要下决心迎难而上，掌握主动权，否则当问题真正出现时就为时已晚了。

2、遗留系统四化建设