我在一个使用多个开源Java库的项目上工作.当升级到这些库时,我们倾向于遵循保守的策略:
如果没有破损,请不要修复它
如果它没有我们想要的新功能,请忽略它
我们遵循这一策略是因为我们通常没有时间放入新库并彻底测试整个应用程序.(像许多软件开发团队一样,我们总是落后于几个月前承诺的功能.)
但是,我有时想知道这种策略是否明智,因为一些性能改进和大量的bug修复通常伴随着库升级.(即"谁知道,也许事情会以我们无法预见的方式更好地运作......")
在项目中做出这些类型的决策时,您使用什么标准?
重要:避免技术债务.
"如果它没有破产,不要升级"是一个疯狂的政策,导致软件如此破碎,没有人可以解决它.
皮疹,未经测试的改变是一个坏主意,但不像累积技术债务那么糟糕,因为它在短期内看起来更便宜.
获得"夜间构建"过程,以便您可以持续测试所有更改 - 您的更改以及您依赖的包.
在您进行持续集成过程之前,您可以执行包含基础架构升级的季度主要版本.
避免技术债务.
我已经吸取了足够的教训来完成以下工作:
检查库的更改列表.他们修复了什么?我关心的?如果没有更改列表,则我的项目中不使用该库.
人们在图书馆论坛上发帖的是什么?发布后不久就会发出大量帖子,指出明显的问题?
与2号一样,不要立即升级.每个人发布都不好.我不打算成为第一个得到这个小虫子的人.(再也是).这并不意味着要等6个月.在发布的第一个月内,你应该知道缺点.
当我决定继续升级时; 测试,测试测试.这里的自动化测试非常重要.
编辑:我想添加一个至少同样重要的项目,也许比其他项目更重要.
这个版本引入了哪些重大变化?换句话说,图书馆是朝着不同的方向发展的吗?如果库正在弃用或替换功能,您将希望保持最佳状态.