我的部门目前面临着维护相当大的 COBOL 代码库的任务。我们想知道如何添加新功能以满足业务需求。现在 COBOL 程序员很难找到，而且我们还认为使用 Java 或 C# 等更现代的语言可以提高工作效率。
我们觉得我们有四种选择：
您认为对我们来说最好的选择是什么，为什么？
诚然，问题涉及 cobol，它会根据您的需求给出任何答案，如果您说“我们有一个旧的 VB 应用程序”或旧的 C 应用程序，那么选项 #3 始终是正确的选择。
我曾在 3 家决定选择选项 2 的公司工作过。2 试图为新系统买单而破产，而只能从旧系统中获得收入，3 确实非常接近。
opetion #3 的另一个因素是您可以保留多年来所做的所有旧错误修复。每次重写都会引入越来越多的错误，部分原因是您希望快速完成重写，部分原因是您将使用一种新的、不熟悉的语言编写它，部分原因是所有新代码都有错误。
重构并替换旧应用程序的逻辑块，最终您将拥有一个漂亮闪亮的新应用程序。从 GUI 开始，以获得最安全的新方法。此外，当你用新的东西重写应用程序时，更新的东西将是最酷的，你的新应用程序将过时，你将再次发布相同的问题！
这是选项 3 的变体：
Microfocus提供了一个名为 Enterprise Server 的工具，它允许 COBOL 与 Web 服务进行交互。
如果您有一个 COBOL 程序 A 和另一个 COBOL 程序 B 并且 A 通过接口部分调用 B，则该工具允许您将 B 的接口部分公开为 Web 服务。
对于程序 A，然后生成客户端代理，A 现在可以通过 Web 服务调用 B。
当然，因为 B 现在有一个 Web 服务，任何其他类型的程序（命令行、Windows 应用程序、Java、ASP 等）现在也可以调用它。
使用这种方法，您可以“蚕食边缘”，将 GUI 移动到使用 ASP 之类的现代、基于浏览器的方法，同时仍然使用 COBOL 业务引擎。
一旦你拥有了一套不错的 Web 服务，它们就可以用于任何新的开发，从长远来看，它提供了一种远离 COBOL 的方式。
尝试完全重写时要小心。对于许多软件公司来说，有很多这样的例子。网景是一个典型的例子
遵守 80/20 规则。与客户坐下来，为获得 80% 使用率的 20% 的应用编写规范。在现代系统中写下来。然后要么保留旧系统以减少特殊情况的数量，要么在充实新系统时逐步淘汰它。
不要试图 100% 重写旧代码。这很愚蠢。最好的情况是您拥有一个过时系统的完整端口。最坏的情况是您花费大量时间和金钱来建立一个失败的新系统，而您仍然坚持使用旧系统。
花时间和精力来改进系统，而不仅仅是移植它。在移植了最重要的部分之后，利用时间重新考虑特殊情况。
选项#2 和#3 是您的最佳选择。如果您的 COBOL 应用程序将其数据存储在 SQL DB 或其他一些健全的格式中，您可以从最便宜/最简单的解决方案的现代语言轻松访问。
如果没有，那么在您重建时，需要有人在工作人员中实施关键的新功能。但我仍然建议要求每个人将旧代码库中的新功能限制在真正关键的功能上。
从长远来看，维护 COBOL 只会变得更加困难。你等待的时间越长，它就越难。
逐步迁移应用程序？
有没有一种方法可以将其他代码连接到 COBOL，并随着变化的涌现逐渐重写组件？您可能永远无法摆脱所有这些，但这真的重要吗？
重写现有代码通常是一个坏主意。这将是非常冒险的（例如，可能会破坏某人所依赖的一些知之甚少的功能）并且会花费大量时间而没有实现大多数利益相关者可见的任何有用的东西。
如果需要，不要假设一个称职的程序员将无法学习 COBOL——一种编程语言与另一种很相似。如果您雇用（比如）C++ 或 Java 方面有能力的人，他们将能够学习 COBOL。
我自己已经将旧系统迁移到新系统（尽管规模要小得多）。
对于客户端/服务器系统（一种小型的内部编写的报告系统），我们非常成功地使用了“逐步替换”（#2）方法。实际上，我们通过使用“代理”方法做了一些改动：
这种方法提供了很大的灵活性，并且允许在不触及旧代码的情况下实现新的东西。转换持续了一年多，应用程序的最后部分仅迁移到新系统，因为旧服务器运行在专用的、老化的硬件上，即将退役。
我实际上是在迁移所有内容时亲自下到服务器机房将旧服务器关闭。那很有趣 ：-）。
顺便说一句，这种“逐渐转换”的方法还允许我们在新系统中实现一些日志记录，以决定使用哪些功能的频率。这样，一些旧的服务器功能可能会被废弃，因为事实证明客户端不再使用它。这是“代理”方法的一个显着优势。
我会使用 Microfocus/AcuCOBOL 中的一些很棒的东西来维护旧代码并为其添加新功能。您可以直接从“遗留”代码中创建 GUI 应用程序并调用 .NET 和 Java 内容。
如果它对你有用，为什么要打破后端？保留工作的后端并更换疲惫的前端是我工作的公司开始采用的解决方案。
所以我想我的选择是选项#3，因为那里有这样的解决方案。
数据不足，无法确定正确的路线。
尽管许多人在特定情况下给出了适当的答案，但正确的答案实际上取决于您公司所处的业务情况。
现有的路线图、交付承诺、服务合同、新功能所需的发布时间等将决定什么是最适合您的情况。
也就是说，许多技术专家的答案是#1，而许多商务人士的答案是#4。只知道所呈现的内容，我会推动团队深入调查#3，因为它可能是最低风险。＃1有失败的记录，而＃2只是资源较少的＃1。#4 可能不是一个长期的解决方案，除非您在近期/中期终止此产品线。
老实说，在帮助将应用程序从 ColdFusion 5“移植”到 PHP 到 ColdFusion 8 之后，我会说选择 #1。保留旧应用程序并冻结开发。与客户会面并说明新功能是什么，以及旧系统如何工作/应该如何工作并生成良好的需求文档。剩下的只是构造和设计细节，然后您可以智能地为您的应用程序选择最佳语言和平台。
在我现在工作的地方，我们实际上是在构建替换的 .NET 应用程序时维护一个旧的 CF 应用程序。您能想象 .NET 人员在完成基本应用程序后必须编写的代码吗？这就是为什么我建议冻结开发。
我坚信将遗留应用程序更新为尖端技术（这让我的经理很沮丧）。这应该始终是一个分阶段的方法，并且只有在必要时才进行。尝试保持遗留应用程序运行并服务于它的目的，但在更新的技术中创建它的一小部分，并且随着时间的推移逐步淘汰旧代码并用更新的代码替换它。我总是确保我优先考虑这些对企业的收益/成本。
如果应用程序过于紧密，那么听起来您需要聘请一些 COBOL 脚本编写人员来帮助提取隔离的服务，以便在准备好时可以将它们贬低。
请注意：有时原始遗留代码中的错误和怪癖服务于业务所依赖的目的，因此请注意修复其他代码以后依赖的错误。
另一种解决方案可能是：
将代码翻译成您选择的现代语言。
通常，这将涉及几个大块：
这种方法的主要优点是它将保留多年来在代码库中编码的所有令人讨厌的业务角落案例。从头开始重写的最大问题是它们丢弃了所有这些积累的知识。
另一个优点是它把一个烦人的问题（维护一个 cobol 应用程序）变成了一个有趣的问题（自动语言翻译），所以你有机会让一个优秀的程序员参与这个项目。
吉姆丹佛评论
编写一个可以翻译成可读性和可维护性代码的翻译器不是很难吗？我们的问题是 COBOL 应用程序是维护的噩梦。我们不希望这成为另一种语言的噩梦。
我说不出会有多难。如果您开始的代码是常规的，那就更容易了。但无论如何，您最终都会得到“用 $LANG 编写的 COBOL”。这只是增量重写的起点，直到修复了维护噩梦。
这只是“从头开始重写”和“在 COBOL 中维护”的替代方案。可能只是代码库中积累的知识价值低于增量清理的预期成本。
如何使用第三方应用程序之一，该应用程序采用 cobol 并将其转换为 C#，例如：
http://www.softwaremining.com/index.jsp
或者将其移植到 COBOL.net，这应该更容易，然后您添加的所有内容都可以使用其他 .net 语言之一。
我会维护旧的应用程序，但是，我是一名 cobol 程序员....
如果您使用 OpenVMS，BridgeWorks可以帮助您使用旧代码稍作修改来构建 Web 应用程序。
COBOL 的美妙之处在于，数据要求就在代码的顶部进行了说明。COBOL 被设计为使用（相对）简单的商务英语（TXTSPKers 不需要申请）编写也有帮助。
当然，如果您的割草机比您的某些程序员年长，请忘记让他们阅读源代码。他们只会抱怨太多。
我认识的一家公司多年来一直在为同样的问题苦苦挣扎；最终，他们放弃了 COBOL 应用程序并转而使用 SAP。这样做是一个巨大的项目，需要几年时间才能完成，但效果很好。