在我们公司,我们开发和销售VB6应用程序,我们认为现在是时候将其迁移到.Net了.

主要原因是：

>我们希望VB6运行时支持在某个时间点结束,我们不想在那时开始迁移,因为它可能会是一个漫长的过程.
>剩下的只有1 1/2 VB6开发人员.半个是我.
>越来越多的客户要求提供云和移动设备支持等功能.

我知道从头开始重写应用程序是迁移到.Net的最不推荐的方法.我完全赞同这一点！抛弃十多年的代码感觉是错误的,浪费金钱,我很难向我们的管理层推荐和证明它.

但是现在我没有看到另一种方法.

让我告诉你一些关于应用程序的信息：

就像我说它已经发展了十多年.已经有很多开发人员在开展这项工作,其中大多数都是当时没有经验的.我们从最初的团队中留下了一名开发人员.该应用程序是他的第一个也是最大的软件项目,到目前为止,他意识到过去15年中做出的许多架构决策都是错误的,其他人当时是正确的,但没有进行重构以满足其他部分的变更.应用程序等在某个时间点变得错误.此应用程序似乎是代码腐烂的展示示例.

我们正在谈论大约150个KSLOC的应用程序,所有这些都在一个可执行文件中.它使用大约15个外部DLL,其中一些是第三方ActiveX控件,其中一些是我们自己的.Net程序集.

向应用程序添加新功能仍然可以完成,但与我们的其他.Net应用程序相比需要很长时间.原因是代码库中的每一个小变化都需要在整个地方进行更改.改变是可能的唯一原因是因为一个开发人员只知道应用程序的大部分依赖性和怪癖.您可能已经猜到了意外副作用和错误率非常高.

我首先考虑迁移该应用程序是首先清理和重构,然后使用Artinsoft / Microsoft / WhoEver中的工具进行迁移/转换,然后再次重构以获得一个漂亮而干净的.Net应用程序.

但我看到一些问题：

>似乎没有办法重构旧的应用程序.没有任何自动化测试,甚至没有正式的手动测试方法.每一个小小的变化都需要经验丰富的用户进行手动测

>另一方面,我已经建立了一个用于测试.Net应用程序的过程和工具集,这为我们提供了重构的坚实基础

>将代码转换为.Net而不进行重大修改感觉就像：垃圾进入,垃​​圾进出.虽然我讨厌调用旧的应用程序垃圾,因为它以某种方式工作并证明它本身很有用.
>我们的管理层习惯于明确要求快速和肮脏的解决方案,无视其对生产力的影响以及开发团队的所有建议,这些建议在某些时候开始否认存在快速和肮脏的解决方案以便能够做正确的事.这并不意味着我们改进功能,但我们确实包括编写测试的时间并在我们的估算中进行重构.所以知道这一点,我怀疑一旦代码转换为.Net并修复到应用程序启动并且似乎正常工作的点,重构阶段将被取消,应用程序将被运送给一些客户.

所以.我认为,尽管从头开始重写需要花费大量的时间和资源,但它仍然是我们唯一的选择.

我错过了一个选项吗？您是否看到不必重写该应用程序的可能性？

最佳答案 我建议你退后一步,阅读Brian Foote& Joseph Yoder(伊利诺伊大学).它提供了一些建筑洞察力,可以解决您遇到的问题以及解决问题的方法.它的标题是“泥球大球”(请不要笑,这是一篇严肃的论文).这是摘要：

While much attention has been focused on high-level software
architectural patterns, what is, in effect, the de-facto standard
software architecture is seldom discussed. This paper examines the
most frequently deployed architecture: the BIG BALL OF MUD. A BIG BALL
OF MUD is a casually, even haphazardly, structured system. Its
organization, if one can call it that, is dictated more by expediency
than design. Yet, its enduring popularity cannot merely be indicative
of a general disregard for architecture.

These patterns explore the forces that encourage the emergence of a
BIG BALL OF MUD, and the undeniable effectiveness of this approach to
software architecture. In order to become so popular, it must be doing
something right. If more high-minded architectural approaches are to
compete, we must understand what the forces that lead to a BIG BALL OF
MUD are, and examine alternative ways to resolve them.

A number of additional patterns emerge out of the BIG BALL OF MUD. We
discuss them in turn. Two principal questions underlie these patterns:
Why are so many existing systems architecturally undistinguished, and
what can we do to improve them?

顺便说一句,我认为您最好的选择是使用当前的应用程序作为您的要求,并使用适当的设计重写VB.NET或C#中的所有内容.