“语言转换器”的经验?

在我看来,与MS-Access问题中的情况几乎总是一样,带有标签的问题吸引了更广泛的StackOverflow人群,回答的人在这里遗漏了关键问题,我将其理解为:

是否有任何工具可以成功地将访问应用程序转换为任何其他平台?

答案是

绝对不是

原因很简单,同一个系列中为UI对象使用类似模型的工具(例如,vb6)缺少默认情况下Access提供的许多功能(如何将Access Continuous子窗体转换为vb6而不丢失功能?).而其他平台甚至没有与VB6和Access共享相同的核心模型,因此这些平台还有更多的障碍需要解决。

引用的MySQL文章非常有趣,但它确实混淆了不合格开发的应用程序所带来的问题与正在使用的开发工具所带来的问题。糟糕的数据模式不是访问固有的——它是[大多数]新手数据库用户固有的。但是这些文章似乎把这个问题归因于访问。

并且完全忽略了修复模式、将其升级到MySQL和保持前端访问的可能性,这是迄今为止解决问题最简单的方法。

这正是我所期望的,对于那些没有访问权限的人来说——他们甚至不认为访问作为安全的、大容量服务器数据库引擎的前端可以是解决这个问题的一个更好的解决方案。

这篇文章甚至没有真正考虑到访问应用程序的转换,这是有充分理由的。我看到的所有声称要转换访问应用程序(到任何平台)的工具要么什么都不转换,只转换数据(在这种情况下,它们根本不转换应用程序——白痴!)或者通过访问应用程序和目标应用程序中的UI对象之间的1:1对应关系,轻松转换前端结构。

这不管用。

Access的应用程序设计是特定于自身的,其他平台不支持相同的功能集。因此,必须将访问特性转换为转换后的应用程序中原始特性的工作替代品。在我看来,这不是一种可以自动完成的事情。

第二,当考虑在Web浏览器中转换一个用于部署的访问应用程序时,整个应用程序模型是不同的,即从有状态到无状态,因此,不支持的访问功能不仅仅是几个问题,而是UI对象如何与数据交互的一个完全不同的基本模型。也许一个100%未绑定的访问应用程序可以相对容易地转换为基于浏览器的实现,但是有多少呢?这意味着一个不使用任何子窗体的Access应用程序(因为它们不能被解除绑定),以及一个仅使用富事件模型中的少量事件的应用程序(其中大多数只使用绑定的窗体/控件)。简言之,100%未绑定的访问应用程序将是一个反对整个访问开发模式的应用程序。任何人如果认为他们想要在Access中构建一个未绑定的应用程序,就不应该首先使用Access,因为整个访问点都是绑定的表单/控件!如果您消除了这一点,那么与其他开发平台相比,您已经放弃了Access的大部分RAD优势,并且几乎没有任何回报(除了巨大的代码复杂性)。

要在Web浏览器中构建用于部署的应用程序,以完成与访问应用程序相同的任务,需要从头重新设计应用程序UI和工作流。由于成功的访问应用程序模型与成功的Web应用程序模型是对立的,因此没有转换或转换可以工作。

当然,所有这些都会随着Access 2010和带有Access Services的SharePoint Server 2010而改变。在这种情况下,您可以在Access中构建应用程序(使用Web对象),并部署到SharePoint上,以便用户在浏览器中运行它。结果在功能上是100%等效的(视觉上是90%),并在所有浏览器上运行(此处没有特定于IE的依赖项)。

因此,从今年6月开始,将Access应用程序转换为在浏览器中部署的最便宜方法可能是升级到A2010,将设计转换为使用所有Web对象,然后使用SharePoint部署。这不是一个简单的项目,因为与客户端对象相比,Access Web对象的功能有限(例如,没有vba,所以您必须学习新宏,它比旧宏更强大、更安全,因此对于熟悉Access的旧宏的人来说,这不是一个可怕的困难),但它可能会喜欢与在Web上部署的全面重新设计相比,ELY的工作要少得多。

另一件事是,它不需要对最终用户进行任何再培训(只要Web对象版本与原始客户端版本相同),因为它在访问客户端中与Web浏览器中相同。

所以,简而言之,我认为转换是一个奇美拉,几乎总是不值得努力。事实上,我同意被引用的观点(即使我对来自那个来源的其他评论有很多问题)。但我也要注意的是,转换的愿望往往是错误的,错过了更便宜、更简单、更好的解决方案,这些解决方案不需要从上到下大规模更换接入应用程序。通常情况下,对jet/ace作为数据存储的不满意会使人们误以为他们也必须替换访问应用程序。事实上,许多用户开发的访问应用程序都充满了可怕的、不可修复的妥协,并与口香糖和捞线绑在一起。但是,一个设计糟糕的访问应用程序可以与后端数据模式的升迁和远景结合起来加以改进——不必丢弃它。

这并不意味着 容易的 --通常不会。正如我一直告诉客户的那样,建造新房子通常比改造旧房子容易。但我们改造旧房子的原因之一是它们具有我们不想失去的不可替代的特性。通常情况下,访问应用程序隐式地包含了许多业务规则和工作流建模,而这些规则和工作流不应在新应用程序中丢失(旧的Netscape难题,Pace Joel Spolsky)。对于试图移植到不同平台的外部开发人员来说,这些事情可能并不明显,但对于最终用户来说,如果应用程序产生的结果与旧应用程序相比只差一分钱,他们会不高兴(而且可能应该是,因为这可能意味着应用程序的其他方面也不会产生可靠的结果)。

不管怎样,我漫谈了太久,但我的观点是,除了最普通的应用程序(或者设计用于转换的应用程序,例如100%未绑定的访问应用程序),转换永远不会起作用。我完全赞成用修订代替替换。

但是,当然,这就是我的生活方式,也就是修复接入应用程序。

尝试?不,实际构建的(多个)语言转换器。

这是我(和我的同事)为 B2 Spirit Stealth Bomber 要将任务软件转换成可维护的C代码,使用传统语言jovial进行编码,并进行100%的自动转换。其中一个要求是我们不允许看到实际的源代码。不是开玩笑。

你是对的:如果你只得到一个中高的转化率(如70-80%),完成转化的努力仍然是非常重要的,如果你确实可以做到的话。我们的目标是95%以上,并且在被告知更努力尝试时做得更好,就像B2的情况一样。人们接受中高速率转换器的唯一原因是他们找不到(或不会出资!)一个更好的,坚持开始 现在 接受这样一个事实:用这种方式转换它可能会很痛苦(通常他们不知道有多痛苦),但实际上比从头开始重建它要痛苦得多。(我恰好同意这一评估:一般来说,尝试从头开始对大型系统重新编码的项目通常会失败,而使用中高转换率工具的转换没有那么高的失败率。)

有很多不好的转换工具,一些东西加上大量的Perl代码在文本字符串上执行regex,或者一些基于yacc的解析器(代码生成基本上是针对编译单元中的每个语句一对一)。前者是由那些从天而降的人建造的。后者通常是由没有良好编译器背景的善意工程师构建的。

对于一个非常糟糕的例子,请看我对这个关于COBOL迁移的问题的回答: Experience migrating legacy Cobol/PL1 to Java ,这正是一个直接语句转换程序…生产产生“jobol”一词的物质。

要获得如此高的精度转换率,您需要高质量的解析器,这意味着要构建高质量的翻译规则,以保留语义,并针对目标语言属性和特殊情况进行优化。本质上,您需要相当于可配置编译器技术的东西。我们成功的原因是 DMS Software Reengineering Toolkit 是为完成这项工作而设计的。(我是建筑师;查看我的SO图标/BIO)。

很多仔细的测试也有帮助。

DMS“知道”编译器对代码的了解,因为它有一个类似于感兴趣的语言前端的编译器,并且能够构建AST、符号表、控制和数据流、调用图。它使用了编译器社区过去半个世纪发明的大部分编译器技术, 因为这些东西在翻译中已经被证明是有用的!

DMS知道 更多 大多数编译器都不知道,因为它可以一次读取/分析/转换整个应用程序;大多数编译器只使用单个编译单元。因此,可以对依赖于整个应用程序的翻译规则进行编码,而不只是对当前语句进行编码。我们经常添加特定于问题或应用的知识来改进翻译。这通常在转换语言的特殊特性或调用库时出现,在这种情况下,必须将库调用识别为特殊的习语,并将它们转换为对目标库和语言构造的组合的调用。

此功能用于构建翻译器(例如Jovial翻译器)或特定于域的代码生成器。

我们通常会构建复杂的自动化软件工程工具,以解决特定于客户的问题,例如程序分析工具(死代码、重复代码、样式中断代码、度量、体系结构提取等)和大规模更改工具(平台[非langauge]迁移、数据层插入、API替换等)。

影响跨语言转换成败的几个问题是语言及其语义模型的相对语义丰富性。

• 从C++到C的翻译应该比较容易,但是C到C的转换 惯用的 C++几乎是不可能的,因为这几乎不可能自动将过程程序转换为面向对象程序。

• JAVA到C的翻译将相对简单,尽管处理存储管理将是混乱的。如果C程序在整数和不同类型的指针之间做了时髦的指针运算或铸造,那么C到Java的翻译几乎是不可能的。

• 将一种功能性语言翻译成命令式语言要容易得多,尽管结果可能是低效的,非惯用的。将一种命令式语言翻译成一种功能性语言可能已经超出了技术水平。除非您在函数语言中为命令式语言实现了一个解释程序。

这意味着有些翻译人员 必要地 在以下方面会比其他人更成功:

• 翻译的完整性和准确性,以及
• 结果代码的可读性和可维护性。

Things You Should Never Do, Part I Joel Spolsky

“…他们犯了任何软件公司都能犯的最严重的战略错误:

他们决定从头重写代码。”

我有一个 list of MS Access converters on my website . 在我每天阅读的与访问相关的新闻组的任何帖子中,我从来没有听说过任何关于它们的好消息。我每天都读很多帖子。

还请注意,在访问中有大量的功能,例如绑定的连续表单或子表单,这些功能在其他系统中复制时需要做更多的工作。不一定很多工作,但更多的工作。在发布和安装应用程序的时候会遇到更多的麻烦。

我使用了一个从C到Visual Basic.net的自动转换器。除了增加一些不必要的 If True 声明。

我也尝试过使用 Shed Skin 转换python-to-c++,但由于缺乏对新样式划分的支持,它没有工作。

我已经使用了工具将一个vb6项目转换成vb.net——你希望这可能是此类事情的一个简单例子。我的经验是,所有的东西都必须仔细检查,而且有一半是丢失/错误的。

当然,我建议您手动迁移,或者根据您的目标语言,如果这给您一个对代码库进行重大改进的机会,我将考虑完全重写。

马丁

我只试过免费和基本的付费转换器。但主要的问题是,很难有信心,转换是完全成功的。

通常,它们最好一次用于手工转换代码部分,在这里您可以查看每段代码。根据我的经验,重写而不是转换通常是更好的选择。