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

【问题标题】：How do you balance the conflicting needs of backwards compatibility and innovation?您如何平衡向后兼容性和创新的冲突需求？
【发布时间】：2008-10-02 05:13:13
【问题描述】：

我正在开发一个同时具有 GUI（图形）和 API（脚本）界面的应用程序。我们的产品拥有非常庞大的安装基础。许多客户已投入大量时间和精力来编写使用我们产品的脚本。

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

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

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

我知道 Windows Vista 刚推出时就惹恼了很多人，因为所有的软件和外围设备都不能在它上面运行，即使它们在 XP 上运行也是如此。因此，它收到了非常糟糕的接待。但你可以看到，微软也成功地在 Vista 中进行了一些伟大的创新，但牺牲了许多用户的向后兼容性。他们冒险了。它得到回报了吗？他们做出了正确的决定吗？我想只有时间会证明一切。

您是否发现自己在创新和向后兼容性的冲突需求之间取得平衡？你如何处理杂耍表演？

【问题讨论】：

标签： backwards-compatibility innovation

【解决方案1】：

就我的编程经验而言，如果我要从根本上改变一些会阻止过去传入数据被正确使用的东西，我需要为旧数据创建一个抽象层，以便将其转换以供使用采用新格式。

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

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

那只是我的 2c

【讨论】：

【解决方案2】：

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

【讨论】：

这将需要维护 2 个代码流，因为如果这意味着破坏他们的脚本，并非所有客户都会迁移到新系统。听起来这不是面向未来的最有效工作方式。
我同意 - 维护 2 个不同的编码线程很困难并且容易出错，如果可能的话我会避免这种情况

【解决方案3】：

您需要问的关键问题是客户是否想要/需要这种“改进”，即使您认为客户可能不会这样做。一旦建立了某种做事方式，改变工作流程是一项非常“昂贵”的操作。根据用户的计算机熟练程度，可能需要很长时间才能适应 UI 的变化。

如果您与客户打交道，为了创新而创新并不总是一件好事，因为开发这些改进对您来说可能很有趣。

【讨论】：

【解决方案4】：

您总是可以寻找创新的方法来保持向后兼容性。

【讨论】：