我的部门目前面临着维护相当大的COBOL代码库的任务。我们想知道如何添加新功能来满足业务需求。如今，COBOL程序员很难再出现了，我们还认为，使用Java或者C＃等更现代的语言可以提高生产率。

我们认为我们有四个选择：

• 从头开始重写所有内容，将旧应用程序留给自己，直到准备好进行替换
• 从头开始重写所有内容，使一些人可以维护旧的应用程序，以在新的应用程序构建时应对新的业务需求
• 用现代语言编写所有新功能，并找到某种方式将新代码与旧功能集成在一起。
• 继续维护旧的应用程序。

我们认为什么是我们的最佳选择，为什么？

解决方案

回答

老实说，我已经帮助将＃1应用程序从ColdFusion 5移植到PHP到ColdFusion 8. 保留旧的应用程序并冻结开发。与客户会面，并说明新功能是什么，以及旧系统如何工作/应该如何工作并产生良好的需求文档。剩下的只是构造和设计细节，然后我们就可以为应用程序智能地选择最佳的语言和平台。

我现在工作的地方，实际上是在构建替换的.NET应用程序时维护一个旧的CF应用程序。我们能想象.NET人员完成基本应用程序后必须编写的代码吗？因此，我建议冻结开发。

回答

尝试完全重写时要小心。对于许多软件公司来说，有很多这样的例子是行不通的。 Netscape是一个很好的例子

回答

选项＃2和＃3是最佳选择。如果COBOL应用程序以SQL DB或者其他合理的格式存储数据，则可以从最便宜/最简单的解决方案现代语言轻松访问。

如果不是这样，那么在重建时需要有人来实施关键的新功能。但是我仍然建议大家限制旧代码库中的新功能，只限于真正关键的功能。

从长远来看，维护COBOL只会变得越来越困难。我们等待的时间越长，就越难。

回答

我坚信将旧版应用程序更新为尖端技术(这让我的经理很沮丧)。这应该始终是分阶段的方法，并且仅在必要时才采取。尝试保持旧版应用程序的运行并满足其目的，但要使用较新的技术来创建旧版应用程序的一小部分，然后逐步淘汰旧代码并用新代码替换。我始终确保首先将收益/成本中的这些放在业务上。

如果应用程序编织得太紧密，则听起来我们需要雇用一些COBOL脚本编写者来帮助提取隔离的服务，因此可以在准备就绪时将它们贬低。

注意这一点：有时原始遗留代码中的错误和怪癖可达到企业赖以生存的目的，因此请谨慎纠正以后其他代码所依赖的错误。

回答

诚然，问题涉及到cobol，它会根据需求做出任何特定的答案，如果我们说"我们有一个旧的VB应用程序"或者旧的C应用程序，那么选择＃3始终是正确的方法。

我曾在3家决定选择方案2的公司工作。第2位破产者试图为新系统付费，而仅从旧版本中获得收益，第3位确实非常接近。

行动3的另一个因素是，我们必须保留多年来使用的所有旧错误修正程序。每次重写总是会引入越来越多的错误，部分是因为我们希望快速完成重写，部分是因为我们将用一种陌生的新语言编写它，部分是因为所有新代码都包含错误。

重构并替换旧应用程序的逻辑块，最终我们将拥有一个漂亮的闪亮新应用程序。从GUI开始，以获得最安全的新方法。此外，当我们完成用新内容重写应用程序时，更新的内容将是最酷的，新应用程序将过时，我们将再次发布相同的问题！

回答

遵守80/20规则。与客户坐下来，为20％的应用编写规格，获得80％的使用率。用现代系统编写。然后或者保留旧系统以减少特殊情况，或者在充实新系统时逐步淘汰旧系统。

不要尝试将旧代码改写为100％。那真是愚蠢。最好的情况是我们拥有完整的旧系统端口。最坏的情况是，我们要花费大量时间和金钱来使新系统发生故障，而我们仍旧无法使用旧系统。

花费时间和精力来改进系统，而不仅仅是移植它。移植了最重要的部分之后，请花时间重新考虑特殊情况。

回答

另一个解决方案可能是：

将代码翻译成我们选择的现代语言。

通常，这将涉及几个大块：

• 重写旧版应用程序中无法翻译的部分。至少，到处都使用结构化的程序构造。
• 实施内部DSL，使从旧语言到新语言的结构映射更加容易。
• 为90％的代码实现一个一次性的源代码翻译器。
• 手动翻译其余10％的棘手代码。
• 花很多时间来编译该死的东西。
• 通过认真的测试和修复来获得整个结果。
• 慢慢清理所产生的动物，使其变得惯用。

这种方法的主要优点是，它将保留多年来在代码库中已经编码过的所有讨厌的商业案例。从头开始重写的最大问题是它们会丢弃所有这些累积的知识。

另一个优点是，它将烦人的问题(维护cobol应用程序)转变为有趣的问题(自动语言翻译)，因此我们有机会让优秀的程序员参与项目。

Comment by Jim Denver
  
  
    Won't it be very hard to write a translator that translate into code that is somewhat readable and maintainable? Our problem is that the COBOL app is a maintenence nightmare. We don't want this to become the same nightmare in another language.

我无法说出这将有多困难。如果我们从中开始的代码是常规代码，则会更容易。但是无论如何，我们最终都会得到"用$ LANG编写的COBOL"。这只是逐步重写的起点，直到解决了维护方面的噩梦。

这只是"从头重写"和"保留在COBOL中"的替代方法。可能仅仅是代码库中积累的知识的价值小于增量清理的预期成本。

回答

逐渐迁移应用程序？

有没有一种方法可以将其他代码连接到COBOL，并随着更改的进行而逐渐重写组件？我们可能永远不会摆脱所有这些，但这真的重要吗？

重写现有代码通常不是一个好主意。这将具有很大的风险(例如，冒着破坏某人所依赖的一些理解不清的功能的风险)，并且会花费大量时间而没有实现大多数利益相关者都可以看到的有用的东西。

如果需要的话，不要以为有能力的程序员将无法学习COBOL。一种编程语言很像另一种。如果雇用(例如)C ++或者Java的主管，他们将能够学习COBOL。

回答

我会维护旧的应用程序，但是，我是一名cobol程序员...。

回答

我将使用Microfocus / AcuCOBOL的一些出色功能来维护旧代码并为其添加新功能。我们可以执行GUI应用程序，并直接从"旧版"代码中调用.NET和Java。

如果适合我们，为什么要破坏后端？保持后端工作并更换疲倦的前端是我工作的公司开始采用的解决方案。

所以我想我的选择将是选项3，因为那里有这样的解决方案。

回答

这是选项3的变体：

Microfocus提供了一个称为Enterprise Server的工具，该工具允许COBOL与Web服务进行交互。

如果我们有一个COBOL程序A和另一个COBOL程序B，并且A通过接口部分调用B，则该工具允许我们将B的接口部分公开为Web服务。

然后，对于程序A，我们将生成一个客户端代理，并且A现在可以通过Web服务调用B。

当然，由于B现在具有Web服务，因此任何其他类型的程序(命令行，Windows应用程序，Java，ASP等)现在也可以调用它。

使用这种方法，我们可以"蚕食边缘"，使用ASP之类的工具将GUI迁移到基于浏览器的现代方法，同时仍然利用COBOL业务引擎。

并且，一旦有了一套不错的Web服务，便可以将其用于任何新开发，从而从长远角度提供摆脱COBOL的方式。

回答

如何使用采用cobol并将其转换为Clike的第三方应用程序之一：

http://www.softwaremining.com/index.jsp

或者将其移植到COBOL.net，应该会更容易，然后添加的所有内容都可能使用其他.net语言之一。

回答

关于COBOL的美丽之处在于，数据要求在代码顶部就已阐明。这也有助于将COBOL设计为使用(相对)简单的商务英语编写(不需要使用TXTSPKers)。

当然，如果割草机比某些程序员年长，请不要让他们阅读源代码。他们只会抱怨太多。

回答

数据不足，无法确定正确的过程。

尽管许多人在特定情况下都给出了适当的答案，但正确的答案实际上取决于我们公司所处的业务状况。

诸如现有路线图，交付承诺，服务合同，要求推出新功能的时间等条件将决定哪种情况最适合我们。

也就是说，许多技术专家的答案将是＃1，而许多商人的答案将是＃4. 除了所介绍的内容外，我一无所知，因此我敦促团队深入研究＃3，因为这可能是最低的风险。 ＃1具有可靠的故障跟踪记录，而＃2只是资源较少的＃1. ＃4可能不是一个长期的解决方案，除非我们在近期/中期禁止该产品线。

回答

我认识的一家公司多年来一直在为完全相同的问题而苦苦挣扎。最终，他们放弃了COBOL应用程序并切换到SAP。这样做是一个巨大的项目，耗时数年才能完成，但效果很好。

回答

如果我们使用OpenVMS，BridgeWorks可能会使用旧代码进行少量修改来构建Web应用程序。

回答

我本人已经完成了将旧系统迁移到新系统的工作(尽管它的规模要小得多)。

对于客户端/服务器系统(内部编写的小型报告系统)，我们相当成功地使用了"逐步替换"(＃2)方法。实际上，我们通过使用"代理"方法来做到这一点：

• 首先，我们实现了一个新服务器，该服务器提供了旧服务器的所有功能/调用接口，但内部只是将所有内容委派给了旧服务器，并一直运行。
• 然后，所有客户端都切换到新系统。因为新系统本质上只是一个包装器，所以这相对没有问题。
• 最后，我们逐步改写了新服务器以实现功能，而无需调用旧系统。

这种方法具有很大的灵活性，并允许在不接触旧代码的情况下实现新的东西。转换持续了一年多的时间，该应用程序的最后部分仅迁移到了新系统，因为旧服务器正在专用的，老化的硬件上运行，而该硬件将被淘汰。

实际上，当一切都迁移后，我去了服务器室亲自关闭了旧服务器。蛮好玩的 ：-)。

偶然地，这种"渐进式转换"方法还使我们能够在新系统中实现一些日志记录，从而决定使用哪个功能的频率。这样，某些旧服务器功能可能会被废弃，因为事实证明客户端不再使用它。这是"代理"方法的重要优势。