Java 项目变得太大

Question

我们有一个越来越大的 Java 8 Spring Hibernate Maven 项目。

问题:

• 构建时间最多为 10-12 分钟； 3 分钟无测试
• 我们已经有了一个命令行开关来跳过很少修改的模块，这是构建过程达到实际限制的症状
• Eclipse 难以管理项目(尽管 IntelliJ 目前还可以)
• 随着项目的发展，以及随着测试团队的更多场景被合并为代码库中的集成测试，情况变得越来越糟。

我们现在的工作方式

• 该项目配置了大约 20 个 Maven 模块，如下所示:

    Parent    |--- Tier1    |--- Tier2    |--- WebTier         |---- ModuleA         |---- ModuleB         |---- ModuleC         |---- ...         |---- Entities         |---- Shared         |---- Batch         |---- IntegrationTests

• 应用程序构建为单个 WAR
• 开发人员将单个层(通常是 WebTier)作为 Eclipse 或 IntelliJ 的 Artifact 部署到他们的本地 Tomcat
• 虽然该项目看起来很好地划分为多个模块，但它们之间存在许多不需要的耦合点。特别是在 Shared 中，需要“跨模块”访问的模块放置它们的服务
• 所有集成测试都在一个专用模块中(不知道为什么)

让它变得更好的想法

• 添加一个 MessageBroker 模块以允许相关的松散耦合。也许是 JMS，或者只是一个用于同步通信的愚蠢的内存组件
• 去掉 Shared 模块
• 确保模块具有粗粒度的入口点
• 消除 sibling 之间不需要的耦合，尽可能使用消息代理
• 可能会保留实体。至少是核心业务实体(Customer、CustomerFile 等)。但是一些实体显然属于单个模块(批处理执行信息将在 Batch 模块中)

这样，任何对 ModuleA 进行更改的人大部分时间都只会在该模块中构建和运行测试，而不必担心破坏应用程序。

问题

• 这看起来是个好计划吗？好的，我的意思是面向 future ，有很好的机会改进事情，并且在这种情况下不需要过多的工作
• 我们应该每层有 1 个 Eclipse/IJ 项目，让 IDE 构建 Artifact 并将其部署到 Tomcat，还是应该每个模块有 1 个项目，并依赖于 Nexus？或者后一种选择可能有点矫枉过正？
• 还有其他建议吗？

一些指标

• Windows 7、Java 8、Maven 3.0.3、TestNG。
• SSD 或 7200rpm HDD(影响有限)
• 6Gb 内存
• 堆 1Gb (maven)
• 与 Jenkins 的持续集成

非常感谢!

Answer 1

CI 将是真正的答案，但看起来您的项目没有像它应该的那样模块化。您不会每次都从头开始构建整个项目。您构建 jar ，在不同的项目中测试它们，然后作为单个项目使用。每个项目都应该足够小并且只覆盖一个区域。你认为 Java 在 io 包上工作时会构建安全 jar 吗？分而治之——这就是 OOP 和封装的全部思想。