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

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

不幸的是，这种要求有时会束缚我们的双手，因为它确实限制了我们的创新能力，并提出了新的更好的做事方式。

例如，我们可能想出一种更好(且更有用)的方式来完成一项可能的任务。最好将此默认方法设置为更好的方法，但是我们不能这样做，因为它可能会向后兼容。因此，我们坚持将新的(更好的)方式保留为一种模式，即用户必须先"打开"电源，然后才能将其使用。除非他们阅读文档或者在线帮助(许多客户不这样做)，否则这项新功能将永远被隐藏。

我知道Windows Vista刚问世时就惹恼了很多人，因为所有软件和外围设备都无法在其上运行，即使它们在XP上也可以运行。因此，它收到了一个非常差的接待。但是我们可以看到，Microsoft也成功地在Vista中进行了一些重大创新，但是却牺牲了许多用户的向后兼容性。他们冒险了。它还清吗？他们做出正确的决定了吗？我想只有时间会证明一切。

我们是否发现自己在创新需求和向后兼容性的矛盾需求之间取得了平衡？我们如何处理杂耍行为？

解决方案

就我的编程经验而言，如果我要从根本上更改某些内容以防止过去的传入数据被正确使用，则需要为旧数据创建一个抽象层，在此可以将其转换为新层格式。

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

我认为这里最重要的是测试，测试，测试。向后兼容不应妨碍向前发展。

那只是我的2分

将开发分为两个分支，一个分支保持向后兼容性，另一个分支用于新的主要发行版，我们可以在其中清楚地知道向后兼容性已被破坏。

我们需要问的关键问题是客户是否希望/需要这种"改进"，即使我们认为它是客户也可能不需要的。一旦确定了某种特定的工作方式，更改工作流程将是一项非常"昂贵"的操作。根据用户的计算机熟练程度，可能需要很长时间才能适应UI的更改。

如果我们是为了创新而与客户打交道，那么创新并不一定总是一件好事，而开发这些改进可能会很有趣。

我们可以寻求合法的方法来保持向后兼容。