7

寻找一些在项目中处理主要依赖升级的最佳实践，假设使用依赖管理工具（例如，Maven 2）。

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

  • 如何使继承的应用程序保持最新（例如，Spring 1.2.x 到 2.5.x）
  • 在这样的大修之后可以采取哪些实践来使应用程序保持最新

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

编辑： 更新依赖版本号是微不足道的。我更多的是寻找您如何根据对依赖项的更改（弃用、删除、参数/返回值类型的更改等）来处理您需要进行的更改。如果将来有一种好方法可以缓解这些变化，因为保持你的依赖关系是最新的应该可以让你保持在变化之上，并防止浪费大量时间只是为了获得“更安全的 x 2.1 功能” '。

4

2 回答 2

1

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

我一直发现，最佳实践始于完成应用程序的生产周期，将其作为稳定版本发布，并在下一次开发迭代中手动更新依赖项。将您的版本集中在您的父 POM 中将导致最小的依赖版本修改和增加的可扩展性。假设您使用的是 Maven：

<dependency>
   <groupId>your.dep.group</groupId>
   <artifactId>your-artifact-id</artifactId>
   <version>${desiredVersion}</version>
</dependency>
于 2010-03-09T02:09:28.240 回答
1

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

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

对于较大的更改（例如在 Spring 等框架的不兼容版本之间进行升级），如果您有一些自动化的功能或集成测试，或者至少有一个功能规范，您的 QA 人员可以运行以验证高级功能，这会有所帮助。如果您要升级的框架 API 差异到足以需要进行广泛的代码更改，则单元测试可能不再相关。

管理从一个版本的依赖项迁移到另一个不兼容的版本的实际战术部分实际上取决于您在做什么。一个成熟的库将提供某种迁移路径，并且希望不会要求您重写所有内容。将与框架升级相关的代码更改与与实现新功能相关的更改分开是一个好主意。这样，如果出现问题，您将知道它与框架升级有关，而不是您在实施新功能时发生的问题。

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

于 2010-03-09T04:07:06.483 回答