0

我们在 4GL（Progress）中有一个包含 1000 万行代码的应用程序，还有一个包含 300 个表的 OpenEdge 数据库。我的老板说我们应该将它迁移到新的编程语言和新的数据库管理系统。我的问题是：

  1. 你认为我们应该迁移它吗？你认为Progress有“未来”吗？
  2. 如果我们应该迁移它，如何迁移，有什么工具吗？还是我们应该从头开始编程？

感谢您的帮助。阿布罗

4

5 回答 5

4

除非你的老板有无限的预算、无尽的用户耐心以及对挫折和痛苦的渴望，否则你不应该浪费任何时间考虑重写。

http://www.joelonsoftware.com/articles/fog0000000069.html

是的，进步有未来。他们可能永远不会像微软或甲骨文或本周酷孩子们使用的任何东西那样性感。但是他们已经存在了 30 年，当你和你的老板退休时，他们仍然会在这里。

有些人会对 Progress 嗤之以鼻，因为它不是 X 或没有 Y。也许他们可以在下周末重写你的 1000 万行代码，并证明它们是多么正确。但是，在通过用户验收测试并完成实施之前，我不会为这些努力付钱给他们。

于 2014-07-02T18:32:55.857 回答
1

几年后（原帖是从 2014 年开始，答案是从 2014 年到 2015 年）：

获得最多选票的帖子基本上是在争论两个方面：

一个。Progress (Openedge) 已经存在了很长时间并且不会很快出现

湾。除非你的老板有无限的预算、无尽的用户耐心和对挫折和痛苦的渴望，否则你不应该浪费任何时间考虑重写：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 for 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 的需求。所以实际上最终这种“重写”和强大的价值回报也是从商业角度来看的。

因此，简而言之（非常;-)）长话短说：

无论如何，概括很容易出错。

于 2018-05-29T19:10:43.327 回答
0

我回来的第一个问题是“为什么”？如果应用程序没有达到标准，那是一回事，需要从这个角度来看待这个问题。

如果认为 Progress 在某种程度上是一个“较小”的应用程序开发和操作环境，并且只是希望转移到不同的开发和操作环境 - 您最终会在时间、精力和金钱方面获得大量资源投资——更不用说机会成本——为了什么？在不同的数据库平台上运行？迁移会降低 TCO 吗？更快的开发周转时间？更快的上市时间？从 Progress 迁移的预期优势是什么？恢复迁移成本需要多长时间 - 如果有的话？

某处有一家公司有类似的想法，并试图摆脱 Progress 和 ABL。这项工作未能达到他们的目标性能和功能指标，因此他们最终放弃了迁移，认输，并留在了 Progress 公司——在该项目上花费了 2500 万美元。

你的公司能承受这样的风险/回报率吗？

于 2014-07-03T03:14:13.633 回答
0

您无需从头开始编程。有在线帮助，是的，如果您遇到困难，可以联系 Progress 技术支持。通常，以前版本的 ABL 代码只需进行少量更改即可工作。为了迁移您的应用程序，您需要做以下几件事：

备份数据库
备份源代码和 .r 文件
截断 DB bi 文件
转换你的数据库
重新编译 ABL 代码并测试

http://knowledgebase.progress.com文章将在这方面为您提供帮助。如果您从一些旧版本（如 9）迁移，您可以找到一组很好的新功能。您可以尝试它们，但只有在您完成转换之后。

如果您是从 32 位迁移到 64 位，并且如果您使用的是 32 位库，则需要将它们替换为 64 位

于 2014-07-02T17:44:40.853 回答
0

Progress (Openedge) 已经存在了很长时间，并且不会很快出现。用任何语言重写 1000 万行代码只是为了使用当月的当前风格是不值得的，除非您当前的应用程序没有满足您的需求。即使这样，将其满足当前需求通常也是一个更好的解决方案。

如果您需要将当前应用程序迁移到最新版本的 Openedge（Progress），您通常只需复制您的数据库并将其/它们转换为新版本的 Openedge，然后针对新数据库编译您的代码并把虫子抖掉。您可能会遇到一些关键字问题，但这通常很小。

如果您在编程方面需要帮助，我建议您联系 Progress Software 并参加年度贸易展或访问https://community.progress.com/并询问/寻找本地用户组。本地用户组将是寻找本地编程人才的绝佳场所。

希望这可以帮助.....

于 2015-06-12T04:43:13.537 回答