趁热打铁
Source: Dev.to
请提供您希望翻译的完整文本（除代码块和 URL 之外），我将为您翻译成简体中文并保持原有的格式。
Source: …
让遗留系统转型变得简单、快速且安全
大型机现代化项目常因开发成本不断攀升、交付日期不断推迟而失败。这些失败源于低估了复杂性，并在未为安全、高效的变更奠定基础之前就尝试进行大规模转型。
采用正确的策略和一些优秀的工具，现代化可以变得高效、有效且安全。
提议的三阶段方法
- 重写 – 将 COBOL 转换为可移植、经过单元测试的 Java。
- 重新平台化 – 将 Java 代码从 z/OS 迁移到云端。
- 重新架构 – 重构并重新塑造，以提升可维护性并实现新功能。
通过在严格限定的迭代中依次完成这些阶段，现代化可以在保持系统稳定性的同时稳步推进，实现技能和知识的逐步转移，避免系统规模和成本不断膨胀的陷阱。
为什么现代化项目会失败
遗留系统难以维护和测试。成功的关键在于在尝试转型之前先让软件更易于变更——换句话说，“只有在铁热了才下手”。
遗留 COBOL 应用的特征
- 缺乏自动化安全网 – 没有单元测试库、CI/CD 流水线或冒烟测试套件来捕获意外后果。
- 高度耦合的单体结构 – 大多数组件是多用途的，使得隔离或抽取极其困难。
- 零容错 – 它们处理生死攸关的事务（医疗保险、社会保障、失业救济等）。
- 硬件高效设计 – 经过数十年针对 IBM 硬件的优化，几乎没有性能余量容纳低效的改动。
- 持续的监管变动 – 没有用于重大转型的“冻结期”。
当这些挑战共存时，缺乏相关经验的开发团队很容易低估改造遗留系统的难度。
现代化团队的常见误解
- 假设瀑布模型是唯一的障碍 – 认为 Scrum 可以立即采用，而不解决更深层的架构问题。
- 将遗留设计视为偶然 – 把系统架构当作“开发者当时不懂更好方案”的遗物。
- 使用考古隐喻 – 将发现过程描述为“挖掘文物”，却忽视了日常维护系统的人员的专业知识。
有才华且能力出众的工程师往往在现代技术栈上表现出色，但他们很快会陷入意想不到的约束以及与遗留系统的过度集成之中。他们的 Scrum 会议沦为仅仅展示透明度的机制，而非真正推动敏捷开发的助力。
他们拉动的每一根线似乎都可能使整件毛衣解体。每一个设定的目标或截止日期在面对后期才发现的约束时，都显得软弱或后退。
当团队在冲刺期间花时间在低层技术细节上，仅仅是为了填补演示环节时，项目经理应敲响警钟，提出关于投资回报的严肃问题。
思考实验
忘掉主机一会儿。想象你继承了一个庞大的软件系统——数百万行代码——并且在接下来的二十年里它完全由你负责。
- 第一个变更请求 到来：修改处理规则，扩展数据模型，调整审计/报告子系统。
- 你深入代码，发现一个 单块式鲁布·戈德堡机器，没有测试。
- 调整一个在许多地方出现的神秘标志会让你脊背发凉，因为你无法预测副作用。
如果你和大多数工程师一样，你的本能是 在动手之前先写测试——你知道意外的副作用可能会转移数百万救命美元。如果这与你的感受相符，下面的建议应该会显得合情合理。
关键要点
成功地现代化复杂的遗留系统 需要奠定基础，以安全地进行变革性更改。三阶段方法（Rewrite → Replatform → Rearchitect）提供了一条结构化的路径，在控制风险、范围和成本的同时实现该目标。
第1阶段 – 重写 → 可移植、已测试的 Java
目标：将 COBOL 程序转换为可移植、经过充分测试的 Java 代码。
注意：这 不是 市场上充斥的低质量 “JOBOL” 转译器。借助现代 LLM，我们可以获得更好的结果。
我们的做法
- 用 函数和接口等价 的 Java 实现替换每个 COBOL 程序。
- 引入 平台抽象层，使所有平台特定代码都位于定义良好的接口之后。
- 编写 单元测试，验证功能等价性，并作为并行生产测试的安全网。
为什么重要
| 关键收益 | 说明 |
|---|---|
| 测试覆盖率 | 单元测试覆盖率显著加快变更验证，使快速、安全的部署成为可能。 |
| 可移植性 | 抽象层使相同的代码和测试能够在任何平台（本地工作站、z/OS 或云）上运行。迁移离开主机时无需重写业务规则。 |
| 通过并行测试确保安全 | 相同的函数和接口使您能够将新的 Java 组件与旧的 COBOL 版本并行运行，在进入生产环境前捕获回归问题。 |
实用技巧
- 逐程序 重写可保持双重维护成本低，并实现快速重新集成。
- 将此指导视为 框架 而非硬性规定——根据接口边界和 LLM 驱动的生产力调整工作粒度。
- 专注于 稳定接口，在实现平台抽象的同时，可在并行测试中进行验证。
第 2 阶段 – 迁移 → 云基础设施
目标：将已测试、可移植的 Java 代码从 z/OS 迁移到云环境。
“云迁移”听起来像是最终的终点线，但它带来的权衡必须谨慎评估。
云的优势
- 按需付费 硬件资源 → 灵活的成本模型。
- 内置冗余 跨多个数据中心 → 提升灾难恢复能力。
- 独立的 CI/CD 流水线 → 更容易部署，且不会干扰主机系统的发布周期。
- 访问 庞大的市场，提供开发者生产力、分析和监控工具。
需要预见的挑战
| 挑战 | 影响 |
|---|---|
| 复杂性 | 将应用拆分到多个平台会使理解和故障排查更加困难。 |
| 延迟 | 用约 50 ms 的 API 调用取代亚毫秒级的本地调用，可能在大规模时威胁批处理周期的时序。 |
| 成本 | 新的云资源需要费用，且不会立即抵消本地支出；同时还需要具备云原生技能的工程师。 |
迁移建议
- 从小开始 – 仅迁移 规模相当大且自包含的功能组件，这些组件具有明确的数据边界。
- 评估数据本地性 – 确保组件能够容忍网络延迟带来的任何运行时性能下降。
- 限制跨平台胶水 – 最小化临时集成层；每增加一层都会带来成本、拖累和风险。
- 保持简洁 – 让现代化系统保持精简，以保留速度并降低维护开销。
Source: …
第三阶段 – 重塑 → 可维护性与新功能
目标：重构或重新架构系统以提升可维护性 或 开始交付新功能。
现在应用已经：
- 更易于更改（得益于现代化的测试）。
- 更易于部署（得益于 CI/CD 流水线）。
团队可以安全地进行更深层次的转型。
前进的两条路径
| 路径 | 适用情形 |
|---|---|
| 可维护性优先 | 在添加新功能之前，你希望继续提升可测试性、模块化以及整体代码健康。 |
| 功能优先 | 你有一批用户体验改进或业务关键功能的待办事项，现在可以安全交付。 |
为什么可行
- 重写阶段 有意避免了大幅度的重新设计，使代码库保持稳定且经过充分测试。
- 有了这层安全网，重构（例如，抽取服务、引入领域驱动设计）或 重新架构（例如，迁移到微服务）就变得低风险。
最后思考
大型机遗留应用程序是 庞大、复杂且关键任务 的。它们的功能和结构已经演变为紧密耦合的多用途组件。
在你完全了解系统并建立安全网 之前 尝试全面转型是灾难的配方——每一步都像踩到耙子一样。
“趁热打铁。”
利用三阶段方法的动能，但要有计划地推进，以测试和并行执行作为护栏。
策略建议
在尝试对系统进行根本性改造之前，先投入时间让系统更易于变更 之前。
- 重写 COBOL 为可移植、单元测试的 Java，同时保持功能和接口等价，
- 防止范围蔓延，
- 实现并行生产测试，且
- 是实现软件可塑性的最高效路径。
这一步关键的第一步——从 COBOL 转向更高效的语言——可以是：
- 最容易的步骤，如果你专注于此，或
- 如果你忽视这些遗留系统的根本挑战，则会成为持续的负担，最终决定是 沉浮。
本文未涉及的主题
- 数据现代化
- 接口现代化
- 支持 COBOL/Java 集成的软件工具（帮助您快速上手）
- 项目规划、管理和成功指标
如果有足够的兴趣，我可能会写这些主题的文章。我始终乐于与任何感兴趣的人讨论这些以及更多内容。
联系我们
如果您对这套策略感兴趣，并希望在您的具体项目中得到帮助，我很乐意协助。
- 电子邮件: sbwiley@pm.me
- LinkedIn: Sam Wiley
关于作者
Sam Wiley – 软件工程师兼 Boring Technology 倡导者，专注于大型机现代化。
- 现代化团队的首席开发者，利用 IBM Redbooks 中的知识构建新功能。
- 为每年处理 数十亿美元 的软件成功交付了生产环境的现代化部署。
- 技术顾问，协调跨学科团队的现代化工作，规划并监督众多项目。
- 强调务实、降低风险和成本的转型策略，在技术创新与运营稳定之间取得平衡。