您如何平衡向后兼容性和创新的冲突需求？

Question

我在一个具有GUI(图形)和API(脚本)接口的应用程序上工作.我们的产品具有非常大的安装基础.许多客户在编写使用我们产品的脚本上投入了大量的时间和精力.

在我们的所有设计和实现中,我们(可以理解)对保持100%向后兼容性有非常严格的要求.当我们引入新的软件版本时,之前运行的脚本必须以完全相同的方式继续运行,无需任何修改.

不幸的是,这种要求有时会牵扯到我们的背后,因为它确实限制了我们的创新能力,并提出了新的更好的做事方式.

例如,我们可能会提出一种更好(更有用)的方法来实现已经可能的任务.我们希望以更好的方式使用默认方式,但我们不能这样做,因为它可能具有向后兼容性含义.因此,我们坚持将新的(更好的)方式作为一种模式,用户必须在其可用之前"打开".除非他们阅读文档或在线帮助(许多客户不这样做),否则这项新功能将永远隐藏起来.

我知道Windows Vista在第一次出现时会让很多人感到恼火,因为所有软件和外围设备都没有用,即使他们在XP上工作也是如此.由于这个原因,它收到了非常糟糕的接待.但是你可以看到,微软也成功地在Vista中进行了一些伟大的创新,但却牺牲了许多用户的向后兼容性.他们冒了风险.它得到了回报吗？他们做出了正确的决定吗？我想只有时间会证明.

您是否发现自己在平衡创新和向后兼容性的冲突需求？你如何处理杂耍行为？

Answer 1

就我的编程经验而言,如果我要改进一些会阻止过去传入数据正确使用的东西,我需要为旧数据创建一个抽象层,在那里它可以转换为在新的使用格式.

基本上我将"改进"方式设置为默认方式,并确保通过转换器可以读取旧格式的数据,但将数据保存或存储为新格式.

我认为这里最重要的是测试,测试,测试.向后兼容性不应妨碍前进.

那只是我的2c