分离java项目

Question

我有一个大型的java项目，我们在构建周期中使用maven。这一个项目被广泛使用-在其他项目中，在各种应用程序中，其中一些包含在其中，另一些则在其他地方.老实说，这有点混乱(为了特定的目的，在不同的时间添加了不同的数据)，我想把它清理一下。此外，它还没有完全测试(在没有适当的单元和集成测试的情况下，已经添加了很多位)，有些测试需要很长时间才能运行，或者没有真正通过.(嗯-哦)-所以测试在maven构建周期中被关闭(同样，呃-哦)。

我正在考虑将这个大型项目分成较小的具体项目，这样“最后”的子项目(或几个子项目)就能获得它所需要的各种子项目。

我的想法如下：

• 如果我把大项目分成不同的子项目，这就清楚了每个项目的责任是什么。
• 通过分离成子项目，我可以单独清理每个子项目的测试，并在maven构建周期中打开该子项目的测试。

我有点担心这会对构建时间产生什么样的影响。

• 在大型项目(即小的子项目)上强加一个结构会减缓编译器的速度吗？

另外，我对IDE中的编辑时间可能会产生什么样的影响(我们主要使用Intellij)有一点小小的关注。Intellij似乎依次通过依赖树构建每个项目--也就是说，如果C依赖于B依赖于A，而我更改了A，它将不会尝试构建B，除非A编译，等等。可以说这是有利的，但我发现，如果-例如，我在A中更改了一个在B和C中广泛使用的接口，则需要一些时间来修复该更改中的所有错误……

另一个问题是如何使用工厂类。项目的某些方面依赖于外部jars。有时(谢天谢地)这些更新，我们不得不迁移。我们倾向于通过使用Factory类来处理这个问题，该类指向外部代码的正确版本(因此我们不必在整个代码库中更改所有实现)。

目前，所有这些都在大型项目中，但我认为，通过切换到子项目，我可以为实现新的外部代码开发一个新的项目，确保子项目具有充分的功能和测试，然后切换用户项目中的依赖项/工厂类。但是，由于在整个大型项目中广泛使用接口，这变得更加复杂。例如

• 子项目A-包含接口
• 子项目B-依赖于接口和旧外部jar的A
• 子项目C-依赖于B(因此是A和旧的外部jar)，并包含一个使用B接口实现的Factory类

如果我需要更改B的外部罐子，我可以：

• 创建子项目B_ii -再次依赖于A，现在新的外部jar
• 完成功能后，我可以将C的依赖项添加到B_ii中，并将Factory类更改为使用新的接口实现。
• 当这一切都起作用时，我可以将C的依赖项移除到原始的B中，如果需要，可以删除子项目B。
• 这样做是明智的吗？

因此，总的来说，我的问题是：

• 有谁有过分拆大型项目的经验吗？有没有什么你愿意分享的小窍门？
• 这对您的开发和构建时间有什么影响？
• 关于这样一个项目的结构，你能给出什么建议？

Answer 1

我将在这个(伟大的Q BTW！)的第一个快速剪裁：

在大型项目(即小的子项目)上强加一个结构会减缓编译器的速度吗？

这还不够重要，开销实际上是在Maven调用中。

另外，我对IDE中的编辑时间可能会产生什么样的影响(我们主要使用Intellij)有一点小小的关注。Intellij似乎依次通过依赖树构建每个项目--也就是说，如果C依赖于B依赖于A，而我更改了A，它将不会尝试构建B，除非A编译，等等。可以说这是有利的，但我发现，如果-例如，我在A中更改了一个在B和C中广泛使用的接口，则需要一些时间来修复该更改中的所有错误……

不同的IDE在Maven绑定和依赖关系管理方面有不同的优势。目前的情况似乎是，它只适用于最新的Eclipse和IntelliJ --但您必须告诉开发人员“磁盘刷新源文件和重建所有相关maven项目”的紧急双击。

我发现现在我不得不越来越少地这样做了。有一个SSD驱动器使这里的BTW巨大的不同。

snip工厂类段落

依赖关系管理是非常重要的，不管使用什么技术(Maven/Ivy/任何技术)来帮助您实现它。

首先，我将从Maven依赖插件中获取大量的报告，并评估您所拥有的内容。一般来说，您在POM的依赖性管理中将依赖性设置在尽可能高的食物链上，但没有更高的依赖性。因此，如果您的两个子模块使用外部依赖项，那么将其拖到它们的父POM中，以此类推。

外部JAR的升级应该始终作为一个适当的小型项目进行。评估你为什么要升级，修改源代码来利用任何新的特性/错误修正等等。只是在没有这个分析和工作的情况下碰撞版本就会给你带来麻烦。

所以，总的来说，我的问题是:有谁有过分拆大型项目的经验吗？有什么你愿意分享的>技巧/技巧吗？

• 接口和依赖项注入是您的朋友。
• 迈克尔·费瑟关于有效地处理遗留代码的书是必读的。
• 集成测试是您的朋友
• 将子项目拆分为foo(仅限接口！)而且foo-core和拥有的模块只依赖foo-api，这大大有助于实现分离。
• Jboss模块和/或OSGi可以帮助强制执行干净的分离

这对您的开发和构建时间有什么影响？

非常小的影响开发和建设时间-一个巨大的增长时间，为我们的整体持续交付管道。

关于这样一个项目的结构，你能给出什么建议？

把小事情做好，大事情就会干干净净地掉下来。所以，把事情一分为二--不要对整批产品进行大规模的重组，除非你的集成测试有很高的覆盖率。

在拆分之前编写集成测试--在拆分之后，您应该大致得到相同的结果(S)。

画出你现在和你想要达到的模块化的图表。设计中间步骤。

不要放弃-一些牦牛剃须现在建立了基础，能够“快速建立和重建没有恐惧”无Shameless插头->和我的基础良好的Java开发人员。

祝你好运！

Answer 2

我对此的看法只有在必要时才是分开的。然而，这引出了下一个问题:我如何确定是否有必要？

• 当工件不同时(即不要在同一个项目中构建EAR、WAR、JAR、集成测试-jar)。
• 在分离过程中，您注意到某些代码需要存在于多个工件中，将它们重构为一个新的工件。
• 当您的团队之外的其他项目想要使用您在项目中拥有的东西时。

原因之一是开发人员必须处理多个项目，并试图找出Java包应该属于什么项目。我曾经参与过一些项目，在这些项目中，它变得非常贫乏，并且有一个只有四个类实现一个功能的项目，仅仅因为这是体系结构的方向。这也是在Maven流行之前出现的，因此在IDE和Ant脚本上都需要设置类路径和不需要设置的内容。

另一个原因是你会有更多的移动部件需要处理的管道周围的文件，你可能会有依赖意大利面条之前，你知道它。

重构在项目内部也更容易，而不是跨项目。

如果构建时间是一个问题，那么只需提供更好的硬件。