客户端是确定是否应支持大型向后兼容性问题的关键.
基本上,您需要像需要实现的任何其他非功能性需求一样进行评估,并且需要仔细指定"向后兼容性"功能中包含的内容:
API兼容性.这意味着库的后续版本提供与先前版本相同的API,因此针对先前版本编写的程序仍然能够使用新版本进行编译和运行.除了实际上保留相同的功能外,这也意味着这些功能在较新版本中的功能与旧功能相同.
应用程序二进制接口,或ABI,兼容性.这意味着在编译库时生成的二进制对象代码级别保留了向后兼容性.
API和ABI兼容性之间通常存在一些重叠,但存在重要差异.要保持ABI兼容性,您所要做的就是确保程序导出所有相同的符号.
这意味着所有相同的功能和全局可访问的对象都需要存在,因此与先前版本链接的程序仍然可以使用新版本运行.
在破坏API兼容性的同时,可以保持ABI兼容性.在C代码中,在C文件中保留符号但将其从公共标题中删除,因此尝试访问符号的新代码将无法编译,而用户针对先前版本编译的旧代码将继续运行
客户端-服务器协议兼容性.这意味着使用旧版本中提供的网络协议版本的客户端在面对较新的服务器时将继续运行,并且较新的客户端程序将继续使用较旧的服务器.
数据格式兼容性.较新版本的代码需要能够处理旧版本编写的数据文件,反之亦然.理想情况下,您还应该能够在数据格式中构建一些向前兼容性.如果您的文件处理例程可以忽略并保留无法识别的字段,那么新功能可以以不破坏旧版本的方式修改数据格式.这是最关键的兼容性之一,因为用户在安装新版本的程序时会非常沮丧并且突然无法访问其旧数据.
如果将先前的条件(向后兼容性的性质)与客户群的性质相结合,则可以决定:
如果您的客户是您公司的内部客户,则需求较低,而2.0可能会破坏重要功能.
如果您的客户是外部的,2.0可能仍会破坏,但您可能需要提供迁移指南
在极端情况下,如果你的客户是全世界的,正如我在这个关于java的问题中已经提到过的那样,你最终可能会提供新的功能,而不会弃用旧的功能!或者甚至保留旧产品的BUGS,因为客户端的应用程序依赖于那些错误!!
软件的使用年限会影响您的决定吗？当程序较新时,您是否会减少向后兼容的时间？
我认为这与已经部署的内容有关:最近的程序将不得不处理较少的向后兼容性需求,而不是20年左右的需求.
决定是否仅基于已安装副本的客户端数量？
它应基于一个商业案例:您的迁移 - 如果因缺乏向后兼容性而需要 - 是否能够有效地"出售"给您的客户(因为它带来了所有新的闪亮功能？)
您是否积极努力生成支持未来变更的代码和文件格式？
试图预测"未来的变化"可能会适得其反,并且很快就会与YAGNI(你不需要它)接轨:一套好的迁移工具可以更加有效.
在开发v1.0时,您是否尝试构建以使v2.0更容易向后兼容v1.0？(留下"保留"字段就是一个例子.)
对于我所使用的内部应用程序,没有.一个并行运行是我们的方式,以确保一个"功能"后向兼容性.但这不是一个普遍的解决方案.
你如何决定"不,我们不再支持那个"功能？
同样,对于内部应用程序,决策过程可能与外部部署过程非常不同.如果某项功能没有为业务带来任何附加值,则会设置内部"一致性"任务,以便与其他内部应用程序一起检查其迁移成本(即"不再使用此功能").对于组织外部的客户来说,同样的任务要难得多.
京公网安备 11010802040832号 | 京ICP备19059560号-6 