我们有一个拥有1000万行4GL(Progress)代码的应用程序和一个拥有300个表的OpenEdge数据库。我的老板说我们应该把它迁移到一种新的编程语言和一个新的数据库管理系统。我的问题是:
- 你认为我们应该迁移它吗?你认为进步有"未来"吗?
- 如果我们应该迁移它，如何，有什么工具吗?或者我们应该从头开始编程?
谢谢你的帮助。Ablo
除非你的老板有无限的预算、无限的用户耐心和对挫折和痛苦的渴望，否则你不应该浪费任何时间考虑重写。
http://www.joelonsoftware.com/articles/fog0000000069.html是的，进步有未来。它们可能永远不会像微软或甲骨文或其他酷孩子们本周正在使用的东西那样性感。但是他们已经存在了30年，当你和你的老板退休的时候，他们还会在这里。
有些人会因为Progress没有X或者没有y而对它嗤之以鼻，也许他们可以在下周末重写你的1000万行代码，并证明他们是多么正确。但是，在用户验收测试通过并且实现完成之前，我不会为他们的这些努力付费。几年后(最初的帖子是2014年的，答案是2014年到2015年的):
获得最多投票的帖子基本上有两种观点:
。Progress (Openedge)已经存在很长时间了，而且不会很快消失。
b。除非你的老板有无限的预算、无限的用户耐心和对挫折和痛苦的渴望，否则你不应该浪费任何时间考虑重写:http://www.joelonsoftware.com/articles/fog0000000069.html
关于a:
是的，Progress OpenEdge Stack仍然存在。但从我的经验来看，要找到经验丰富、技术娴熟的Openedge用户变得更加困难了。
但这里还有一个重要的因素，我认为自从讨论开始以来，它已经变得更加重要了:
可用于应用程序开发的开源堆栈已经得到了更好的因素，无论是在开箱即用的功能和质量方面，并且已经果断地朝着RAD的方向发展。
我正在考虑例如Spring Boot，但不仅如此，请参阅https://stackshare.io/spring-boot/alternatives。在Java领域中，Spring Boot当然是独一无二的。此外，对于富web的开发，也出现了许多非常有效的选项，它们当然可以满足RAD的需求，只是一些"任意"的例子https://vaadin.com用于Java，还有https://www.polymer-project.org用于Javascript，有趣的是它们都与https://vaadin.com/flow融合在一起。
许多可用的堆栈仍在不断发展，但作为强大的驱动程序，它们都使开发人员的工作更轻松。此外，在架构方面，你会发现许多这些堆栈在基本构建块和原则方面的融合:接口与实现的分离、用于远程通信的REST API、对象关系映射技术、NoSql/Json方法等。
所以是的，开源堆栈在开发方面变得非常高效。还必须提到的是，这些堆栈的范围不会随着开发而停止:部署、操作方面和测试自然也是强大的，它们最终也使开发人员的工作更轻松。
一般来说，我们可以说，在RAD需求的背景下，选择良好的开源堆栈混合和匹配具有非常强大的价值主张，从长远来看，私有堆栈将很难与之匹配——至少从我的角度来看是这样。
关于b:
有趣的是，我最近遇到了一个客户，他想做的就是:重写他们的应用程序。具有讽刺意味的是:他们正在从Progress迁移到Progress OpenEdge，并附带几个额外的OpenEdge兼容工具。原因有二:他们的代码越来越难以维护，而且为了满足来自Web前端的需求，他们会进行重构。同样有趣的是，他们找不到足够多的合格开发人员。
基本上:当代码可以重构，当它可以随着新的需求发展时，它是健全的和有生命的。不幸的是，有很多例子——至少从我的经验来看——是相反的。
另外，软件生命周期结束可以迫使公司"重写"至少他们的软件层。这并不一定是坏的和不可能的。我曾参与过一个项目，在不到两年的时间内将300多个Oracle Forms表单迁移到基于Java的UI上。这种从2层架构到3层架构的迁移实际上使公司能够发展他们的架构来满足Web Ui的需求。所以其实最后这个"重写"和强回报的价值也从商业的角度来看。
(非常;-))长话短说:不管怎样，概括很容易出错。
您不需要从头开始编程。网上有帮助，是的，如果你遇到困难，你可以联系进步技术支持。一般来说，以前版本的ABL代码只需要稍加修改就可以工作。为了迁移应用程序，您需要做以下几件事:
备份数据库备份源代码和。r文件
截断DB bi文件
转换数据库
重新编译ABL代码并测试
http://knowledgebase.progress.com文章将在这方面帮助您。如果您是从像9这样的旧版本迁移过来的，那么您可以找到一组很好的新特性。你可以尝试一下，但必须在你完成转换之后。
如果要从32位迁移到64位并且使用32位库，则需要将其替换为64位
我要问的第一个问题是"为什么"?如果应用程序没有达到要求，这是一回事，需要从这个角度来看待问题。
如果认为Progress是一个"较小的"应用程序开发和操作环境，并且希望只是转移到一个不同的开发和操作环境—您将最终花费大量的时间、精力和金钱资源—更不用说机会成本—为了什么呢?在不同的数据库平台上运行?迁移会降低TCO吗?更快的开发周期?更快的上市时间?从Progress迁移的预期优势是什么?如果有的话，需要多长时间才能收回迁移成本?
在某个地方，有一家公司也有类似的想法，并试图离开Progress和ABL。这项工作未能达到他们的目标性能和功能指标，所以他们最终放弃了迁移，认输了，并在项目上花费了2500万美元后继续前进。
你的公司能承受那样的风险/回报比率吗?
Progress (Openedge)已经存在很长时间了，而且不会很快消失。除非当前的应用程序不能满足您的需求，否则用任何语言重写1000万行代码都是不值得的。即使这样，把它提高到当前的需求通常是一个更好的解决方案。
如果您需要将当前应用程序迁移到最新版本的Openedge (Progress)，您通常只需复制数据库并将其转换为新版本的Openedge，并针对新数据库编译您的代码并消除错误。您可能会遇到一些关键字问题，但这通常是相当小的。
如果您需要编程方面的帮助，我建议您联系Progress Software并参加年度贸易展，或者访问https://community.progress.com/并询问/寻找本地用户组。本地用户组将是寻找本地编程人才的绝佳场所。
希望对您有所帮助.....