我有一个大型的Java项目，我们在构建周期中使用了maven。这个项目被广泛使用-在其他项目中，在各种应用程序中，其中一些包含在其中，有些则在其他地方...老实说，这有点混乱（针对特定时间，在不同时间添加了不同的位目的），我想对其进行清理。另外，它还没有经过完全测试（没有适当的单元和集成测试就添加了很多位），并且有些测试需要很长时间才能运行或实际上没有通过……（嗯）测试在Maven构建周期中关闭（再次，呃，哦）。
我正在考虑将这个大型项目分成较小的特定项目，以使“最终”子项目（或几个子项目）可以选择所需的各个子项目。
我的想法如下：
- 如果我将一个大型项目分为多个子项目，这将清楚说明每个项目的责任。
- 通过分成多个子项目，我可以分别清理每个子项目的测试，然后在maven构建周期中打开该子项目的测试。
我有点担心这可能会对构建时间产生影响。
- 在大型项目上（即放入较小的子项目中）采用结构会减慢编译器的速度吗？
另外，我对这可能会对IDE中的编辑时间产生什么影响（我们主要使用Intellij）略有担忧。Intellij似乎是通过依赖关系树依次构建每个项目的-例如，如果C依赖于B依赖于A，而我更改了A，除非A进行编译，否则它不会尝试构建B。可以说这是有好处的，但是我发现，例如，如果我更改了A在B和C中广泛使用的接口，则需要花费一些时间来修复该更改中的所有错误...
另一个问题是如何使用工厂类。该项目的某些方面取决于外部罐子。有时（非常不经常）更新这些内容，因此我们必须进行迁移。我们倾向于使用Factory类来处理此问题，该类指向外部代码的正确版本（因此，我们不必在整个代码库中更改所有实现）。
目前，这一切都在大型项目中，但是我认为通过切换到子项目，我可以开发一个新项目来实施新的外部代码，确保子项目功能完整并经过测试，并且然后在用户项目中切换依赖项/工厂类。但是，由于在整个大型项目中大量使用接口，因此使情况变得更加复杂。例如
- 子项目A-包含接口
- 子项目B-取决于A的接口和旧的外部jar
- 子项目C-依赖于B（以及A和旧的外部jar），并且包含一个使用B的接口实现的Factory类。
如果需要更改B的外部jar，我可以：
- 创建子项目B_ii-再次取决于A，现在取决于新的外部jar
- 一旦功能完备，我可以将C的依赖项添加到B_ii，并更改Factory类以使用接口的新实现。
当这一切正常的时候，我就可以删除C对原始B的依赖关系，如果需要，可以删除子项目B。
这是明智的做法吗？
因此，总的来说，我的问题是：
- 有没有人有分解大型项目的经验？您是否愿意分享任何提示/技巧？
- 这对您的开发和构建时间有什么影响？
- 您可以在构建此类项目的分解方面提供什么建议？