我一直在阅读有关仍在生产中的 Cobol 代码量的信息。它没有更新为更现代的语言的主要原因是它需要太长时间/成本太高。
我的问题是:如果有一种工具可以将 Cobol 转换为 Java,那么任何组织会发现它有用吗?还是他们宁愿继续保持他们知道已经有效的东西?
目前,大量的 COBOL 代码(我估计超过 90%)是无法测试的。
没有人知道它的真正作用。
他们知道——至少——它在大多数时候都能完成预期的工作。如果没有,则错误是已知的。
更糟糕的是,一部分 COBOL 只是针对 COBOL 其他部分中的错误的解决方法。
因此,如果您对其进行任何审查,您会发现您不知道真正发生了什么。您不能创建测试用例。
事实上,您会发现大多数组织甚至无法就什么是“正确的”达成一致。但他们愿意在可用的东西上妥协。
检查核心业务处理的成本和风险是不可想象的。
人们总会找到将一种语言转换为另一种语言的工具——它们通常使用“编译器”一词。
必须执行将语言 X 的代码转换为语言 Y 的任务的编译器总是存在一个缺点,尤其是当所述代码是由人编写时。这个缺点恰好是在翻译过程中经常失去可读性的事实。无法保证任何程序员都能理解从 COBOL 编译成 Java 的代码,因此实际上翻译成本实际上增加了。事实上,在这种情况下很难定义可读性。
缺乏可读性和可理解性意味着缺乏对已翻译代码的运行时行为的了解。此外,不能保证人们完全理解原始代码;当然,他们确实了解其中的点点滴滴。
任何转换工具都会有与之相关的风险,并且生成的代码必须经过大量测试。
鉴于每天都在使用这些系统中的许多来运行业务,因此很多依赖于持续运营。因此,这不仅仅是“多长时间”或“多贵”,而是我们能否相信它能够 100% 相同地工作。
可能两者都有一点。有些公司提供使用自动和手动技术进行转换的工具和服务。
然而,许多公司都遵循“永不破产”的理念,这可能与任何事情一样明智。特别是因为许多转换导致尝试“改进”现有系统或尝试引入现代软件设计/构建理念并导致混乱。
许多用 Cobol 编写的系统都有许多事务通过它们。它们在运行的大型机平台上运行良好。仅仅为了改变而改变它们是有风险的。
我认为一些组织可能会发现它很有用,特别是那些与遗留代码交互/设计比将代码转换为 Java(或其他语言)成本更高且问题更大的组织
while ( (CostToPortToJava > CostOfNotPortingOverTime++) && DoesLegacyCodeStillWork() )
{
StayWithLegacyCode();
}
PortCodeToJava();
这里有几个因素:
这将需要很长时间 - 每隔一段时间,其中一个程序的一部分就会停止工作或无法做某事,并且它会被替换。我没有看到很多高级管理人员对其中一个项目中的所有 FUD 有胃口,而且就所花费的资金回报而言,时间框架相当长。
COBOL 实际上是一种极好的 DSL(领域特定语言)。
它的领域是嵌入(主要)后端应用程序中的业务规则。
寻找另一种语言......
....您将拥有后端业务应用程序的杀手级应用程序。
对于旧的 COBOL 应用程序,除了语言不同之外,需要意识到的是,在这些应用程序中构建的许多数据结构不符合任何后来的 RDBMS 结构,所以实际上你会谈论重新思考很多底层架构和设计,而不仅仅是改变语言语法,一旦它达到现实世界的负载,替换它就会有很大的性能风险,即使它可以进行充分的 QA。
底线是,在现代语言中加入新功能比重写它更经济。只要这种情况继续存在,COBOL 就会继续存在。
Cobol 的优势在于可以快速移动数据,而这正是这类应用程序经常做的事情。这些机器也是为 I/O 而设计的,而不是处理速度。因此,在相同或相似的硬件上,任何到另一种语言的翻译很可能会比 Cobol 对应物慢,没有理由这样做。
让我问一个反问:如果你有合适的东西,为什么要转换它?
(类似于每 10 年拆除一座桥,只是为了在之后再次重建它——维护你所拥有的通常总是更便宜)。
有一些翻译器可以以很少的成本进行修改,使其在特定的机器或操作系统上运行,有些可以从英国获得,可以在那里或现场运行。主要型号都有标准版本(任何人都可以联系我)。Cobol 到另一种语言的源代码或脚本相对容易自动执行,并且会生成一个文本文件以导入到目标机器上的源文件中,具有 95% 或更高的代码兼容性。在运行编译器或 JIT 软件以实现新程序之前,只需进行简单的手动修改——不要忘记在测试或上线时修改大型机作业的作业命令语言或宏。