2008-11-20 84 views
5

当你在开发工具中考虑升级时,向后兼容性对你来说有多重要?如果您需要对源代码进行重大更改,您还会购买Visual Studio 2010吗?在交易向新的功能兼容性方面,您的转折点在哪里?向后兼容性有多重要?

+0

你能不能作为一个经验丰富的人解释一下我为什么这不是一个社会维基职位? – badbadboy 2008-11-20 19:56:38

+0

因为这是一个合法的问题?社区Wiki并不适用于所有事情,我不会因为没有选择它而认错。 – 2008-11-20 20:05:53

回答

10

当你问这个但从开发商的角度来看,我认为这将是参考你开发软件一个更有趣的问题。所以我要回答这个问题。 :)

的硬件和软件的向后兼容(更重要的是,未来兼容)提供一种安全感给您的用户,购买或升级平台,如Windows时尤其如此。如果没有别的,Windows以其对向后兼容性的细致关注而闻名。如果程序写得很好(即不使用未公开的API),则可以在Windows Vista上运行十几年前编写的程序,但只有小问题。

在另一方面,严格注意向后兼容性可以配合你的手,当你试图引入新的功能或者以革命性的平台。苹果知道它有一个垂死的操作系统,并且在其最大胆的举动之一中,它购买了NeXT并决定让NeXTSTEP成为新的MacOS。销售人员转型的关键之一是向后兼容的图层Classic。再次,当苹果决定转用英特尔芯片时,在英特尔上运行PowerPC应用程序的机制(称为Rosetta)以及通用二进制文件允许人们在PowerPC和英特尔之间自由移动,而不用担心应用程序丢失。

一个有趣的事情是,随着向英特尔过渡,Classic环境消失了,但没有人真正在意,因为他们有前5年从Mac OS 9过渡。因此,最终可能会将遗留系统的支持放弃为只要你有一个简单的方法迁移到新系统,并给你的用户足够的时间这样做。

0

定义“重大变化”。如果可以通过精心制作的“搜索&替换”进行更改,即使它们很广泛,我也会去做。

但是,这就是会做什么。我曾经工作过的任何公司都会拒绝对现有代码进行任何更改。

1

这取决于您需要支持哪些环境以及使用哪些第三方工具可能相容也可能不相容。

例如,在我工作的地方,我们将所有人都升级到VS2008,除了我们的BI组,因为SQL Server BI工具与VS2008不兼容。一旦更新,他们升级到VS2008。

当专注于VS时,请记住VS2008可以针对.NET 2.0,.NET 3.0和.NET 3.5。诀窍是意识到它实际上是以.NET 2.0 SP1和.NET 3.0 SP1为目标的。因此,升级IDE不应要求您更改代码。

1

由于软件和硬件领域发生了很多变化,因此在构建解决方案时,我认为开放新变更和更好工具是一个好主意。例如,我们在90年代没有多核处理器和高端图形卡或网卡,因此编译器和工具的优化目标自然不同。但同时,工具正在尽其所能地适应旧的框架和应用程序。

我认为,如果我们期待着一个更美好的世界,我们应该开放不断的变革,直到这个行业超级成熟。 (可能不会发生在我们的生活中:) :)

1

在genreal中,如果您正在开发一个平台,许多其他用户会不断用它来构建自己的产品,并且您计划开发一个应用程序很长一段时间,这很重要。查看PHP,Python,Eclipse和其他开源项目,这些项目对于向后兼容性非常重要。在开发n层体系结构中使用的服务或其他开放apis时,它也是重要的。当您更改服务时,您可以让企业中的所有应用程序始终处于中断状态。

现在,如果您正在构建一个收缩包装应用程序或商业应用程序,那么它并不是那么重要,因为每个版本都与其前身是分开的。

2

对于家庭项目,向后兼容性并不重要。对于办公室/企业来说,这绝对是关键。

3

在开发工具中,如果它没有提供与我以前的代码的完全向后兼容性,我不会购买它,我怀疑任何人都会。坦率地说,没有意义。如果我已经有了一个编译器,可以将我的源代码构建成适用于我的可执行代码,那么我将使用它。为什么要改变我的代码以符合显然对工具制造者而言不是一个标准?如果他们强迫从一个版本到另一个版本的源代码更改,他们为什么会打扰使下一个版本兼容?

100%与源的向后兼容性是一项要求。唯一不是全部要求的情况是不兼容的位是扩展名;即特定于该工具的API更改,例如Eclipse插件等。即便如此,我还是喜欢兼容性,但是我意识到它不能完全被期望。但是,如果您为基础应用程序/工具开发提供API,并且无法保持兼容性;那么,那么,你显然不认真对待你的工具,我不会为他们付出沉重的代价。