【论文精读】当代软件现代化：战略、动力与研究机遇

在当今的商业环境中，几乎每家公司都依赖于软件系统。然而，许多系统并非新兴的、时髦的技术，而是我们常说的“遗留系统”或“祖传代码”。这些系统虽然承载着多年的业务知识和核心价值，但其维护成本却高得惊人。

为了揭示软件现代化的真实面貌，我们进行了一项系统性的研究，全面综述了过去十年间发表的 126 篇相关学术论文。这项分析的目的，是拨开行业流行语的迷雾，找到那些被实践和数据反复验证的真知灼见。

Wesley K. G. Assunção, Luciano Marchezan, Lawrence Arkoh, Alexander Egyed, and Rudolf Ramler. 2025. Contemporary Software Modernization: Strategies, Driving Forces, and Research Opportunities. ACM Trans. Softw. Eng. Methodol. 34, 5, Article 142 (June 2025), 35 pages. https://doi.org/10.1145/3708527

背景

一个普遍的误区是，只要是遗留系统，就必须进行现代化改造。但研究结果明确指出：现代化并非总是正确的选择。
在现有文献中，我们可以看到将传统系统向现代系统转型的三种方式：

• “大爆炸式”改革，即直接用现代系统替换传统系统；
  
• 渐进式现代化，逐步用现代组件替换传统系统的部分模块；
  
• 共存模式，让传统与现代组件在同一系统中共存运作。
  

为了做出明智决策，研究人员在现有经典模型的基础上，提出了一个扩展版的“投资组合分析象限”（Portfolio Analysis Quadrant）决策框架。该框架建议根据系统的​技术质量 (Technical Quality)​、商业价值 (Business Value) 以及新增的创新潜力 (Innovation) 这三个维度，来决定其未来走向，如图1所示。

这会产生五种可能的结果：

• ​替换​：对于商业价值和技术质量都低的系统，最明智的选择是放弃，并用现成的商业解决方案取而代之。
  
• ​维护​：对于技术质量高但商业价值低的系统，推荐的策略是进行常规维护，保持其正常运行即可。投入巨资进行现代化改造很可能得不偿失。
  
• ​演进​：对于技术质量和商业价值双高的系统，应通过常规的软件演进（如添加新功能）来持续提升其价值。
  
• ​重构​：对于商业价值高但技术质量差（即技术债严重）的系统，应进行重构，以改善其内部质量，同时保留其核心商业价值。
  
• ​迁移​：当一个具有高商业价值的系统需要与新兴技术结合以驱动创新时（例如，数字化转型），无论其技术质量如何，都应考虑进行迁移。
  

这一发现的核心在于​战略定力​。在砸钱启动现代化项目之前，企业必须冷静评估系统的真实成色。对于那些运转良好但已非业务核心的系统，“什么都不做”可能反而是避免资源浪费的最佳策略。
结果与分析

表 2 列举了研究中归纳出的 8 种现代化策略，这些策略已被应用于软件工程的多个领域，例如系统云迁移、架构优化、编程语言转型、复用优化、新型硬件集成、自动化应用、数据库升级以及数字化转型。

人们通常认为，软件现代化的主要目的是为了偿还“技术债”，修复过时的代码。然而，对 126 项研究中提及的 14 个驱动力的分析显示，这一假设并不完全正确。关于驱动因素（详见表 3），研究人员将这些驱动力归纳为三大类：​运营 (Operational)​、技术 (Technical)和 ​组织 (Organizational)​。令人惊讶的是，最主要的驱动力来自运营层面，而非技术层面。被提及次数最多的驱动力（在 62 项研究中出现）是​降低运营成本 (reducing operational costs)*。这意味着，大多数现代化项目的根本动机是财务上的。企业希望通过现代化来减少昂贵的维护费用、硬件成本和专业人才招聘的困难。

既然现代化的首要驱动力是商业和财务目标，那么阻碍企业实现这些目标的最大技术障碍又是什么呢？出人意料的是，研究表明问题并不在于代码本身。表 4 则呈现了本次分析的研究样本中所发现的 16 项挑战。在所有被提及的挑战中，最普遍的一个是​缺乏工具支持 (lack of tooling support)​，在 126 项研究中有 45 篇论文都提到了这一点。这表明，行业中存在一个根本性的差距：工程师们迫切需要更先进、更自动化的工具来辅助代码分析、迁移和重构工作，但现实中这类工具却严重不足。

接下来，我们将详细拆解这 8 种策略，探讨它们背后的动因、面临的挑战以及未来的研究机遇。
云端化 (Cloudification)

云端化是目前应用最广泛的系统现代化策略，相关研究多达 41 项。这一结果其实在意料之中，毕竟当下各类云服务提供商的普及度本就很高。
基于该策略下的大量原始研究资料，我们将其划分为三个细分方向：

• 无特定架构约束的系统上云迁移：不依托任何既定的架构风格，直接完成系统向云端的迁移部署；
  
• 遗留系统向面向服务架构（SOA）的转型：把传统老旧系统重构为符合 SOA 架构理念的系统；
  
• 单体系统向微服务架构的迁移：将庞大的单体系统拆解为轻量、独立的微服务模块。
  

无特定架构约束的系统上云迁移

这一策略主要指将本地运行的遗留系统整体“搬家”到云基础设施。过程包括迁移应用程序、数据和安全组件。其特点是​不动架构​，单体系统上云后依然是单体。
驱动因素

最直接的动力是解决可扩展性问题。例如，有研究提到一个实时地理社交应用，因为数据量激增和搜索变复杂，本地撑不住了，必须上云。另一大动力是​成本​。本地机房维护贵、人手重，而云服务按需付费，管理省心。此外，迁移到 FaaS（功能即服务）模式还能降低系统复杂度，提升可测试性。
研究机遇

• ​新旧系统共存​：目前研究多关注“大爆炸”或“渐进式”替换，很少讨论如何构建一个“混合环境”，让新旧系统在很长一段时间内协同工作，特别是解决功能缺失和数据不兼容的问题。
  
• ​迁移流程标准化​：如何选择云平台？如何评估迁移后的成本与质量？业界需要更通用的决策模型。
  
• ​性能预测​：在 FaaS 场景下，如何通过预测函数调用来预热容器，解决“冷启动”卡顿，是一个热门方向。
  
• ​工具链缺失​：目前缺乏能够生成架构视图、追踪决策流程的云迁移规划工具。
  

遗留系统向面向服务架构（SOA）的转型

核心目标是把“铁板一块”的系统拆成模块化、松耦合的服务。
驱动因素

很多用 COBOL 写的老系统面临三大难：运行贵、招人难、工具少。转向 SOA 不仅能降低维护成本，还能让架构更易懂，甚至挖掘出新的商业机会（服务对外开放）。
研究机遇

• ​服务识别难题​：在代码耦合严重的“面条代码”中，现有的聚类算法往往很难精准切分出独立服务。我们需要更智能的服务识别技术。
  
• ​反模式检测​：为了求快，很多自动生成接口的工具会引入“代码怪味”或反模式（如数据模型封闭）。我们需要工具来自动检测和修正这些问题。
  

单体系统向微服务架构的迁移

这是 SOA 的进阶版，将系统拆得更细、更独立。
驱动因素

两大核心动力：一是​解决扩展瓶颈​，二是配合 DevOps 实现快速发布。微服务允许对特定模块进行独立扩容，能显著提升业务敏捷性。
研究机遇

• ​拆分技术升级​：怎么把单体拆成微服务？这是最难的。除了静态分析，现在有研究开始尝试用机器学习、图神经网络来辅助识别微服务边界。
  
• ​评估指标​：我们需要新的指标来量化拆分的效果（比如复用度如何？），以便在动手前做好规划。
  
• ​可视化与重配置​：技术和业务人员之间往往存在沟通壁垒，需要开发能直观展示微服务架构、并支持动态调整配置的工具。
  

架构重构

软件用了几十年，功能不断堆叠，架构往往已经变得难以理解。对于高商业价值的系统，通过重构来改善内部质量是必经之路。
例如，系统通常在空间维度上不断扩展功能，在时间维度上持续更新功能，这使得对其理解变得困难。针对这种情况，采用重构策略是提升遗留系统内部质量以应对现代化改造的有效方法。

驱动因素

重构通常是为了解决具体痛点：数据结构混乱导致的不一致、业务逻辑重复导致难以维护、模块耦合过重导致无法复用。此外，引入多租户模式（SaaS 化）或改为反应式编程以提升性能，也是重构的重要动因。
研究方向

• ​架构恢复技术​：先得搞清楚现在的架构长什么样。未来可以探索利用无监督学习或扎根理论，从复杂的遗留代码中“考古”还原出架构图。
  
• ​正确性验证​：重构不能把系统改坏了。如何自动生成单元测试来验证重构后的代码，以及确保重构不降低性能，是关键问题。
  
• ​大模型辅助​：利用 LLM（大语言模型）来理解代码、检测代码异味（Code Smell）并辅助重构，是极具潜力的前沿方向。
  

编程语言转型

简单说，就是把代码从“死语言”翻译成“活语言”。比如从 COBOL 转到 Java/C#，或者 VB 转 Python。
驱动因素

最根本的原因是​人才断层​（没人会写 COBOL 了）和​技术生态​（旧语言缺乏新库支持）。例如，AI 时代，金融业纷纷把 Visual Basic 转成 Python。这不仅是为了好维护，更是为了能用上新的技术栈。
研究方向

• ​性能评估​：翻译后的代码跑得快吗？有案例显示重构后性能反而下降。未来需要更多针对特定框架（如 Angular）迁移后的性能评估研究。
  
• ​成本效益分析​：别拍脑袋决定。需要模型来量化分析，转语言到底划不划算？要把数据库依赖等复杂因素考虑进去。
  
• ​AI 翻译工具​：现在的工具很多只做语法翻译。未来需要能微调的大模型，它不仅能翻译代码，还能理解业务规格，并自动生成测试用例。
  

复用优化

这一策略主要关注软件产品线 (SPL) 工程。简单说，就是别再到处“复制粘贴”代码了，而是建立一套通用的“底座”或工厂模式，系统地生产软件。
驱动因素

“复制粘贴”式开发虽然初期快，但后期维护是噩梦——改一个 Bug 要改十个地方。引入 SPL 旨在提取通用功能（如安全模块），减少重复开发，缩短上市时间。
研究方向

• ​经济账怎么算​：搞产品线工程，初期投入很大。需要建立模型来预测收益，告诉老板这笔钱花得值不值。
  
• ​业务驱动​：如何确保提取的通用模块真的符合市场需求？需要将业务约束纳入建模。
  
• ​特征提取工具​：目前缺乏好用的工具来从现有代码中自动提取“产品线特征”，这导致很多依赖关系理不清楚。
  

新型硬件集成适配

硬件在变（多核 CPU、AI 芯片、非易失性存储），软件得跟上。
驱动因素

为了突破“内存墙”瓶颈，计算内存架构 (CIM) 等新技术应运而生。遗留系统必须重写或调整，才能利用这些新硬件的性能。
研究方向

• ​权衡分析​：针对新硬件优化往往是牵一发而动全身。需要程序化的验证方法，确保为了并行化而修改代码后，逻辑依然正确。
  
• ​编译器与转换工具​：新硬件（如 CIM）的编程范式很复杂（涉及矩阵运算等）。我们需要能自动将老代码转换为适配新硬件格式的编译器，减少人工重写的痛苦。
  

自动化应用

引入 DevOps 和自动化脚本，把人工运维变成自动化流程。
驱动因素

核心就是快和​稳​。自动化能显著缩短发布周期，降低运营成本。
研究方向

• ​自主计算​：让软件具备“自我管理”和“自愈”能力。
  
• ​重构自动化​：开发能集成在 CI/CD 流水线中的重构工具，让代码质量管理常态化。
  

数据库现代化

从关系型数据库转 NoSQL，或者整合多个数据源。这对确保业务运营高效持续至关重要，尤其在企业合并或收购时。
驱动因素

主要是为了解决数据孤岛问题，特别是在企业并购时，系统间的数据互通至关重要。
研究方向

数据库间数据迁移

• ​跨库迁移​：从 SQL 到 NoSQL 的数据迁移不仅仅是导数据，还涉及数据模型的转换。需要更安全、高效的迁移方案。
  
• ​互操作性平台​：在工业 4.0 时代，建立一个能让所有系统无缝交换数据的底层数据库设施是当务之急。
  

数字化转型

这是一个宏大的命题，通常指利用数字技术彻底重塑业务流程，比如工业 4.0。
驱动因素

为了在万物互联的时代保持竞争力。比如让老旧的工厂设备也能联网，实现数据采集和互操作。
研究方向

• ​数字孪生​：利用数字孪生技术，先在虚拟世界里模拟老系统的现代化改造，测好了再动手。
  
• ​自组织系统​：开发能让工厂设备自动感知变更并重新配置的工具，实现真正的智能制造。
  

讨论

下图系统梳理了驱动力与现代化战略、现代化战略与挑战之间的关联关系，同时揭示了不同现代化战略共有的驱动力与挑战特征。

RQ1: 我们有哪些现代化手段？我们总结了 8 大策略。其中云化转型是一骑绝尘的热门选择（41 项研究），其次是架构重构和编程语言转型。
RQ2: 到底是什么在驱动企业做现代化？我们识别了 14 种驱动力。​“钱”是最关键的因素​​。降低运营成本、提升性能/可扩展性、以及系统互操作性是最常见的三大动力。这说明，技术情怀往往要让位于商业现实。
RQ3: 最大的拦路虎是什么？我们归纳了 16 个挑战。​工具匮乏是最大的痛点​。无论是云迁移、微服务拆分还是语言转换，工程师们都缺乏高效的自动化工具支持。此外，如何定义标准的现代化流程、如何建立科学的评估指标（KPI），也是未来亟待解决的研究方向。
通过对过去十年 126 篇学术论文的深度复盘，我们得以一窥软件现代化的真实图景。它远非一个单纯的代码修改问题，而是一场涉及商业目标、财务预算、工具基建和长远战略的复杂战役。对于企业而言，认清形势、选对策略、配好工具，方能在现代化的浪潮中立于不败之地。

来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！