c# – 具有域知识的逆向工程VB6代码的最佳实践方法

我们将大型VB6 / ASP / COM应用程序重写为.NET(主要是C#)为生,我们开发了一个软件分析和重新设计工具来帮助我们实现这一目标.这个工具本质上就像一个VB6 / ASP / COM编译器和一个编写.NET代码的反编译器.当然,由于VB6平台与.NET非常不同,直接编译/反编译是不可取或不可行的,因此我们的工具有一个“分析器”,它实现了各种代码重组算法来处理VB6-C#不兼容性.还有一个可编程的“作者”,允许迁移团队规定设置.NET代码文件,重构代码以及使用.NET类替换COM API和ActiveX控件等规则 – 取决于团队需要什么或者想要.

作为编译和分析代码的副产品,我们的工具生成了一个正在升级的整个VB6 / ASP / COM系统的模型.该模型可用于生成有关系统内部结构的非常详细的报告.这些模型可用于帮助对代码进行反向工程 – 如果您知道要问的正确问题,并且您需要了解问题域以做好工作.

当然,一旦您拥有构建完整的.NET,您就可以使用各种分析和代码审查工具来处理程序集.某些版本的Visual Studio具有这些工具,并且有开源工具,如FxCop,NDepends).我还使用了一些非常棒的动态分析工具(EQUATEC Tracer).

最后虽然迁移团队很难确定任何未知系统.即使您停留在同一平台上,如果您不知道如何运行它以及如何设置/输入预期输入并查找/验证预期输出,您将无法证明应用程序是“正确的”.我们通常将此留给客户！

如果我们正在为客户进行验证,我们会严重依赖并排测试来验证系统的新版本 – 假设我们知道如何运行遗留应用程序,我们假设在给定相同的输入和用例的情况下应表现出相同的行为并产生相同的结果.我在单元测试圈听过这个批准测试.

我承认我们在很大程度上依赖于VB6 / COM代码是对系统数据结构和逻辑的完整,详细,正式和生产测试描述的知识,并且我们通过经过测试和重新测试的系统转换来提供这些信息.我们自1977年以来一直在开发编译器,我们在这个VB6 / ASP编译器上非常努力,以确保我们生成的.NET代码保留了原始VB6的语义.每次都不是100％ – 但它一直在变得越来越近.然后再次手工处理并不保证第一次尝试100％正确的代码…