什么时候将旧应用程序移植到新平台?

Ric*_*man 2 legacy port

我正在为一家拥有用VB6编写的已建立应用程序的公司工作.申请稳定,并继续为公司提供良好的收入.然而,它开始显示它的年龄,并且已经发出声音来移植到更现代的平台,例如.Net.

由于这几乎不是一个切割和干燥的决定,我会很感激在何时将长期应用程序移植到现代平台的时候.

我已经完成的一些优点和缺点:

支持移植

  • 寻找旧编程语言的技能变得更难,更昂贵
  • 平台供应商的支持在某个时候结束
  • 在旧平台上利用现代编程实践变得更加困难或不可能
  • 重写提供了改进现有实践的机会
  • 迁移到现代平台是激励开发团队的动力
  • 迁移到现代平台提供营销机会

反对移植

  • "如果没有破坏就不解决它"
  • 重写成本与回报成本
  • 与从旧应用程序到新应用程序的转换相关的风险
  • 提升现有软件工程师的能力

一些相关的StackOverflow问题:

Ern*_*rno 5

需要考虑的一件事是随着时间的推移移植应用程序会变得越来越昂贵.我看过用非常发达的"古代"语言写的应用程序.但是,正如多次发生的那样,所有领域知识都在开发人员的代码和头脑中,而不是在最新的文档中.

因此,在这样的情况下,移植不仅意味着重写新的闪亮语言,而且还反向引入规范并挑选开发人员的大脑,希望可用的大脑.随着时间的推移,这变得越来越难.

另一件事是"移植"几乎不像迁移向导让我们相信那么简单.许多向导生成一种半生不熟的解决方案,仍然根据"遗留"环境中常见的结构和特征构建,并且很难使用新功能和可能性.这可能看起来并不那么糟糕但是如果你把它放在那个级别,你实际上使得了解"新"语言的开发人员很难理解代码并且更难以移植到下一个平台或语言.这就是我在首都所说的LEGACY.几十年来拖着无用的东西.

从开发人员的角度来看,开始移植的最佳时刻是昨天.

从管理者的角度来看,开始移植的最佳时机是明天.

从竞争对手的角度来看,开始移植的最佳时机永远不会.

  • 不,我的意思正是我写的.我看到软件发行商通过推迟移植和陷入旧平台而失去了竞争对手.因此,您的竞争对手会希望您坚持使用当前的平台.我的观点是移植不是浪费精力. (2认同)