整个项目分成不同的模块时如何避免依赖问题答案

【问题标题】：How to avoid dependency issue when the whole project are divided into different modules整个项目分成不同的模块时如何避免依赖问题
【发布时间】：2020-08-05 22:18:53
【问题描述】：

给定一个项目，它分为 3 个模块 A、B 和 C。这三个模块由三个团队在不同的 repos 中开发。此外，A、B 和 C 之间存在依赖关系。一开始，一切都运作良好。每个团队都可以从其他团队导入依赖项并在某个文件中配置依赖项。但是，假设模块 A 出于某种重构原因需要调整类。调整可能只是更改某些类的依赖引用（例如将类从“a-folder-1”移动到“a-folder-2”）。当 A 推送代码时，测试不会失败，因为对于 A 的 repo，没有任何问题。但是，当 B 或 C 推送代码时，他们将面临依赖问题，因为他们仍然使用旧的方式来导入已重构的 A 中的类。解决方法很简单，B和C只需要调整依赖配置文件就可以正确地从A导入类。

我的问题是，有没有什么框架或工具可以帮助我们避免此类问题？ 目前，每次有人更改依赖项时，其他人只能调整自己的依赖项配置。项目小的时候很简单，但是团队多的时候就麻烦了。因为每次有人想要推送新代码时，他都可能面临依赖问题。

【问题讨论】：

解决方案 - 接口代码。
版本每个构建，以便 B 和 C 可以在方便时更新对 A 的依赖。但是为什么同一个项目有 3 个不同的仓库呢？为整个代码库提供 1 个 repo，包含 3 个 maven/gradle 模块。重构将强制更新其他模块（假设不允许合并构建失败）。
每次 B 或 C 尝试推送代码时，他们都会使用 A 的最新版本。因为没有必要为他们定义版本。不同的repo有自己的开发速度。即使他们在做同一个项目，当项目真的很大时，他们确实需要分成不同的repos。

标签： java gradle dependencies

【解决方案1】：

确实没有一个简单的工具可以使用。唯一的解决办法是做好规划。

解决此类依赖问题的唯一方法是在项目启动之前拥有完整的 API（类、属性、方法的列表）。 这需要计划，这也是理解软件架构和设计如此重要的原因。

三个模块中的每一个的设计都必须仔细规划，这样制作新功能就不需要任何大的重构。

您可以查看semver，它基本上是一种系统化的版本控制方式。它可以帮助您传达变更，尤其是区分重大变更和非重大变更。

【讨论】：

是的，我知道在项目开始之前计划很重要。但大部分时间在科技公司工作，你将没有机会在项目开始之前参加计划会议。加入团队时，代码已经运行多年。