2

我目前正在尝试找到一个合适的工作流程来跨多个 Maven 项目执行重构，但我找不到任何令人满意的解决方案。

假设有三个项目。一个名为common的项目和两个名为app1和app2的依赖项目。每个都在一个单独的 Git 存储库中。

现在假设一个名为 StringUtils.trim() 的通用方法应重命名为 StringUtils.getTrimed()。因为app1和app2使用了这种方法，所以这些项目也需要进行调整。

现在，问题是，向开发团队提供这种修改的正确工作流程是什么。鉴于这种情况：一个由大约 10 名开发人员组成的团队，拥有一个中央 SCM 服务器和一个中央 Maven 存储库服务器来托管工件。

可能的工作流程：

  1. 只需将更改提交到 SCM（对于所有三个项目）--> 问题：例如，在app1上工作的开发人员可能没有检出项目公共，而是使用来自中央工件服务器的二进制文件。当他们从 SCM获取最新版本的app1时，他们的构建将中断。坏的！

  2. 除了 1，将app1的依赖项更改为指向common的 SNAPSHOT 版本。--> 问题：当在app1上工作的开发人员从 SCM 获取最新版本时，如果更新策略设置为DAILY（这是默认设置），他们可能不会获得common的最新 SNAPSHOT。坏的！

  3. 除了 2，将 SNAPSHOTS 的更新策略更改为ALWAYS。--> 问题：现在，app1的开发人员将获得common的最新 SNAPSHOT，一切都很好，但前提是在我提交对app1的更改之前将 SNAPSHOT 部署到工件服务器！此外，在将公共项目部署到工件服务器和我将app1提交到 SCM之间有一段时间。如果开发人员获取common的最新 SNAPSHOT ，它将与 SCM 中app1的当前版本不兼容，因为我还没有提交对app1的更改。坏的！

我能想出的唯一可行的解​​决方案是跳过 SNAPSHOT 机制并使用版本。这是工作流程：

  • 在我的机器上本地更改三个项目后（在任何提交之前），将common的版本从 1.0 增加到 1.1。
  • commit common to SCM 并将其部署到工件服务器。
  • 只有在部署完成后，将app1和app2中的依赖关系更改为指向新版本的common并提交app1和app2。

这种方法的问题：我必须做版本管理，所以这只能与整个团队协调并考虑所有依赖项目来完成。此外，我必须等待公共项目部署到工件服务器，然后才能提交对app1和app2的更改。

是不是有什么简单灵活的机制，如何进行这样的重构呢？我希望有人能帮助我。也许我这边也有一些误解。

4

4 回答 4

0

是的。使用版本控制。对于次要版本升级，保留旧方法并将其标记为已弃用。在通用项目的发行说明中记录您对界面的更改。

于 2013-01-27T10:15:29.220 回答
0

我会向你推荐一个开源工具，比如 Sonar (sonarsource.org)

于 2012-09-14T12:16:36.167 回答
0

贬低旧的方法名称并将调用引用到新的方法名称。然后你有一个时间窗口来处理两者。然后要求开发团队每隔 X 检查一次折旧的方法，并在固定时间后在未来的版本中删除折旧的方法。

于 2013-01-24T16:34:30.910 回答
0

如果重构属于您在示例中建议的类型，我认为您不会找到一种简单的重构方法。您在这里基本上拥有的是从应用程序 1 和 2 到 common 的第三方依赖项。而且，正如您可能已经注意到的那样，第三方依赖项不会经常更改其接口方法的名称，这是有充分理由的 - 对于任何试图更新到最新版本的人来说都是地狱。

我建议您将接口方法的名称保持在尽可能高的水平，名称应该有一些非常错误的东西才能更改（名称说明它做了一些它没有做的事情，反之亦然）。想要将“trim()”更改为“getTrimmed()”并不是这样做的充分理由。

所以，我的建议是这样的：

在 common 的内部部分做所有你想要的重构，保持接口不变。如果您真的需要重命名某些东西，请使用新名称复制相关方法，将旧方法标记为已弃用，并让它们都存活一段时间，直到可以合理地假设每个人都开始使用新的，停止使用旧的。

于 2012-09-14T12:06:05.647 回答