8

鉴于每个软件项目只有这么多的程序员时间专门用于它，你会花多少钱来确保产品与以前的版本向后兼容？其实有几点需要考虑：

  • 软件的年龄会影响您的决定吗？当程序更新时，您会在向后兼容性上投入更少的时间吗？
  • 该决定是否仅基于已安装副本的客户端数量？
  • 您是否积极努力生成支持未来更改的代码和文件格式？
  • 当您开发 v1.0 时，您是否尝试构建以使 v2.0 更容易向后兼容 v1.0？（留下“保留”字段就是一个例子。）
  • 您如何决定在功能上“不，我们将不再支持它”？
4

5 回答 5

9

客户群是决定您是否应该支持大的向后兼容性问题的关键。

基本上，您需要像您需要实现的任何其他非功能性需求一样评估它，并且您需要仔细指定“向后兼容性”功能中包含的内容：

  • API 兼容性。这意味着库的后续版本提供与之前版本相同的 API，因此针对之前版本编写的程序仍然能够使用新版本编译和运行。除了实际上保留相同的功能外，这还意味着这些功能在新版本中的作用与在旧版本中所做的相同
  • 应用程序二进制接口或 ABI 兼容性。这意味着在编译库时生成的二进制目标代码级别保留了向后兼容性。
    API 和 ABI 兼容性之间通常有一些重叠，但也有重要的区别。为了保持 ABI 兼容性，您所要做的就是确保您的程序导出所有相同的符号。
    这意味着所有相同的功能和全局可访问的对象都需要在那里，以便与先前版本链接的程序仍然能够与新版本一起运行。
    在破坏 API 兼容性的同时保持 ABI 兼容性是可能的. 在 C 代码中，将符号保留在 C 文件中，但从公共头文件中删除它们，因此尝试访问符号的新代码将无法编译，而用户针对先前版本编译的旧代码将继续运行
  • 客户端-服务器协议兼容性。这意味着使用较旧版本中提供的网络协议版本的客户端在面对较新的服务器时将继续运行，而较新的客户端程序将继续与较旧的服务器一起使用。
  • 数据格式兼容性。新版本的代码需要能够处理旧版本写出的数据文件，反之亦然。理想情况下，您还应该能够为数据格式构建一些前向兼容性。如果您的文件处理例程可以忽略并保留无法识别的字段，那么新功能可以以不破坏旧版本的方式修改数据格式。这是最关键的兼容性之一，因为用户在安装新版本的程序时会变得非常不安，突然无法访问他们的旧数据。

如果您将先前的标准（向后兼容性的性质）与您的客户群的性质结合起来，您可以决定：

  • 如果您的客户是公司内部的，则需求会降低，并且 2.0 可能会破坏重要功能。

  • 如果您的客户是外部客户，2.0 版可能仍会破坏，但您可能需要提供迁移指南

  • 在极端情况下，如果您的客户是全世界，正如我在这个关于 java 的 SO 问题中已经提到的那样，您最终可能会提供新功能而不会弃用旧功能！甚至保留旧产品的错误，因为客户的应用程序取决于这些错误！

  • 软件的年龄会影响您的决定吗？当程序更新时，您会在向后兼容性上投入更少的时间吗？
    我相信这与已经部署的内容有关：与大约 20 年前的程序相比，最近的程序必须处理更少的向后兼容性需求。

  • 该决定是否仅基于已安装副本的客户端数量？
    它应该基于业务案例：您的迁移（如果由于缺乏向后兼容性而需要）是否能够有效地“出售”给您的客户（因为它带来了所有新的闪亮功能？）

  • 您是否积极努力生成支持未来更改的代码和文件格式？
    试图预测“未来的变化”可能会适得其反，并且很快就会接近 YAGNI（你不需要它）：一套好的迁移工具可能会更有效。

  • 当您开发 v1.0 时，您是否尝试构建以使 v2.0 更容易向后兼容 v1.0？（留下“保留”字段就是一个例子。）
    对于我工作过的内部应用程序，没有。并行运行是我们确保“功能性”向后兼容性的方法。但这不是一个普遍的解决方案。

  • 您如何决定在功能上“不，我们将不再支持它”？
    同样，对于内部应用程序，决策过程可能与外部部署的决策过程非常不同。如果某项功能没有为业务带来任何附加值，则设置一个内部“一致性”任务来与每个其他内部应用程序检查其迁移成本（即“不再使用此功能”）。与组织外部的客户执行相同的任务要困难得多。

于 2009-02-09T09:33:58.197 回答
2

您的系统每天使用的越多，您就越应该关注它。

您的系统越深入地嵌入客户的核心流程中，您就越应该关注它。

您的系统拥有的竞争对手越多，您就越应该关注它。

使用旧版本的用户越多，您就越应该关注它。

客户对您的系统的购买越复杂，越深入，就您的软件对其业务的影响而言，您应该越关注向后兼容性。

如果您无法通过有吸引力的定价等方式帮助他们升级到新版本，那么可能值得考虑强迫所有人升级的风险。

像 Vista 或 Office 2007。这些对我到 Apple 的帮助非常好。

于 2009-02-09T09:40:46.793 回答
1

我对软件向后兼容性的看法：

1.）如果它已经被许多客户广泛​​使用，那么我会确保该产品的新版本仍然使用相同的“基本代码”（实现正在开发的应用程序的基本功能的代码）。新功能应纳入此代码库或构建在此代码库之上，并且在此应用程序的执行环境中需要尽可能少的更改。您不想让现有用户在其现有安装中执行大量更改。因此，它需要在支持新功能和改进客户现有设置和使用过程之间进行权衡。

2.)在新产品中，如果可能的话，甚至在 v1.0 发布之前，一开始就确定该应用程序的所有可能功能。确定您将在 v1.0 中发布哪些功能。以及哪些将保留以供以后发布。在设计、代码实现、最终确定应用程序的输出以适应未来版本的功能时，请尽可能记住这些“后期功能”。例如，在您的数据结构中保留额外的元素/位字段。

-广告。

于 2009-02-09T09:31:04.990 回答
1

很多。如果您不想惹恼您的每一位忠实客户！

于 2009-02-09T09:36:30.813 回答
0

我的经验是使用相对较少（100 - 5000）用户的复杂收缩包装系统。
市场营销人员通常对向后兼容性持有一种态度，而没有充分了解生命周期成本。例如，为当前用户群维护系统中的错误所节省的费用很容易与系统生命周期内新用户的支持成本相比相形见绌。

于 2009-08-25T02:28:10.430 回答