Rewrite of legacy code我的部门目前承担着维护相当大的COBOL代码库的任务。 我们想知道如何添加新功能来满足业务需求。 如今，COBOL程序员很难再出现了，我们还认为，使用Java或C＃等更现代的语言可以提高生产率。 我们认为我们有四个选择： 您认为什么是我们的最佳选择，为什么？ 诚然，问题涉及到cobol，它会根据您的需求做出任何特定的答案，如果您说"我们有一个旧的VB应用程序"或旧的C应用程序，则选择＃3始终是正确的方法。 我曾在3家决定选择方案2的公司工作。第2位破产者试图为新系统付费，但仅从旧版本中获得收益，第3位确实非常接近。 行动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等)现在也可以调用它。 使用这种方法，您可以"蚕食边缘"，使用ASP之类的工具将GUI迁移到基于浏览器的现代方法，同时仍然利用COBOL业务引擎。 并且，一旦有了一套不错的Web服务，这些服务便可以用于任何新开发，这些新开发提供了从长远来看摆脱COBOL的方式。 尝试完全重写时要小心。对于许多软件公司来说，有很多这样的例子。 Netscape是一个很好的例子 遵守80/20规则。与客户坐下来，为20％的应用编写规格，获得80％的使用率。用现代系统编写。然后要么保留旧系统以减少特殊情况，要么在充实新系统时逐步淘汰旧系统。 不要尝试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可能不是一个长期的解决方案，除非您在近期/中期禁止该产品线。 如何使用采用cobol并将其转换为C＃的第三方应用程序之一，例如： http://www.softwaremining.com/index.jsp 或将其移植到COBOL.net，应该会更容易，然后添加的所有内容都可以使用其他.net语言之一。 老实说，我已经帮助将＃1应用程序从ColdFusion 5移植到PHP到ColdFusion 8。保留旧的应用程序并冻结开发。与客户会面，并说明新功能是什么，以及旧系统如何工作/应该如何工作并产生良好的需求文档。只需留下构造和设计细节，然后您就可以为应用程序智能地选择最佳的语言和平台。 我现在工作的地方，实际上是在构建替换的.NET应用程序时维护一个旧的CF应用程序。您能想象.NET人员完成基本应用程序后必须编写的代码吗？因此，我建议冻结开发。 另一个解决方案可能是： 将代码翻译成您选择的现代语言。 通常，这涉及几个大块：
这种方法的主要优点是，它将保留多年来在代码库中已编码的所有讨厌的商业案例。从头开始重写的最大问题是它们会丢弃所有这些累积的知识。 另一个优点是，它将烦人的问题(维护cobol应用程序)转变为有趣的问题(自动语言翻译)，因此您有机会让优秀的程序员参与项目。
|
