project-management - 一个项目应该在向后兼容性上花费多少时间和精力？

Question

关闭。这个问题是opinion-based .它目前不接受答案。












想改善这个问题吗？更新问题，以便可以通过 editing this post 用事实和引文回答问题.

2年前关闭。




Improve this question




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

软件的年龄会影响您的决定吗？当程序更新时，您会在向后兼容性上投入更少的时间吗？

决定是否仅基于安装副本的客户端数量？

您是否积极努力生成支持 future 更改的代码和文件格式？

在开发 v1.0 时，您是否尝试构建以更容易地使 v2.0 向后兼容 v1.0？ (保留“保留”字段是一个示例。)

你如何决定“不，我们不再支持它”的功能？

Answer 1

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

基本上，您需要像任何其他 一样评估它。非功能性需求 您需要实现，并且需要仔细指定"backward compatibility" feature 中包含的内容:

API 兼容性 .这意味着库的后续版本提供与先前版本相同的 API，因此针对先前版本编写的程序仍然能够使用新版本编译和运行。除了实际上保留相同的功能外，这还意味着这些功能在较新版本中的功能与在旧版本中的功能相同

应用程序二进制接口(interface)或 ABI，兼容性 .这意味着在编译库时生成的二进制目标代码级别保留了向后兼容性。
API 和 ABI 兼容性之间通常有一些重叠，但也有重要的区别。为了保持 ABI 兼容性，您所要做的就是确保您的程序导出所有相同的符号。
这意味着所有相同的功能和全局可访问的对象都需要存在，以便与先前版本链接的程序仍然能够在新版本中运行。
可以在破坏 API 兼容性的同时保持 ABI 兼容性。在 C 代码中，将符号保留在 C 文件中但从公共(public)头文件中删除它们，因此尝试访问符号的新代码将无法编译，而用户针对先前版本编译的旧代码将继续运行

客户端-服务器协议(protocol)兼容性 .这意味着使用较旧版本中提供的网络协议(protocol)版本的客户端在面对较新的服务器时将继续运行，并且较新的客户端程序将继续与较旧的服务器一起工作。

数据格式兼容性 .新版本的代码需要能够处理旧版本写出的数据文件，反之亦然。理想情况下，您还应该能够在数据格式中构建一些前向兼容性。如果您的文件处理例程可以忽略并保留无法识别的字段，那么新功能可以以不破坏旧版本的方式修改数据格式。这是最关键的兼容性之一，因为用户在安装新版本的程序时会变得非常沮丧，突然无法访问他们的旧数据。

如果您将之前的标准(向后兼容性的性质)与您的客户群的性质结合起来，您可以决定:

如果您的客户在您的公司内部，则需求较低，并且 2.0 可以破坏重要功能。

如果您的客户是外部客户，2.0 可能仍然会破坏一些东西，但您可能需要 provide migration guide

在极端情况下，如果您的客户遍及全世界，正如我在此 中已经提到的那样SO question about java ，您最终可能会提供新功能而不会弃用旧功能!甚至 preserving BUGS of your old products ，因为客户端的应用程序依赖于那些错误!!

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

决定是否仅基于安装副本的客户端数量？
它应该基于商业案例:您的迁移 - 如果由于缺乏向后兼容性而需要的话 - 是否能够有效地“出售”给您的客户(因为它带来了所有新的 Shiny 功能？)

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

在开发 v1.0 时，您是否尝试构建以更容易地使 v2.0 向后兼容 v1.0？ (留下“保留”字段是一个例子。)
对于我处理过的内部应用程序，没有。 Parallel Run是我们确保“功能性”向后兼容性的方式。但这不是万能的解决方案。

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