我从事的项目使用多个开源 Java 库。当这些库的升级出来时,我们倾向于遵循保守的策略:
- 如果它没坏,就不要修理它
- 如果它没有我们想要的新功能,请忽略它
我们遵循这个策略是因为我们通常没有时间放入新库并彻底测试整个应用程序。 (与许多软件开发团队一样,我们在几个月前 promise 的功能方面总是落后于时间表。)
但是,我有时想知道这种策略是否明智,因为一些性能改进和大量错误修复通常伴随着库升级。 (即“谁知道呢,也许事情会以我们没有预见到的方式变得更好......”)
当您在项目中做出这些类型的决策时,您使用什么标准?
最佳答案
重要:避免 Technical Debt .
“如果它没坏,就不要升级”是一个疯狂的政策,它会导致软件坏到没人能修复它。
草率、未经测试的更改是个坏主意,但没有积累技术债务那么糟糕,因为它在短期内看起来更便宜。
开始“每晚构建”流程,这样您就可以持续测试所有更改——您的更改以及您所依赖的包。
在您拥有持续集成流程之前,您可以每季度发布一次包含基础架构升级的主要版本。
避免技术债务。
关于java - 您如何决定何时升级项目中的库?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/394223/