如何防止你的代码过时？
这里的一些程序员一直在用 VB6 开发一个项目，他们说如果他们希望他们的应用程序在更新/未来的系统上运行，他们现在需要升级到 vb.net，因为 vb6 很快就会成为历史。
因此，他们一直在开发一个巨大的应用程序，他们将不得不从头开始重建（他们尝试使用升级向导，但出现了太多错误）
公司所有者对于投入这么多时间并不太兴奋在一个项目中，只需转身并从头开始重做。
这不是我的项目，我对 vb 一无所知，我是一名网络程序员。
但这些人能做什么，才能让这种情况不再发生，或者他们应该做什么，才能让这不再成为问题？
有没有某种方法可以确保您的应用程序始终可扩展并且不会过时并需要重新编写？
谢谢！
Some programmers here have been developing a project in VB6, and they say they now need to upgrade to vb.net if they want their apps to run on newer/future systems as vb6 is going to be history soon.
So there is this huge application they have been working on that they are going to have to rebuild from scratch (they tried to use the upgrade wizard but there were too many errors)
The owner of the company is not too thrilled about investing so many hours in a project just to have to turn around and redo it from scratch.
This isn't my project and I don't know anything about vb, I am a web programmer.
But what can these guys do, so that this doesn't happen again, or what should they have done so that this wouldn't be an issue now?
Is there some way to make sure your application is always scalable and wont become obsolete and need to be re-written?
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（13）
不，确实没有什么，虽然Windows 7仍然可以运行DOS程序，所以他们的程序不会无法运行。他们将遇到的最大问题是没有新的支持或新功能，以及该主题的知识社区不断缩小。
我的公司目前正在运行 Fortran、Clipper、VB6 和 FoxPro 等程序，其中一些程序已经存在了 20 多年，并且在所有 Windows 升级中毫发无伤。通常导致旧程序无法使用的原因是无法重新编译程序来修复错误。
不过，它确实有助于分解程序的功能，因此，如果您决定从 VB6 迁移到 VB .Net，则可以更轻松地挑选出可重用的代码。
Nope, there's nothing around it really, although Windows 7 can still run DOS programs, so it's not like their programs will be un-runnable. The biggest problem they will run into is no new support or new features, and a shrinking community of knowledge on the subject.
My company is currently running programs in Fortran, Clipper, VB6, and FoxPro to name a few, some of which have been around for over 20 years, and have survived all of the Windows upgrades unscathed. Usually the thing that renders an old program unusable is the inability to recompile the program to fix bugs.
It certainly helps though to break the functionality of your programs up so that if you do decide to migrate from VB6 to VB .Net it's a lot easier to pick out the reusable code.
很好的问题。
简而言之，答案是否定的。因为所有代码最终都会过时。
如果您使用 x86 汇编程序编写代码，那么它会持续一段时间。 C 代码也有很长的保质期。但问题是，由于多种因素，一项技术从组装机中抽象出来的次数越多，其保质期就越短。
Excellent question.
The short answer is No. Because all code will eventually become obsolete.
If you wrote code in x86 assembler then it would last a while. C code would have a long shelf-life too. But the problem comes with the more a technology is abstracted away from assembler the shorter its shelf life due to many factors.
不要使用专有语言。当然，库和平台可能会发生变化，但有趣的是，语言本身已经过时了。坚持使用 C、C++ 或任何拥有大量用户群的开源软件。即使维护者停止支持，它们也可能会存在一段时间 - 这意味着 Python、Ruby、Java 和可能 C#。我的水晶球在 C 和 C++ 之外并不是那么好，但有令人信服的理由让其他水晶球之一能够持续 20 到 50 年。
Visual Basic 很有趣，但从体系结构的角度来看，它所提倡的代码和 UI 的混合是很糟糕的。一个好的设计应该使更改后端、GUI 工具包和操作系统变得可行（不一定非常容易）。
你有点被一种语言所困，所以选择一种不局限于不断改变它的供应商的语言。
尝试阅读 Joel 的Fire and Motion。
Don't use a proprietary language. Sure the libraries and platform may change, but it's interesting that the language itself has become obsolete. Stick to C, C++ or anything with a large user base that is open source. These are likely to be around for a while even if the maintainers stop supporting it - this means Python, Ruby, Java, and possibly C#. My crystal ball isn't so good outside of C and C++ but there are compelling reasons for one of the others to last 20-50 years.
Visual Basic was fun, but the intermixing of code and UI that it promotes is terrible from an architectural point of view. A good design should make it feasible (not necessarily super easy) to change backend, GUI toolkit, and OS.
You're kinda stuck with a language, so pick one that isn't restricted to one vendor who is constantly changing it.
Try reading Fire and Motion by Joel.
考虑到编程技术的快速发展，过时是我们的应用程序正常生命周期的一部分。
我不太了解桌面/服务器应用程序，但是，在网络开发中，我们说 5 年长，例如 ^^
当然，可以更新、打补丁、更正、修复等等……但这样做通常会降低代码的质量和应用程序本身的质量——这意味着随着时间的推移，维护成本会越来越高;最后，重写所有内容可能意味着在维护上花费更少的钱。
Considering the fast evolution of technologies arround programming, becoming obsolete is part of the normal cycle of live for our applications.
I don't really know for desktop/server applications, but, in web-development, we say that 5 years is long, for instance ^^
Of course, it is possible to update, patch, correct, fix, whatever... But doing so generally tend to degrade the quality of the code and the quality of the application itself -- meaning maintenance will cost more and more as time passes ; in the end, re-writing everything will probably mean spending less money in maintenance.
正如其他人所说，这不是“我的应用程序如何不被淘汰”。更多的是“当我的应用程序过时时，我如何快速恢复”。实际上，这只是其他问题的不同版本：
这就是 OO 和 SOA 试图回答的问题。构建许多小型独立应用程序，并使用标准机制将它们松散地耦合在一起。当您出于某种原因需要升级时，请将其拔出，升级，然后重新插入。
As other have said, it's not "how can my application not be made obsolete." It's more "when my application becomes obsolete, how can I recover quickly." And really, that's just a different version of other questions:
This is what OO and SOA was attempting to answer. Build lots of small independent applications, and loosely couple them together using a standard mechanism. When you need to upgrade for whatever reason, pull it out, upgrade, and plug it back in.
我不知道有任何公认的方法可以防止未维护的应用程序过时。应用程序。
如果您想防止产品过时，那么将其设计为可升级。
至少在 .NET 中，您有很多很多选项来创建可重用组件：
独立的程序集，可以在任何 .NET 项目中使用，并且可以在以后扩展以支持 COM 互操作（如果需要使用不同的技术。
网络服务；这些可以公开公开并在几乎任何环境中使用。
接口和控制反转可用于支持可自由互换的组件，理论上这些组件可能来自 .NET 以外的组件（只需构建一个 COM 包装器）；
进程间通信 - 如果其他方法都失败，您实际上可以创建一个内存映射文件或命名管道，并开始从（或目的地）全新应用程序中收集数据。
事实上，其中许多内容可能适用于您当前的 VB 项目。通常有多种不同的方法可以延长现有产品的使用寿命，同时逐渐将核心功能转变为新技术。
我不是 SOA 的铁杆支持者，但这正是 SOA 试图解决的问题。我做了很多服务 - 事实上，这里几乎所有重要的事情都会在某个时候通过某种 Web 服务 - 并且我很放心地知道我可以随时完全删除某个服务并用某个服务上的服务替换它不同的平台。它所要做的就是吐出 SOAP 或 JSON，我的 .NET 客户端仍然可以使用它。或者，如果我需要替换客户端，我可以直接连接到服务中已经存在的丰富域模型。
事实上，我已经完成了 - 该架构过去完全构建在 Delphi 7 平台之上。现在一切都在 .NET 3.5 上，并且从来没有真正从一个系统到下一个系统的硬切换。我们开始构建普通的 SOAP 服务，然后将大量应用程序内业务逻辑移至服务中，最终，当应用程序只不过是一个 shell 时，我们用几个 .NET 客户端（有一些单独的应用程序），然后开始添加只能在较新的平台上支持的各种安全功能和优化。等等。
所以如果你提前计划的话，这绝对是可以做到的。当然，这里有很多人会建议不要提前计划，引用 YAGNI 的话说……对于某些项目来说，也许这是真的。这完全取决于项目的成本/关键任务的程度。如果产品需要使用 50 年，那么您可能需要考虑投资一些可靠的架构和设计，以便您可以轻松添加和删除子组件。
I'm not aware of any recognized method for preventing the obsolescence of an unmaintained application.
If you want to prevent a product from becoming obsolete, then design it to be upgradable.
In .NET, at least, you have many, many options for creating reusable components:
Separate assemblies, which can be used in any .NET project, and can be later extended to support COM interop if the need arises to use a different technology.
Web services; these can be exposed publicly and used from almost any environment.
Interfaces and Inversion-of-Control can be used to support freely-interchangeable components, which could theoretically be coming from something that isn't even .NET (just build a COM wrapper);
Inter-process communication - if all else fails, you can literally just create a memory-mapped file or named pipe and start funneling in data from (or destined to) a brand-new application.
In fact, a number of these things probably apply to your current VB project. There are usually a myriad of different methods of extending the useful lifetime of an existing product while gradually transitioning the core functionality into a new technology.
I'm not hardcore SOA, but this is precisely the kind of problem that SOA tries to solve. I do a lot of services - in fact, almost everything significant here goes through some kind of web service at some point - and I feel quite comfortable knowing that I can completely rip out a service at any time and replace it with a service on a different platform. All it has to do is spit out SOAP or JSON and my .NET Clients can still consume it. Or, alternatively, if I need to replace the clients, I can just hook into the rich domain model that already exists in the services.
In fact, I've already done this - the architecture used to be built entirely atop a Delphi 7 platform. Now it's all on .NET 3.5, and there was never really any hard cut-over from one system to the next. We started building plain SOAP services, then moved a lot of the in-application business logic to the services, and eventually, when the application wasn't much more than a shell, we replaced it with several .NET Clients (there are a few separate applications) and then started adding various security features and optimizations that could only be supported on newer platforms. And so on and so forth.
So it definitely can be done, if you plan ahead. Of course, there are a number of people here who will advise against planning ahead, citing YAGNI... and maybe that's true, for certain projects. It all depends on just how expensive/mission-critical the project is. If the product needs to last for 50 years, then you might want to think about investing in some solid architecture and design that makes it easy for you to add and remove subcomponents.
他们应该问自己为什么认为一开始就用 VB6 编写这个项目是个好主意！难道他们不知道它已经不受支持并且已经过时了吗？如果您开始使用过时的技术，您能期待什么？
他们还应该考虑改进 VB6 代码的结构并使其更加面向对象。这将使向 .NET 的过渡变得更加容易。除此之外，他们可以尝试将功能分离到通过 COM 访问的外部类中。然后可以从 VB.NET 访问这些相同的类。此外，这些较小的部分可能更容易迁移。
They should ask themselves why they thought it was a good idea to write this project in VB6 to begin with! Didn't they know it was already unsupported and obsolete? If you start off using obsolete technologies, what can you possibly expect?
They should also consider improving the structure of their VB6 code and making it more object-oriented. That will make the transition to .NET easier. Among other things, they could try separating functionality out into external classes accessed through COM. Those same classes could then be accessed from VB.NET. Additionally, these smaller pieces might be easier to migrate.
最好的方法是使用跨平台的开发工具和库。这样微软就不能弃用你所依赖的东西（因为他们不控制它们）。如果您依赖单个供应商的任何特定产品，那么他们很可能会在某个时候把您搞砸。
The best way is to use cross-platform development tools and libraries. That way Microsoft can't deprecate things that you depend on (as they don't control them). If you depend on anything specific from a single vendor, its likely that they will screw you over at some point.
不要关注不能被废弃的代码。您很少在适用的堆栈中工作。相反，请使您的代码清晰简洁，以便您可以在时机成熟时迁移它。相反，要专注于不要让自己变得过时。努力保持最新状态，了解堆栈中正在发生的情况，并尝试了解正在发生的事情，即使您无法投入时间完全投入其中。
考虑到仿真和虚拟机，我有一种感觉，“遗留”代码的寿命实际上比以前想象的还要长。您应该关心的更多是工具，而不是操作系统。
Don't focus on code that cannot be obsoleted. It is rare that you work in a stack that is applicable. Instead, make your code clear and concise so you can migrate it when the time comes. Instead, focus on not letting yourself become obsolete. Work on staying current and know what is happening in your stack and try to be aware of what is going on, even if you cannot dedicate time to fully apply yourself to it.
Considering emulation and virtual machines, I have the feeling that "legacy" code will actually have an even longer life than imagined before. It is more the tooling, as opposed to the OS anymore, that you should be concerned about.
它（也许）取决于将代码与设计分离，尤其是在网络应用程序中，这些应用程序通常非常容易受到时尚变幻莫测的影响。但是如果代码库可以在当前技术上运行，即操作系统仍然可以运行它，那么就没有理由“升级”。
确保代码永久存在的真正方法是编写一个应用程序，该应用程序在使用中变得不可或缺，但重写成本高昂，以至于要完成所有内容（包括不废弃操作系统和硬件）以确保其继续运行。我相信这方面的一个例子是美国社会保障/政府领域的一些核心系统仍在运行，这些系统是在 1960 年代初编写的 COBOL 并在旧的 IBM 大型机上运行。
It depends (perhaps) on separating code from design especially in web applications which are often highly subject to the vagaries of fashion. But is the code base is runnable on the current technology, i.e. the OS will still run it then there is no reason to "upgrade".
The real way to ensure your code lasts forever though is to write an application that becomes so indispensable in use but so expensive to rewrite that everything, including not obsoleting OS and hardware is done to ensure it keeps running. I believe one example of this is some core systems in the US Social Security / Governmental arena are still running written in early 1960's COBOL and running on old IBM mainframes.
将其开源，或者至少在开源平台上构建。
我不知道 20 世纪 70 年代我们使用的任何专有系统与其旧用法兼容，但我知道许多开源系统。
这不是一个完美的机制——所有语言都会在这些时间尺度上发生变化，无论变化多么微小，然后你必须升级你的代码才能获得最新的东西。但我知道很多服务器运行的代码已经存在了几十年，没有任何变化。
更好的是，开源它，或者尽可能地开源。比什么都不做更好的是当其他人为您更新时什么都不做。社区的启动需要付出努力，但一旦启动就很难停下来！
任何非开源程序的效用在有限时间后都会降至零。不能保证开源会导致它保持非零，但至少有机会。
Open-source it, or at least build on an open-source platform.
I don't know any proprietary systems from the 1970's that we're using in a manner compatible with their old usage, but I know many open-source ones.
It's not a perfect mechanism -- all languages change, however slightly, on these timescales, and then you have to make upgrades to your code to get the newest stuff. But I know plenty of servers running code that's been around for decades with no changes.
Better yet, open-source it, or as much as possible. Even better than being able to do nothing is being able to do nothing while other people update it for you. It takes work to get the community started, but once started they can be hard to stop!
The utility of any non-open-source program drops to zero after finite time. It's no guarantee that open-source will cause it to remain nonzero, but there's at least a chance.
写入当前正在认真使用的标准（ANSI 或 ISO，我会避免 ECMA）定义。避免任何依赖于一家公司的事情，或者唯一的完整实施来自一家公司的情况。不要使用供应商语言扩展。请小心避免对语言的假设，例如数据类型大小：如果使用
int来保存内存大小而不是size_t，则可能会使运行变得更加困难64位系统。请记住，Microsoft 在保持向后兼容性方面是杰出的公司，他们为您破坏了 VB6。任何其他公司可能会更糟。
在任何重要的应用程序中，都会有依赖于平台的部分。将它们隔离，以限制平台发生变化时必须重写的内容。
显然，这其中是有成本的。例如，我建议 Windows 应用程序使用 Visual C++ 来完成，并通过抽象层使用 MFC，因为 C#、.NET、VB.NET 和 F# 不符合我的标准。然而，如果这是您的目标，这就是创建持久计划的方法。
Write to standard (ANSI or ISO, I'd avoid ECMA) definitions that are currently in serious use. Avoid anything dependent on one company, or where the only full implementation comes from one company. Don't use vendor language extensions. Be careful to avoid assumptions about the language, such as data type size: if you use
intto hold memory sizes rather thansize_t, you may make it more difficult to run on a 64-bit system.Remember that Microsoft is remarkable among companies for preserving backward compatibility, and they broke VB6 for you. Any other company will likely be worse.
In any significant applications, there will be parts that depend on the platform. Segregate them, to limit what has to be rewritten if the platform changes.
Obviously, there's costs in this. I've recommended, for example, that Windows applications be done in Visual C++, with MFC used through an abstraction layer, since C#, .NET, VB.NET, and F# don't qualify under my criteria. However, this is how to create a long-lasting program, if that's your goal.
我一定是二月份错过了这个问题，抱歉。据我所知，没有人回应过您同事的结论：他们必须从头开始重建[他们的 VB6 应用程序]才能迁移到 .Net。
这是错误：他们不必重写，有替代方法，而且它们通常比完全重写更容易并且更便宜。
以下是来自 Microsoft UK 的官方建议：
来自 一位就重写问题进行咨询的 Microsoft 人员撰写的博客文章：
告诉您的同事查看 Microsoft UK 建议 以及 截屏 解释 VB6 的 5 个基本选项 -> VB.Net 迁移。他们应该与老板一起选择前进的道路。它可能会被重写，但他们应该擦亮眼睛。
他们可能不应该用 VB6 编写任何其他新内容......
I must have missed this question in February, sorry. As far as I can see no-one has addressed your colleagues's conclusion that they are going to have to rebuild [their VB6 app] from scratch in order to migrate to .Net.
This is wrong: they don't have to rewrite, there are alternative methods and they are usually far easier and cheaper than a full rewrite.
Here's the official advice from Microsoft UK:
From a blog post by a Microsoft guy who consulted on rewrites:
Tell your colleagues to check out the Microsoft UK advice with a screencast explaining the 5 basic options for VB6 -> VB.Net migration. They should choose the way forward in conjunction with their boss. It may be rewriting, but they should go into it with their eyes open.
And they probably shouldn't write anything else new in VB6...