我正在开发一个同时具有 GUI(图形)和 API(脚本)界面的应用程序。我们的产品有一个非常大的安装基础。许多客户投入了大量时间和精力来编写使用我们产品的脚本。
在我们所有的设计和实现中，我们(可以理解)有一个非常严格的要求来保持 100% 向后兼容 .当我们引入新的软件版本时，之前运行的脚本必须以完全相同的方式继续运行，无需任何修改。
不幸的是，这个要求有时会束缚我们的双手，因为它确实限制了我们 的能力。创新 并提出新的更好的做事方式。
例如，我们可能会想出一种更好(也更有用)的方法来完成已经可能的任务。将这种更好的方式作为默认方式是可取的，但我们不能这样做，因为它可能具有向后兼容性的影响。因此，我们坚持将新的(更好的)方式作为一种模式，即用户必须在它变得可用之前“打开”。除非他们阅读文档或联机帮助(许多客户不这样做)，否则此新功能将永远隐藏。
我知道 Windows Vista 刚推出时惹恼了很多人，因为所有的软件和外围设备都无法在它上面运行，即使他们在 XP 上运行也是如此。因此，它收到了非常糟糕的接待。但是你可以看到，微软也成功地在 Vista 中做出了一些伟大的创新，代价是对很多用户的向后兼容性。他们冒了风险。它得到了返回吗？他们做出了正确的决定吗？我想只有时间会证明一切。
您是否发现自己平衡了创新和向后兼容性的冲突需求？你如何处理杂耍行为？
最佳答案
就我的编程经验而言，如果我要从根本上改变一些会阻止过去传入数据被正确使用的东西，我需要为旧数据创建一个抽象层，在那里它可以被转换以用于新数据格式。
基本上我将“改进”方式设置为默认值，并确保通过转换器它可以读取旧格式的数据，但将数据保存或存储为新格式。
我认为这里最重要的是测试，测试，再测试。向后兼容性不应该阻碍前进。
那只是我的 2c
关于backwards-compatibility - 您如何平衡向后兼容性和创新的冲突需求？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/160968/