【CSDN 编者按】对于遗留系统，我们必须记住，修复旧物件远比扔掉换新的更划算、更方便。

原文链接：https://stratoflow.com/legacy-software-systems/

未经允许，禁止转载

人们经常拿软件开发人员和建筑师做类比，因为他们的工作与土木工程师有点类似。他们使用多种工具和技术来构建软件，就像建筑师建造高楼大厦一样。

然而，现实往往并没有这么简单。

有时，软件开发人员需要修复或改进老系统，因此开发人员需要时不时地站在机械的角度考虑问题。

在本文中，我们来探讨一下软件开发人员如何处理遗留软件。这些系统在如今的软件架构中当真毫无用处吗？程序员在改进遗留系统时需要优先考虑什么？

汽车在连续运转十年或行驶里程数超过几万之后，就会出现一些问题。毕竟，每个机械部件都有一定的耐用限制。

但这是否意味着这样的车辆必须报废？完全不会。

你需要的是一位经验丰富的机械师，更换最脆弱的部件，比如同步带或刹车片，之后车辆再行驶几万公里都不是问题。

软件开发在这方面也很类似。遗留软件就像一辆二手车，可能有一些问题，需要一些重构，但一般仍然能正常工作。你需要的是一位优秀的“机械师”来维护，并修复所有最脆弱的部分。

从技术的角度来看，我们可以认为遗留软件是一种正在生产中运行的软件架构，但有些部分没有持续更新或支持。我们可以将遗留系统分为三大类：

具有不受支持的功能或新驱动程序不兼容的旧系统；

不符合软件开发最新标准的软件；

无法接收安全补丁的软件系统。

Stratoflow 首席技术官 Arkadiusz Drysch 如此定义遗留系统：

“基本上任何部署到生产的系统都可以被视为遗留系统，因为这些系统需要不断维护。软件开发不存在一劳永逸的架构。”

由于替换的难度或成本过高，或者仅仅是出于方便使用的目的，遗留软件仍在使用。然而，遗留软件常常因为老化和缺乏支持而引发各种问题，这就需要重构和重新设计系统的某些部分。

IT 系统一旦投入生产，通常会持续运转数年，但与此同时，技术会以极快的速度发展。这就是为什么当旧的软件架构无法获得支持或更新时，各个公司往往会不知所措，其实这个时候需要进行更彻底的维护工作。以下是大多数遗留系统在运行多年后仍在使用的四个原因：

这些系统仍在为企业提供关键功能；

公司缺乏资源来改进现有的软件架构或改为新系统；

组织缺乏必要的 IT 技能和知识来迁移遗留系统或进行彻底的重构；

公司没有技术规范来创建与遗留系统有相同功能的新系统。

过时的软件架构最常出现的地方往往是公共部门。

戴尔最近的一项研究表明，在美国、德国、英国和日本，大约 70% 的政府机构某些方面使用的都是过时的软件。

此外，接受调查的公共部门代表中有一半表示，他们的遗留操作系统已经超出了使用寿命。更令人惊讶的是，在全世界的联邦政府中，最流行的编程语言竟然是古老的 COBOL。

奇怪的是，一些公共部门组织还存在与这些编程语言和技术一样古老的硬件。

专门从事从损坏的硬件中抢救数据的公司不得不保存一些30年之久的关键设备，例如硬盘驱动器。为什么？你可能永远不知道什么时候会冒出一个核电站仍在运行如此古老的硬件。

银行业也能看到一些旧的计算机系统和软件。

据英国《金融时报》报道，许多知名金融公司仍在使用基于 COBOL 的软件架构，目前缺乏拥有这种古老的语言编程经验的开发人员。

为什么这些组织使用这种过时的编程语言？难道金融部门不应该关注高性能计算吗？

这些关键的遗留系统通常负责这些组织的核心业务流程，涉及大笔资金，并且是全天候终年无休持续运转。许多管理人员将升级遗留软件架构视为不必要的风险。

你会惊讶地发现许多零售、电子商务和制造公司也在使用遗留系统。这很奇怪，因为直觉告诉我们，在当今竞争十分激烈的市场中，紧跟最新的技术趋势是绝对必要的。

那么问题出在哪里呢？

这是因为对于许多电子商务公司而言，盈利能力和销售数据是重中之重。在这些公司中，很大一部分管理人员只关心对 KPI 产生影响的工具和解决方案。由于软件架构对盈利能力没有直接影响，因此往往会被一拖再拖。

关于遗留系统流传着许多神话。

这些神话是真的吗？遗留系统只会让人头疼的传闻真的有道理吗？

下面，我们来打破这些神话，看看互联网上流传的关于遗留软件常见的三种说法。

IT市场绝对不是统一的。对于遗留系统，这意味着它们使用的某些组件的过时速度更快，很快就不受支持。

在某些情况下，联系支持团队或客户经理解决一些问题不会有什么问题。但在有些情况下，系统的核心部分必须经常更新，以使其符合最新的安全标准。

就像汽车修理工可能会遇到某些车辆的零件已不再生产，软件开发人员也会遇到遗留应用程序的安全措施和某些库已过时的问题。

一辆汽车即便使用了十年，运送货物或载人仍然不成问题，只不过看起来缺乏新颖时髦的特征。

遗留系统也与之类似，虽然存在一些风险，但这并不意味着它们完全没有用处。许多时候，人们仍然坚持使用遗留软件，因为这是执行业务流程最方便的选择。

简而言之，时间不会影响系统的核心功能。

就像二手车一样，只要维护得当，遗留软件也能正常运行。

开发人员可以甄别哪些部分、工具和功能缺乏支持或很快就会失去支持，逐步实现遗留系统的现代化，并逐步更新它们。虽然架构没有太多创新，但不影响正常工作。

为什么遗留系统会成为问题？

当然，如果老化的软件架构不会引发任何问题，开发人员和产品经理就不会探讨或重新设计。毕竟，破坏遗留代码的潜在风险是存在的。

以下是遗留系统引发的三个主要问题。

正如本文开头 Arek 所说，所有的软件系统都需要维护。话虽如此，重新设计和重构遗留应用程序通常都需要耗费更多资源，无论是在时间方面还是金钱方面。

更重要的是，随着软件解决方案逐步过时，供应商提供的支持也会减少。这意味着，这些公司为不再属于其主要产品的数据库、工具和库提供支持，可能会收取额外的费用。在有些情况下，软件现代化比从头构建的难度还要大，因为这需要人们不再使用的领域的 IT 专业知识。

许多库和数据库供应商在产品和工具发布几年后，就会停止提供安全更新。以这些库为基础的遗留系统更容易受到安全漏洞和危险数据丢失的影响，这也不足为奇。

对于一些小型软件应用程序来说，这应该不是什么大问题，但如果是存储和管理几十万用户私人数据的软件架构来说，这个问题不容忽视。

随着岁月的流逝，如果某个公司坚持使用同一个软件架构，那么就可能面临寻找掌握了这些过时技术的软件专家的难题。

技术学校和开发人员需要适应不断变化的技术环境。如今已很少有人熟悉 COBOL、Fortran 或 Deplhi 之类的语言，而在二十年前它们可是企业级软件架构的支柱。

通过以上讨论，我们明白即使遗留软件有时确实会出现问题，但对组织而言仍然有很大贡献，而且在许多情况下，新系统并不是必需的。下面，我们来介绍关于如何处理遗留软件系统的三个技巧。

由于对于遗留系统来说，最大的问题是缺乏对某些组件的支持，因此开发人员应该针对应用程序每个部分的更新进行风险分析。

开发团队应该从下面这几个角度思考：这些系统能够在当前版本上运行多长时间？系统的关键组件和库何时会收到制造商的更新？

然后，在制定工作计划时，应该将整个系统中风险最高的部分当成维护工作的头等大事。

我们了解到遗留系统仍然能够完成自己的任务。话虽如此，我们应该定期重构，并寻找改进的机会。

重要的一点是，遗留代码的重构过程应该是完整的。

比如说，开发人员决定重构负责数据库访问的代码库，但只完成了 90%。这样做最终会导致10次连接到数据库，有9次使用的是改进后的方法，但还有1次使用的是旧版本，速度较慢。这样的行为会极大地增加项目的复杂性，并损害用户体验。

因此，一般经验法则应该是，在改进遗留系统的过程中，绝对不可以半途而废。

无论技术和编程语言如何，所有开发人员都应该积极学习的一个好习惯是，维护整个软件开发项目的文档。

在使用遗留系统时，这种做法尤为重要，所有处理过时软件架构的开发人员都应该牢记这一点。

这样做的主要原因是，当团队成员变动时，你需要清楚地记录代码库中发生的一切。面对遗留系统，我们都知道很少有开发人员熟悉这些系统中使用的技术。所以如果最后一个熟悉情况的开发人员离职，而且没有任何文档，那么这个系统基本就完蛋了，几乎一切都需要从头重写。

维护遗留系统是一件苦差事，很少有人喜欢。

毕竟，这份工作需要浏览陈年的旧文档，还需要与如今已几乎没有人使用的解决方案和编程语言打交道。

尽管如此，遗留系统就像一辆多年的旧车，仍然能正常行驶，运货载人的能力不输于新车。只需要得到一些正当的维护，它就能坚持服务客户。我们必须记住，修复旧物件远比扔掉换新的更划算、更方便。