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