java转换为c#_将25k行C＃转换为Java的经验教训

最新推荐文章于 2024-08-26 13:49:18 发布

dnc8371

最新推荐文章于 2024-08-26 13:49:18 发布

阅读量556

点赞数

文章标签： java python 编程语言人工智能大数据

原文链接：https://www.javacodegeeks.com/2015/05/lessons-learnt-translating-25k-line-of-c-into-java.html

版权

java转换为c#

由于各种原因，我最近完成了一个将复杂的财务应用程序从C＃转换为Java的项目。港口的原因大部分是非技术性的，而是对相关企业的一项战略举措。

这是一次有趣的经历，我在此过程中吸取了一些经验教训，可以分享这些经验。

1.在现有系统上构建语言中立的测试。

我将从最重要的一课开始。移植系统时，由于任何原因这可能是任何端口，因此必须具有确定该端口是否成功的标准。最好的方法是围绕原始系统构建一整套测试，这些测试可以“ 无需更改即可导出”到新系统。因此，例如，如果要将系统从Java迁移到不支持JUnit的另一种语言，则没有一套JUnit测试是不好的。我无法强调在没有干预的情况下将测试的更改从字面上从旧系统复制到新系统有多么重要。

JUnit测试的另一个问题是它们通常与现有的实现紧密地联系在一起。由于将要重写实现，因此测试无法在实现之间移植。

我们选择的并且非常有效的策略是使用Cucumber测试。几乎所有语言都有Cucumber的绑定，IDE（至少是IntelliJ和Visual Studio都）很好地支持了Cucumber，此外，该测试是人类可读的。这样，您可以让非技术用户参与测试的准备工作，以为端口做准备。（顺便说一句，我们试图通过记录旧系统所做的所有工作并围绕这些需求构建测试来让用户定义新系统的需求，但这不足为奇，这并不令人意外。基于构建测试用例要好得多而不是尝试为新系统发明它们！）。

使用Cucumber确实是成功的，每当系统之间存在差异时，我们都会创建一个新的测试。到完成时，我们已经有了大约1000种方案，我们对新系统的正确性充满信心。它为我们提供了坚实的基础，我们需要继续开发新系统中的其他功能和重构。

2.尝试并使尽可能多的翻译自动化。

当面对超过25k行的C＃时，考虑将每行手动转换为Java是一件非常艰巨的任务。幸运的是，那里提供了非常有用的工具。我们使用的产品来自有形软件解决方案。花了几百美元，它实际上节省了数百个工时。无论如何它都不是完美的，但是它将为您提供Java代码的结构（部分代码允许将C＃中的类的代码拆分为多个文件），并尝试了使您可以使用的Java。

在我们的案例中，几乎没有任何生成的代码可以实际编译，但这确实是一个很好的起点。我的类比是OCR的早期尝试。您可以扫描文档，但是当您在编辑器中打开文档时，会发现许多未正确识别的单词带有红色下划线。这是要遍历所有红色底线并弄清楚单词应该是什么的问题。自动翻译产生的代码大同小异，当它被导入IDE时，会出现许多编译器错误。有时，自动化过程会保留在原始C＃中，并说无法自动完成翻译。值得称赞的是，该工具总是偏向于保守，它从未对所产生的Java犯错，这一点很重要。

3.不要着急翻译

运行自动翻译后，您将需要返回代码并手动修复编译错误。如果我有时间，我将花费10倍以上的时间来确保对代码所做的每一次更改都是绝对正确的。由于我不是C＃专家，所以有时我会假设C＃库的工作方式。这些假设并不总是正确的，有时我会付出沉重的代价来调试场景，如果我在原始译文中更加小心一点，就永远不会有问题。花时间阅读要翻译的类的C＃API绝对值得。我发现在使用Date和DateTime对象时，这一点特别重要。

花时间学习Visual Studio IDE也是值得的。并行调试时，如果您知道如何正确使用IDE，从长远来看将节省时间。

4.使用Java 8

除了使用Java 8的所有显而易见的原因（这是Java的最新版本，所以为什么不使用它……）之外，Stream API也可以很好地映射到C＃Linq。语法略有不同，例如Java使用'->'和C＃使用'=>' ，但是使用Java 8的新功能确实有助于保持代码的可比性，这在进一步调试时都很有帮助。

5.注意意外行为

语言的某些功能是您不应该依赖的，但可能会完全一样。让我举一个我花了太多时间的例子来说明。 C＃代码使用的是Dictionary ，代码生成器将Dictionary正确翻译为HashMap 。两者都是无序地图。但是，即使在Dictionary遍历Dictionary时没有按合同对Dictionary进行排序（也存在OrderedDictionary ），它似乎仍可以保留插入顺序。 HashMap并非如此，并且由于元素的顺序对于结果HashMap ，因此我们发现了难以调试的差异。解决方案是用确实保留顺序的LinkedHashMap替换HashMap所有实例。

6.不要过早重构

从代码生成器生成的代码不是很漂亮。实际上，要查看它几乎是可怕的，违反了有关命名约定等的几乎所有规则。随着时间的流逝，它很容易整理。抵制这种诱惑，直到所有单元测试都通过为止。您以后总是可以整理一下。重构（甚至重命名）可能会引入错误，尤其是在定义上您不熟悉的代码库中。同样，您可能决定在某个地方重新运行代码生成器，并且所有整理工作最好都需要合并，最坏的情况是浪费时间。