重写遗留代码[关闭]

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就是一个很好的例子

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

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

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

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

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

Answer 9

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

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

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

Answer 10

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

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

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

Answer 11

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

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

Answer 12

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

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

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

Answer 13

另一个解决方案是：

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

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

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

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

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

吉姆丹佛评论

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

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

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

Answer 14

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

Answer 15

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

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

Answer 16

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

Answer 17

如果您使用OpenVMS， BridgeWorks可以帮助您使用旧代码构建Web应用程序， 只需稍作修改即可。