问题标签 [legacy]

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

我们觉得我们有四种选择：

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

您认为对我们来说最好的选择是什么，为什么？

用于自动生成 Java 单元测试的最好的、最好是免费/开源的工具是什么？我知道，单元测试不能真正起到与记录和驱动系统设计的普通 TDD 单元测试相同的目的。但是，如果您拥有庞大的遗留代码库并想知道您需要进行的更改是否会产生不需要的、晦涩的副作用，那么自动生成的单元测试可能会很有用。

我们有一个 12 岁的 Ms Access 应用程序，用于我们的核心库存仓储和发票系统。它已经在 SQL Server 后端运行，但所有“逻辑”、表单和报告都在 Access 中。在经历了将库存交易从非临时性转变为临时性所花费的大量维护污泥之后，我意识到有一天我需要将这个东西转换为代码，这样我才能在一个更易于维护和可测试的环境中更好地管理逻辑。

有哪些技术可以让我以可管理和有效的方式将其转换为 .Net 应用程序？

一个想法是将查询转换为存储过程，然后将应用程序转换为 Adp 项目。但我仍然对如何处理表单和报告一无所知。

此外，如果这很重要，我是我公司唯一的开发人员。

任何有用的指标都可以

当您在遗留代码库中工作时，随着时间的推移，什么会对提高代码库的质量产生最大的影响？

• 删除未使用的代码
• 删除重复代码
• 添加单元测试以提高覆盖率低的测试覆盖率
• 跨文件创建一致的格式
• 更新第 3 方软件
• 减少静态分析工具（即Findbugs）产生的警告

多年来，该代码库由许多具有不同专业水平的开发人员编写，其中许多领域未经测试，有些无法测试，而无需花费大量时间编写测试。

.Net 的当前版本和更新版本不支持 windows 2000 对开发人员来说是否重要？

想到我的几个客户仍在使用 Windows 2000，我感到害怕，尽管我可能决定有一天停止支持 Windows 2000，但我不喜欢微软将它推向人们的产品。

谁能看到微软在未来使用 XP 来刺激 Vista 及更高版本的销售？

澄清一下，这绝不是对 MS 的抨击，我喜欢 MS，但这是一个真正的问题，我想对此发表意见。

相比之下，我看不到 C++0x 实现者说“它在 Windows 2000 上不起作用”

我真的很想说服自己我应该改用.Net，但这是我的担忧之一。

我希望能够（有效地）对数据库视图进行排序-我知道从概念上讲，数据库视图中的顺序是无效的，但是我有以下情况要处理：

• 第三方遗留应用程序，它使用 select(*) from tablename 语句从数据库表中读取数据
• 遗留应用程序对记录的顺序非常敏感
• 我编写的一个应用程序允许用户更轻松地管理表中的数据，但是从表中插入和删除自然会打乱记录的顺序。

将遗留应用程序中的语句更改为 select (*) from tablename order by field 将解决我的问题，但不是一个选项。

所以 - 我已经设置了一个临时表，数据可以以正确的顺序导出到其中，但这是一个资源匮乏的选项，意味着数据在遗留应用程序中不是“活的”，并且是额外的工作用户。

我希望能够获得具有这些约束的表格的有序版本。有什么想法吗？

更新 - 我正在使用 Sybase 12.5，但我想避免与特定 RDBMS 紧密耦合的解决方案 - 它可能会改变。

由于此 Wikipedia 条目中提到的 SQL 标准，我无法向视图添加“order by”子句

您将如何将相当大（>300K）、相当成熟的 C 代码库转换为 C++？

考虑到的 CI 被拆分为大致对应于模块的文件（即比典型的基于 OO 类的分解更细化），使用内部链接代替私有函数和数据，以及公共函数和数据的外部链接。全局变量广泛用于模块之间的通信。有一个非常广泛的集成测试套件可用，但没有单元（即模块）级别的测试。

我想到了一个总体策略：

1. 编译 C++ 的 C 子集中的所有内容并使其正常工作。
2. 将模块转换为巨大的类，以便所有交叉引用都由类名限定，但将所有函数和数据保留为静态成员，并使其正常工作。
3. 使用适当的构造函数和初始化的交叉引用将大类转换为实例；酌情用间接访问替换静态成员访问；并让它工作。
4. 现在，将项目作为一个错误因素的 OO 应用程序来处理，并在依赖项易于处理的情况下编写单元测试，并在它们不易于处理的情况下分解为单独的类；这里的目标是在每次转换时从一个工作程序转移到另一个工作程序。

显然，这将是相当多的工作。有没有关于这种翻译的案例研究/战争故事？替代策略？其他有用的建议？

注 1：该程序是一个编译器，可能有数百万其他程序依赖于它的行为不变，因此大规模重写几乎不是一种选择。

注意 2：源代码已有近 20 年的历史，每年可能有 30% 的代码流失（修改的行数 + 添加的行数/之前的总行数）。换句话说，它被大量维护和扩展。因此，目标之一是提高可维护性。

[为了这个问题，假设翻译成C++是强制性的，并且不能将其留在 C中。添加此条件的目的是清除“将其保留在 C 中”的答案。]

加入一个拥有庞大代码库的现有团队可能会令人生畏。什么是最好的方法；

• 广阔; 尝试从代码中大致了解所有内容如何链接在一起
• 狭窄的; 一次专注于一小段代码，了解它们是如何充分工作的
• 选择一个功能来开发和学习
• 尝试从类图和 uml 中获得洞察力，如果可用（并且是最新的）
• 完全不同的东西？

我正在研究目前大约 20k 行的 C++ 应用程序和库（编辑：在宏伟的计划中很小！）。在行业中，我想您会得到一位经验丰富的程序员的介绍。但是，如果不是这种情况，您可以做些什么来尽快开始增加价值？

--
答案总结：

• 在调试模式下单步执行代码以查看它是如何工作的
• 与比您更熟悉代码库的人配对，轮流担任编码人员和观看/讨论的人员。在团队成员中轮换合作伙伴，以便知识传播。
• 编写单元测试。从你认为代码如何工作的断言开始。如果结果如您所料，您可能已经理解了代码。如果没有，你有一个难题要解决和/或进行调查。（谢谢Donal，这是一个很好的答案）
• 以与上述类似的方式检查功能代码的现有单元测试
• 阅读 UML、Doxygen 生成的类图和其他文档以全面了解代码。
• 进行小的编辑或错误修复，然后逐步建立
• 记笔记，不要跳进去开始开发；花时间理解比生成混乱或不适当的代码更有价值。

这篇文章是the-best-way-to-familiarize-yourself-with-an-inherited-codebase的部分副本

我的问题与之前提出的问题非常相关，但我需要一些实用的建议。

我手中有“有效地使用遗留代码”，并且在我正在从事的项目中阅读这本书时，我正在使用书中的建议。该项目是一个 C++ 应用程序，由几个库组成，但代码的主要部分被编译为单个可执行文件。当我不得不触摸某些东西时，我正在使用 googletest 将单元测试添加到现有代码中。

我的问题是如何设置构建过程以便构建单元测试，因为有两个不同的可执行文件需要共享代码，而我无法将代码从“被测”应用程序中提取到库中。现在我已经为包含单元测试链接的应用程序创建了我的构建过程，该链接针对从主应用程序的构建过程生成的目标文件，但我真的不喜欢它。有什么建议吗？