重写遗留代码

Question

我的部门目前面临维护相当大的COBOL代码库的任务。我们想知道如何添加新功能以满足业务需求。 COBOL程序员现在很难找到，我们也认为使用Java或C＃等更现代的语言可以提高工作效率。

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

1. 从头开始重写所有内容，将旧应用程序留给自己，直到它准备好被替换为止
2. 从头开始重写所有内容，让一些人维护旧应用程序，以便在构建新应用程序时满足新的业务需求
3. 以现代语言编写所有新功能，并找到一些方法将新代码与旧功能集成。
4. 继续维护旧应用程序。

您认为我们最好的选择是什么？为什么？

Answer 1

很抱歉，问题涉及cobol，根据您的需求做出任何答案，如果您说“我们有一个旧的VB应用程序”或旧的C应用程序，那么选项＃3始终是正确的方法。

我曾在3家公司工作，他们决定选择＃2​​。 2人试图支付新系统的费用，而只是从旧系统获得收入，第3次确实非常接近。

操作＃3的另一个因素是你可以保留你多年来所做的所有旧错误修正。每次重写总会引入越来越多的错误，部分原因是你想要快速完成重写，部分原因是你将用一种新的，不熟悉的语言编写它，部分是因为所有新代码都有错误。

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

Answer 2

这是选项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业务引擎。

一旦你拥有了一套不错的网络服务，这些服务就可以用于任何新的开发，从长远来看，它可以摆脱COBOL。

Answer 3

小心尝试完全重写。很多软件公司都有很多这样的例子。 Netscape是prime example

Answer 4

遵守80/20规则。坐下来与客户端一起编写20％应用程序的规格，获得80％的使用率。把它写在现代系统中。然后要么保留旧系统以减少特殊情况的数量，要么在充实新系统时将其逐步淘汰。

不要试图100％重写旧代码。这太傻了。最好的情况是你有一个过时系统的完整端口。在最糟糕的情况下，你需要花费大量的时间和金钱才能使新系统出现故障并且你仍然坚持使用旧系统。

使用时间和精力来改进系统，而不仅仅是移植系统。移植最重要的部件后，请使用时间重新考虑特殊情况。

Answer 5

选项＃2和＃3是您的最佳选择。如果您的COBOL应用程序将其数据存储在SQL DB或其他一些理智的格式中，您可以使用现代语言轻松访问该格式，这是最便宜/最简单的解决方案。

如果没有，那么在你重建的过程中让一个人在工作人员上实施关键的新功能是必要的。但我仍然建议每个人都要将旧代码库中的新功能限制为真正关键的功能。

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

Answer 6

我已经完成了将旧系统迁移到新系统的过程（尽管它的规模要小得多）。

我们非常成功地使用“逐步替换”（＃2）方法，用于客户端/服务器系统（一种小型的，内部编写的报告系统）。我们实际上是通过使用“代理”方法来扭转它：

• 首先我们实现了一个新服务器，它提供了旧服务器的所有功能/调用接口，但内部只是将所有内容委托给旧服务器，后者一直在运行。
• 然后所有客户都切换到新系统;这是相对无痛的，因为新系统基本上只是一个包装。
• 最后，我们逐步重新编写新服务器以实现功能，而无需回拨旧系统。

这种方法提供了很大的灵活性，并允许在不触及旧代码的情况下实现新内容。转换持续了一年多，应用程序的最后部分只迁移到新系统，因为旧服务器运行在专用的，老化的硬件上，将被淘汰。

当我迁移所有内容时，我实际上下到了服务器机房，亲自关闭了旧服务器。这很有趣： - ）。

从本质上讲，这种“逐步转换”方法还允许我们在新系统中实施一些日志记录，以确定使用频率的功能。这样，一些旧的服务器功能可能会被废弃，因为它发现客户端不再使用它。这是“代理”方法的一个重要优势。

Answer 7

逐步迁移应用程序？

有没有办法可以将其他代码与COBOL接口，并在变化通过时逐渐重写组件？你可能永远不会摆脱所有这一切，但这真的很重要吗？

重写现有代码通常是一个坏主意。这将是非常危险的（例如，风险打破某些人依赖的一些知之甚少的功能）并且耗费大量时间而没有实现大多数利益相关者可见的任何有用的东西。

如果需要，不要认为有能力的程序员将无法学习COBOL-一种编程语言就像另一种编程语言。如果你雇用一个能胜任（比如说）C ++或Java的人，他们就能学习COBOL。

Answer 8

我会使用Microfocus / AcuCOBOL中的一些优点来维护旧代码并添加新功能。您可以直接从“遗留”代码中执行GUI应用程序并调用.NET和Java。

如果它适合你，为什么要打破后端？保持工作后端并更换疲惫的前端是我工作的公司开始使用的解决方案。

所以我猜我的选择是选项＃3，因为那里有一个解决方案。

Answer 9

数据不足以确定正确的课程。

虽然在特定情况下，很多人已经找到了合适的答案，但正确的答案实际上取决于贵公司所处的业务情况。

现有路线图，交付承诺，服务合同，新功能启动时间等等将决定您的最佳状况。

尽管如此，许多技术专家的答案将是＃1，而许多商业人士的答案将是＃4。只知道所呈现的内容，我会推动团队深入调查＃3，因为它可能是风险最低的。 ＃1具有成功的失败记录，而＃2只是资源较少的＃1。 ＃4可能不是一个长期的解决方案，除非你在近期/中期内对这个产品线进行了EOL。

Answer 10

另一种解决方案可能是：

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

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

• 重写无法翻译的旧应用程序的部分内容。至少，在任何地方都使用结构化编程结构。
• 实施internal DSL，以便更容易地用新语言映射旧语言的构造。
• 为90％的代码实现一次性的源代码转换器。
• 手工翻译其余10％的棘手代码。
• 花很多时间来编译这件事。
• 通过一些严肃的测试和修复来完成整个事情。
• 慢慢清理生成的动物，使其成为惯用语。

这种方法的主要优点是它将保留多年来在代码库中编码的所有讨厌的业务角案例。从头开始重写的一个大问题是他们放弃了所有这些积累的知识。

另一个优点是它将一个令人讨厌的问题（维护一个cobol应用程序）变成一个有趣的问题（自动语言翻译），所以你有机会让一个好的程序员参与这个项目。

  

Jim Denver的评论

     

    

编写一个翻译成可读性和可维护性的代码的翻译器难道不是很难吗？我们的问题是COBOL应用程序是一个主要的噩梦。我们不希望这种情况成为另一种语言的噩梦。

  

我不知道它会有多难。如果您开始使用的代码是常规代码，则会更容易。但无论如何，你最终会得到“用$ LANG编写的COBOL”。这只是增量重写的起点，直到维护噩梦得到修复。

这只是“从头开始重写”和“在COBOL中维护”的替代方案。可能只是代码库中累积知识的价值低于增量清理的预期成本。

Answer 11

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

Answer 12

我坚信将遗留应用程序更新为尖端技术（这让我的经理感到沮丧）。这应该始终是分阶段的方法，只有在必要时才进行。尝试保持遗留应用程序的运行并满足其目的，但是在较新的技术中创建它的一小部分，并随着时间的推移逐步淘汰旧代码并用更新的代码替换它。我总是确保首先将这些优先考虑在业务的利益/成本中。

如果应用程序编织得太紧，那么听起来你需要雇用一些COBOL脚本来帮助提取孤立的服务，这样你就可以在准备就绪时对其进行描述。

请注意：有时原始遗留代码中的错误和怪癖会产生业务所依赖的目的，因此要小心修复其他代码后来依赖的错误。

Answer 13

如何使用其中一个采用cobol并将其转换为C＃的第三方应用程序，如：

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

或者将它移植到COBOL.net，这应该更容易，然后你添加的所有东西都可以使用其他.net语言。

Answer 14

老实说，帮助将应用程序从ColdFusion 5“移植”到PHP到ColdFusion 8，我会说＃1。保留旧应用程序并冻结开发。除了旧系统如何工作/应该如何工作以及生成良好的需求文档之外，还与客户会面并指出新功能的内容。这只留下了构造和设计细节，然后您可以智能地为您的应用选择最佳语言和平台。

我现在在哪里工作，我们实际上在构建替换.NET应用程序时维护一个旧的CF应用程序。你能想象一下.NET人员在完成基础应用程序后必须编写的代码吗？这就是为什么我建议冻结开发。

Answer 15

关于COBOL的美妙之处在于，数据要求在代码的顶部拼写出来。它也有助于COBOL使用（相对）普通商务英语（TXTSPKers不需要申请）编写。

当然，如果你的割草机比你的一些程序员年龄大，那就忘了让他们阅读源代码。他们只会抱怨太多。

Answer 16

我认识的一家公司多年来一直在努力解决同一个问题;最终，他们放弃了COBOL应用程序并切换到SAP。这样做是一项耗资数年才能完成的大项目，但效果很好。

Answer 17

如果您使用OpenVMS，BridgeWorks可能会帮助您使用旧代码构建一个Web应用程序，只需稍加修改。