这里的一些程序员一直在用VB6开发一个项目，他们说他们现在需要升级到vb.net，如果他们希望他们的应用程序在新的/未来的系统上运行，因为vb6将很快成为历史。
所以他们一直在努力的这个巨大的应用程序，他们将不得不从头开始重建（他们试图使用升级向导，但错误太多）
该公司的老板对于在项目中投入这么多小时而不必太过激动，只是为了转身并从头开始重做。
这不是我的项目，我对vb一无所知，我是一名网络程序员。
但是这些家伙可以做些什么呢？这样就不会再发生了，或者他们应该做些什么来让现在这不是问题呢？
是否有某种方法可以确保您的应用程序始终具有可扩展性并且不会过时并需要重新编写？
谢谢！
答案 0 :(得分：14)
我的公司目前正在Fortran，Clipper，VB6和FoxPro中运行程序，其中一些已经存在了20多年，并且在所有Windows升级中幸免于难。通常，使旧程序无法使用的是无法重新编译程序以修复错误。
虽然打破你的程序功能肯定会有所帮助，这样如果你决定从VB6迁移到VB .Net，那么选择可重复使用的代码要容易得多。
答案 1 :(得分：5)
很棒的问题。
简短的回答是否定的。因为所有代码最终都会过时。
如果你在x86汇编程序中编写代码，那么它会持续一段时间。 C代码也有很长的保质期。但问题在于，由于许多因素，从装配商那里抽出的技术越多，保质期越短。
答案 2 :(得分：4)
请勿使用专有语言。当然，库和平台可能会发生变化，但有趣的是语言本身已经过时了。坚持使用C，C ++或任何具有大量开源用户群的东西。即使维护者停止支持它们，这些也可能存在一段时间 - 这意味着Python，Ruby，Java和可能 C＃。我的水晶球在C和C ++之外并不是那么出色，但其他人中有一个令人信服的理由可以持续20到50年。
Visual Basic很有趣，但从架构的角度来看，它所促进的代码和UI的混合是非常糟糕的。一个好的设计应该使改变后端，GUI工具包和操作系统变得可行（不一定非常容易）。
你有点习惯使用一种语言，所以选择一种不限于一个不断改变它的供应商的语言。
尝试阅读Joel的Fire and Motion。
答案 3 :(得分：3)
考虑到编程技术的快速发展，变得过时是我们应用程序正常生存周期的一部分。
我真的不知道桌面/服务器应用程序，但是，在网络开发中，我们说5年长，例如^^
当然，它可以更新，修补，纠正，修复等等......但这样做通常会降低代码的质量和应用程序本身的质量 - 这意味着随着时间的推移，维护将花费越来越多的成本;最后，重写一切可能意味着在维护上花费更少的钱。
答案 4 :(得分：3)
正如其他人所说，这不是“我的申请怎么能不被淘汰”。它更“当我的应用程序变得过时时，我怎样才能快速恢复。”实际上，这只是其他问题的另一个版本：
这就是OO和SOA试图回答的问题。构建许多小型独立应用程序，并使用标准机制将它们松散地耦合在一起。当您因任何原因需要升级时，请将其拔出，升级并重新插入。
答案 5 :(得分：3)
我不知道任何可以防止未维护的应用程序过时的方法。
如果您想阻止产品过时，那么将其设计为可升级的。
在.NET中，至少，您有许多选项可用于创建可重用的组件：
可以在任何.NET项目中使用的单独程序集，如果需要使用其他技术，可以稍后扩展以支持COM互操作。
网络服务;这些可以公开曝光，几乎可以在任何环境中使用。
接口和Inversion-of-Control可以用来支持可自由交换的组件，理论上它们可能来自甚至不是.NET的东西（只需构建一个COM包装器）;
< / LI>进程间通信 - 如果所有其他方法都失败了，您可以简单地创建一个内存映射文件或命名管道，并从一个全新的应用程序开始汇集数据（或指向它）。
事实上，许多这些东西可能适用于您当前的VB项目。通常有许多不同的方法可以延长现有产品的使用寿命，同时逐步将核心功能转换为新技术。
我不是核心SOA，但这正是SOA试图解决的问题。我做了很多服务 - 事实上，几乎所有重要的服务都在某些时候通过某种网络服务 - 我知道我可以随时完全删除服务并将其替换为服务不同的平台。它所要做的只是吐出SOAP或JSON，我的.NET客户端仍然可以使用它。或者，或者，如果我需要替换客户端，我可以挂钩已经存在于服务中的丰富域模型。
事实上，我已经已经完成了这个 - 这个架构过去完全是在Delphi 7平台上构建的。现在全部都在.NET 3.5上，从一个系统到下一个系统从来没有真正的任何硬切换。我们开始构建普通的SOAP服务，然后将大量的应用程序内业务逻辑移植到服务中，最终，当应用程序不仅仅是一个shell时，我们用几个.NET客户端替换它（有一些）单独的应用程序）然后开始添加只能在较新平台上支持的各种安全功能和优化。依此类推。
如果你提前计划，那肯定可以做到。当然，这里有很多人会提出反对计划的建议，引用YAGNI ......对于某些项目而言，这可能是真的。这一切都取决于项目的昂贵/关键任务。如果产品需要使用50年，那么您可能需要考虑投资一些可靠的架构和设计，以便您轻松添加和删除子组件。
答案 6 :(得分：2)
他们应该问问自己为什么他们认为在VB6中开始编写这个项目是个好主意！难道他们不知道它已经不受支持和过时了吗？如果你开始使用过时的技术，你可能期望什么？
他们还应该考虑改进VB6代码的结构，使其更加面向对象。这将使向.NET的过渡更容易。除此之外，他们可以尝试将功能分离为通过COM访问的外部类。然后可以从VB.NET访问这些相同的类。此外，这些较小的部分可能更容易迁移。
答案 7 :(得分：2)
最好的方法是使用跨平台开发工具和库。这样微软就不能弃用你所依赖的东西（因为它们不控制它们）。如果您依赖于单个供应商的特定内容，可能会在某些时候将您搞砸。
答案 8 :(得分：0)
不要专注于无法废弃的代码。您很少使用适用的堆栈。相反，请使您的代码清晰简洁，以便在时机成熟时进行迁移。相反，专注于不让自己变得过时。努力保持最新状态并了解堆栈中发生的事情并尝试了解正在发生的事情，即使您无法花时间完全应用它。
考虑到仿真和虚拟机，我觉得“遗留”代码实际上会比以前想象的更长寿。与操作系统相反，它更像是你应该关注的工具。
答案 9 :(得分：0)
它（可能）取决于将代码与设计分离，特别是在Web应用程序中，这些应用程序通常很容易受到时尚的影响。但是代码库是否可以在当前技术上运行，即操作系统仍会运行它，然后没有理由“升级”。
确保代码永久存在的真正方法是编写一个在使用中变得如此不可或缺的应用程序，但是重写所有内容都非常昂贵，包括不过时的操作系统和硬件，以确保它继续运行。我相信这方面的一个例子是美国社会保障/政府领域的一些核心系统仍然在1960年代早期的COBOL中运行，并在旧的IBM大型机上运行。
答案 10 :(得分：0)
开源，或者至少建立在开源平台上。
我不知道1970年代的任何专有系统，我们以与旧用法兼容的方式使用，但我知道很多开源系统。
这不是一个完美的机制 - 在这些时间尺度上，所有语言都会稍微改变，然后你必须升级代码才能获得最新的东西。但是我知道很多运行代码的服务器已经存在了几十年而没有任何变化。
更好的是，开源，或尽可能多。当别人为你更新它时，能够什么都不做就更好了。让社区开始工作需要付出努力，但一旦开始就很难停止！
任何非开源程序的效用在有限时间后降至零。不能保证开源会使它保持非零，但至少有机会。
答案 11 :(得分：0)
写入目前严重使用的标准（ANSI或ISO，我避免使用ECMA）定义。避免任何依赖于一家公司的事情，或者唯一的完整实施来自一家公司。不要使用供应商语言扩展。小心避免对语言的假设，例如数据类型大小：如果使用int来保存内存大小而不是size_t，则可能会使在64位系统上运行更加困难。
请记住，微软在保留向后兼容性的公司中非常出色，他们为您打破了VB6。任何其他公司可能会更糟。
在任何重要的应用程序中，都会有部件依赖于平台。隔离它们，以限制平台更改时必须重写的内容。
显然，这有成本。例如，我建议Windows应用程序在Visual C ++中完成，MFC通过抽象层使用，因为C＃，。NET，VB.NET和F＃不符合我的标准。但是，如果这是你的目标，那就是如何创建一个持久的计划。
答案 12 :(得分：0)
我一定在2月错过了这个问题，对不起。据我所知，没有人解决你的同事的结论，他们将不得不从头开始重建[他们的VB6应用程序] 以便迁移到.Net。
这是错误：他们没有重写，有其他方法，他们通常远更容易和更便宜完全重写。
以下是Microsoft UK的官方建议：
对.NET执行完全重写要花费更多，并且难以做好[转换] ...我们只会针对少数情况推荐这种方法。
来自咨询重写的微软人员的blog post：
我在.NET早期工作过的许多公司首先考虑的是重写，部分原因是他们在迁移到.NET的同时强烈希望改进底层架构和代码结构。不幸的是，许多项目遇到了困难，有些项目从未完成。他们试图解决的问题太大了。 [这就是你的同事与老板发生严重问题的关键 - 人们在这一点上被解雇了]
告诉您的同事查看Microsoft UK advice，其中screencast解释了VB6的5个基本选项 - ＆gt; VB.Net迁移。他们应该与老板一起选择前进的方向。它可能是重写，但他们应该睁着眼睛进入它。
他们可能不应该在VB6中写任何新内容......