Mad*_*urf 5 java migration cobol code-migration
原文问: 我想知道是否有人有过将大型Cobol/PL1代码库迁移到Java的经验？
该过程的自动化程度以及输出的可维护性如何？
从交易到OO的转变如何发挥作用？
任何经验教训或可能有益的资源/白皮书都将受到赞赏.
编辑7/7:当然NACA方法很有意思,能够继续对COBOL代码进行BAU更改,直到发布JAVA版本,这对任何组织都有好处.
与COBOL布局相同的过程Java的参数,使编码人员在熟悉Java语言时感到舒适,这对于具有大量代码库的大型组织来说是一个有效的论据.正如@Didier所指出的那样,每年节省300万美元可以在任何BAU变化中提供大量填充的空间,以便持续重构代码.正如他所说,如果你关心你的人,你会找到一种让他们快乐的方法,同时逐渐挑战他们.
我从@duffymo的建议中看出这个问题
最好尝试并从根本上真正理解问题,并将其重新表达为面向对象的系统
如果您正在进行任何BAU更改,那么在编写新OO系统的LONG项目生命周期中,您最终会编码并测试双倍的更改.这是NACA方法的主要好处.我有一些将Client-Server应用程序迁移到Web实现的经验,这是我们遇到的主要问题之一,由于BAU更改而不断变换需求.它使PM和日程安排成为一项真正的挑战.
感谢@hhafez,他的经验很好地被认为是"相似但略有不同",并且从Ada到Java的自动代码迁移有着相当令人满意的体验.
感谢@Didier的贡献,我还在研究你的方法,如果我有任何Q,我会告诉你一句话.
更新6/25:一位朋友刚跑过NACA Cobol到Java转换器.看起来很有趣,它被用来翻译4米线的Cobol,准确度达到100%.这是NACA开源项目页面.我见过的其他转换器都是专有的,材料显然缺乏成功案例和详细的示例代码.NACA值得一看.
更新7/4: @Ira Baxter报告说Java输出看起来很Cobol-esque,它绝对是.对我来说,这是自动翻译的自然结果.我怀疑我们会找到一个更好的翻译.这也许是对逐步重写方法的争论.
更新2/7/11: @spgennard指出JVM上有一些Cobol编译器,例如Veryant的isCobol Evolve.这些可以用来帮助逐步转换代码库,但我认为OP对自动源转换更感兴趣.
我对此非常谨慎.(我曾经为一家为Y2K 自动修正 Cobol和PL/I程序的公司工作,并且做了前端编译器,将Cobol的许多方言转换为我们的中间分析形式,还有代码生成器.)我的感觉就是你最终会使用Java代码库,但仍然不够优雅且不满意.您可能会遇到性能问题,依赖于供应商提供的库,生成的错误代码等等.你肯定会招致巨额测试费用.
从头开始使用新的面向对象设计可能是正确的方法,但您还必须仔细考虑代码库所代表的数十年存储知识.通常,您的新代码可能会遗漏许多细微之处.另一方面,如果您很难找到维护遗留系统的人员,您可能无法做出选择.
一种渐进的方法是首先升级到Cobol 97.这会增加面向对象,因此您可以在添加新功能时单独重写和重构子系统.或者您可以用新编写的Java替换单个子系统.
有时您可以使用现成的软件替换组件:我们帮助一家大型保险公司在20世纪50年代创建的传统语言中仍然拥有200万行代码.我们将其中的一半转换为符合Y2K标准的遗留语言,并且他们用从外部供应商处购买的现代工资单系统替换了另一半.
| 归档时间： |
|
| 查看次数： |
9099 次 |
| 最近记录： |