什么时候应该将旧应用程序移植到新平台？
我在一家公司工作，该公司拥有用 VB6 编写的成熟应用程序。应用稳定，持续为公司提供良好的收入。然而，它已经开始显得过时了，并且有人提出将其移植到更现代的平台（例如.Net）上。
由于这几乎不是一个简单的决定，因此我希望在何时是将长期存在的应用程序移植到现代平台的好时机提供意见。
我已经研究过的一些优点和缺点：
有利于移植
- 寻找旧编程语言的技能变得更加困难和昂贵
- 平台供应商的支持在某个时候结束
- 利用现代编程实践旧平台变得更难或不可能
- 重写提供了改进现有实践的机会
- 迁移到现代平台可以激励开发团队
- 迁移到现代平台提供了营销机会
反对移植
- “如果它没有损坏，就不要'重写
- 的成本与回报
- 与从旧应用程序过渡到新应用程序相关的风险
- 提高现有软件工程师的技能
一些相关的 StackOverflow 问题：
I'm working for a company that has an established application written in VB6. The application is stable and continues to provide the company with good income. However, it is beginning to show its age and noises are been made to port to a more modern platform such as .Net.
Since this is hardly ever a cut and dry decision I would appreciate input on when it is a good time to port a long standing application to a modern platform.
Some of the pros and cons that I have already worked through:
In favor of porting
- Finding skills for an old programming language becomes harder and more expensive
- Support from the platform vendor ends at some point
- Leveraging modern programming practises on the old platform becomes harder or impossible
- Rewriting provides the opportunity to improve existing practises
- Moving to a modern platform is motivating for the development team
- Moving to a modern platform provides marketing opportunities
Against porting
- "If its not broken don't fix it"
- The cost of rewriting versus the return
- Risks associated with the transition from the old to the new application
- Upskilling existing software engineers
Some related StackOverflow questions:
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
需要考虑的事情之一是，随着时间的推移，移植应用程序的成本可能会变得越来越高。我见过用“古老”语言编写的应用程序，而且开发得非常好。但是，正如很多次发生的那样，所有领域知识都在代码和开发人员的头脑中，而不是在最新的文档中。
因此，在这种情况下，移植不仅意味着用新的闪亮语言重写，还意味着对规范进行逆向工程，并挑选开发人员的大脑（希望可用）。随着时间的推移，这变得越来越难。
另一件事是“移植”并不像迁移向导希望我们相信的那么容易。许多向导产生了一个半生不熟的解决方案，该解决方案仍然是根据“遗留”环境常见的构造和功能构建的，并且几乎不会使用新的功能和可能性。这可能看起来并没有那么糟糕，但如果你将其保留在这个级别，实际上会让了解“新”语言的开发人员很难理解代码，并使移植到下一个平台或语言变得更加困难。这就是我所说的大写字母“LEGACY”。几十年来一直拖着无用的东西。
从开发人员的角度来看，开始移植的最佳时机是昨天。
从经理的角度来看，开始移植的最佳时机是明天。
从竞争对手的角度来看，开始移植的最佳时机永远都不是。
One of the things to consider is that porting an application can get more and more expensive over time. I have seen applications writen in 'ancient' languages that were very well developed. But, as happens many times, all the domain knowledge was in the code and in the heads of the developers, not in up-to-date documents.
So in situations like this porting means not only rewriting in the new sparkly language but also reverse-enginering the specs and picking the, hopefully available, brains of the developers. This becomes harder and harder over time.
An other thing is that 'porting' is hardly ever as easy as the Migration Wizard want us to believe. Many wizards produce a half-baked solution that is still constructed according to the constructs and features common to the 'legacy' environment and will hardly be using the new features and possibilities. This might not seem that bad but if you leave it at that level you are in fact making it very hard for developers that know the 'new' language to understand the code and make porting to the next platform or language even harder. That is what I call LEGACY in capitals. Dragging useless stuff around for decades.
The optimal moment to start porting, from a developer's point of view, was yesterday.
The optimal moment to start porting, from a manager's point of view, is tomorrow.
The optimal moment to start porting, from a competitor's point of view, is never.
还有很多其他考虑因素需要评估：机会成本（我们还能做什么）、可扩展性和增长的能力（应用程序还需要做什么/成为什么）、其他移动部件的可持续性（数据库升级、操作系统升级） ）等等。这样的例子不胜枚举。
具体到 VB6，我将评估产品进展与升级到当前 .Net 框架相比有哪些限制。问问自己——这真的是“如果”场景还是“何时”场景？
从一般角度来看，移植应用程序的最糟糕时间是当您必须移植它时。您的情况听起来像是开始代码迁移的理想时机——在它成为必要之前。考虑到您的遗留产品对您公司的盈利能力，任何您被迫迁移的情况都会带来截止日期、范围等方面的压力。
考虑到所有因素，您的情况听起来像是移植到 .Net Framework 的理想时机，嗯在有必要之前。
There are a lot of other considerations to evaluate: opportunity cost (what else could we be doing), capacities for extensibility and growth (what else does the application need to do/be), sustainability with other moving parts (DB upgrades, OS upgrades), etc. The list goes on and on.
Specific to VB6, I would evaluate what limitations are in the way of product progress vs. moving up to the current .Net framework. Ask yourself -- is this really an IF scenario, or a WHEN scenario?
From a general standpoint, the worst time to port an application is when you HAVE to port it. Your situation sounds like an ideal time to begin code migration -- before it becomes a necessity. Given your legacy product's profitability for your company, any situation where you're forced to move to migrate brings pressures around deadlines, scope, etc.
All things considered, your situation sounds like an ideal time to port up to the .Net Framework, well before it becomes necessary.
呼应jro，尤其是Erno，
没有一个有能力的开发人员会接受纯粹的移植工作，这不是一个职业提升的举动。但现有的开发人员将很乐意学习最新的框架作为移植工作的一部分。
VB6 于 1998 年发布。2008 年 3 月 31 日 Microsoft 终止了所有 VB6 支持。公司已经因为这个代码而陷入了危险区域，这并不好笑。
补充一点，
在某个时候，该公司将被迫升级应用程序，因为操作系统将不再支持 api。
你应该离开这家公司。留下来就是职业生涯的死亡。
更新，因为科迪认为“我是一名个人开发人员”：
@Cody - 重新思考你的假设。我经营自己的公司。毫无疑问，每次我们落后于平台的最后一个稳定版本时，追赶都是非常痛苦和昂贵的。最新的痛点是我们使用 dojo 0.4.3 和 Tapestry 4。T4 和 dojo 0.4.3 具有相互依赖关系，我们正在（慢慢地）分离。迁移到 Tapestry5 和/或 jquery 甚至只是迁移到更新版本的 dojo 非常缓慢且非常痛苦。移植花了一年多的时间，因为它必须是一个漫长的过程才能保持其他开发的顺利进行。
选择是：
永远（与周围的问题
寻找/吸引人才），
port
到目前为止，我们一直在结合#2 和#3。
使用旧版本的道场或挂毯意味着我们失去了社区支持我们并帮助我们解决问题的能力。框架的优点是其他人所做的工作可以解决你的问题。没有人再解决任何 VB6 问题。 微软甚至不会花钱来解决 VB6 问题。
OP 的公司完全靠自己。注意：Google 在 VB6 发布的那一年刚刚成立。我怀疑 VB6 知识已经从网络上消失，并且每年在 Google 上搜索 OP 公司提出的任何编程问题时，返回的结果会越来越少。
这是一个商业可行性风险。
关于 MS 永远支持 VB6 的愉快谈论并不是一个好主意。只需要微软的一些高级副总裁说：“如果团队不必修复这些仅影响 VB6 的问题，我们就可以在圣诞节前及时发布下一个 Windows 版本。我们稍后会发布一个 Service Pack。”在某些时候，这可能而且将会发生。
竞争对手可以使用最新的工具更快地推出竞争产品（因为使用最新的框架时可以使用大量的库。）OP 的公司已经失去了灵活的能力，因为最新的工具和库不再支持 VB6 。 （一个 13 年前的框架！！）
这是另一个业务可行性风险。
事实上，这需要向任何人解释，这对于任何正在面试的有任何经验的开发人员来说都是一个巨大的警告标志在OP的公司。
这极大地降低了人才库的质量和数量。
无法吸引优质人才是另一个商业风险。
原来的 OP 应该放弃。
不仅仅是 Microsoft，Windows 也会支持该应用程序。打印机之类的东西呢？或显示？ Epson 没有义务发布支持 VB6 应用程序的打印机驱动程序。
看到弹出的警告对话框、无法打印、不能很好地使用最新的显示器等都会导致客户悄悄转向竞争对手。他们甚至懒得告诉OP的公司他们正在这样做。
OP 应该在裁员到来之前继续前进。
Echoing jro and especially Erno,
No competent developer will accept a pure porting job, it is not a career enhancing move. But the existing developers will be happy to learn the latest framework as part of a porting effort.
VB6 was released in 1998. March 31, 2008 Microsoft EOL'ed all VB6 support. Your company is so far into the danger zone with this code, it isn't funny.
To add some perspective,
At some point, the company will be forced to upgrade the app because the operating system will no longer support the apis.
You should leave this company. It is career death to stay.
Update because Cody thinks "I am an individual developer":
@Cody -- Rethink your assumptions. I run my own company. Without fail, every time we have slipped behind the last stable release of a platform, catching up has been incredibly painful and expensive. The latest pain point is we are on dojo 0.4.3 and Tapestry 4. T4 and dojo 0.4.3 have this mutual interdependency that we are separating (slowly). Moving to Tapestry5 and/or jquery or even just to the more recent version of dojo is very slow and very painful. The porting has taken over a year because it has to be this long stretched process to keep other development moving along.
The choices are :
forever (with the problems around
finding/attracting talent),
port
So far we have been doing a combination of #2 and #3.
Being on old version of either dojo or tapestry means that we have lost the ability of the community to support us and help us with the problems. The advantage of a framework is that other people are doing work that solves your problems. Nobody is solving any VB6 problems any more. Microsoft will not even take money to solve VB6 problems.
The OP's company is completely on their own. Note: that Google was just founded the year VB6 was released. I would suspect that VB6 knowledge has been disappearing from the web and that each year a Google search about any programming problem the OP's company makes will return fewer and fewer results.
This is a business viability risk.
The happy talk about MS supporting VB6 forever and ever is not a good idea. All it takes is some SVP at Microsoft saying: "We can ship the next Windows version in time to make Christmas if the teams do not have to fix these issues that affect only VB6. We will issue a Service Pack later." At some point this can and will happen.
A competitor can come along and introduce a competing product using the latest tools faster ( because the large pool of libraries available when using the latest frameworks.) The OP's company has lost the ability to be nimble because the latest tools and libraries no longer support VB6. (A 13! year old framework!!)
This is another business viability risk.
The fact that this needs to be explained to anyone is a huge, huge warning flag to any developer with any experience who is interviewing at the OP's company.
This reduces the quality and quantity of the talent pool enormously.
Not being able to attract quality talent is another business risk.
The original OP should bail.
Its not just Microsoft and will the Windows support the app. What about things like printers? or displays? Epson is under no obligation to release printer drivers that support a VB6 application.
Seeing a warning dialog popup, not being able to print, use the latest display well, etc will result in customers quietly moving to competitors. They will not even bother to tell the OP's company that they are doing this.
The OP should move on before the layoffs hit.