如何处理主要的框架/依赖关系升级？

Question

假设使用了依赖关系管理工具(例如，Maven 2)，希望了解在项目中处理重大依赖项升级的一些最佳实践。

具体来说，我感兴趣的是：

• 如何使继承的应用程序更新(例如Spring1.2.x到2.5.x)
• 经过这样一次大修后可以采用哪些实践，以使应用程序保持一些最新的

。

欢迎您自己的经验或任何您遇到/发现有用的文章/论文。

编辑：更新依赖版本号非常简单。我更想了解如何根据对依赖项的更改(弃用、删除、参数/返回值中类型的更改等)来处理需要进行的更改。如果将来有一种缓解这些变化的好方法，比如保持您的依赖关系是最新的，应该允许您保持在更改的顶部，并防止浪费大量的时间来获得“更安全的x2.1”功能。

Answer 1

处理依赖项更改的良好实践与应用程序设计的良好实践是相同的。您希望对体系结构进行分层，并尽量减少代码在每个依赖项上的广泛耦合，以保持更改的隔离，这样升级依赖关系就不会破坏应用程序的每个部分。接口代码，并将业务逻辑与基础结构代码分开。

对于较小的升级(升级依赖项的点版本)，如果您有一组全面的单元测试来检测API更改导致的故障，则会有所帮助。这就是为什么有时编写表面上看起来总是有效的琐碎测试的一个重要原因。其中一个例子是编写一个简单的JDBC单元测试来执行一个简单的查询。在数据库升级后发现JDBC驱动程序的运行时问题之前，这似乎是一种浪费(在我身上已经发生了)。

对于更大的更改(比如在Spring这样的框架的不兼容版本之间进行升级)，如果您有一些自动化的功能测试或集成测试，或者至少有一个功能规范，QA人员可以通过该规范来验证高级别的功能，这会有所帮助。如果您正在升级的框架API有足够的不同，需要进行广泛的代码更改，那么单元测试很可能不再有意义。

从依赖关系的一个版本到另一个不兼容版本的迁移的实际策略部分实际上取决于您正在做什么。成熟的库将提供某种迁移路径，希望不会要求您重写所有内容。将与框架升级相关的代码更改与实现新功能相关的更改分开是一个好主意。这样，如果某些东西坏了，您就会知道这与框架升级有关，而不是在实现新功能时弄坏的东西。

让这变得如此困难的部分原因是，在运行时，您只能在JVM中拥有特定依赖项的一个版本，因此您必须一次更新所有代码。OSGi通过允许运行在同一版本中的不同OSGi包依赖于不同的依赖版本来解决这个特殊问题，因此您可以在运行时依赖不同的依赖版本。这就是Eclipse如何在不破坏其他插件的情况下管理插件的依赖关系。

Answer 2

在我的经验中，依赖项升级是由于依赖项所拥有的所需功能而实现的，它是对依赖项中的一个bug的修正，它直接影响到您自己的代码，支持新的Java版本，或者使您的代码符合特定的标准(对于影响安全性的依赖关系)。如果您的代码不属于这些必要的领域之一，我不会费心让它们保持最新，而是只在必要时更新它们，因为从一个版本更新到另一个版本实际上会给您的应用程序带来but。

我一直发现，最佳实践从完成循环应用程序的生产开始，将其作为一个稳定的构建发布，并在下一个开发迭代中手动更新您的依赖项。将您的版本集中在您的父POM中将带来最小的依赖性版本修改和更高的可扩展性。假设您使用的是Maven：

<dependency>
   <groupId>your.dep.group</groupId>
   <artifactId>your-artifact-id</artifactId>
   <version>${desiredVersion}</version>
</dependency>