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

Question

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

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

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

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

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

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

Answer 1

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

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

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

那只是我的2c

Answer 2

将开发拆分为两个分支，一个维护向后兼容性，另一个用于新的主要版本，您可以清楚地看到向后兼容性正在被破坏。

Answer 3

您需要问的关键问题是客户是否希望/需要这种“改进”，即使您认为客户可能不会这样做。一旦建立了某种做法，改变工作流程就是一种非常“昂贵”的操作。根据用户的计算机使用情况，可能需要很长时间才能适应UI中的更改。

如果您正在与客户打交道，那么创新的创新并不总是一件好事，因为它可能会让您发展这些改进。

Answer 4

您可以随时寻找创新方法来保持向后兼容性。