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 

• Приложение построено как единая ВОЙНЫ
• Разработчики развертывают единый уровень (typicall y WebTier) как артефакт от Eclipse или IntelliJ к их местному Tomcat
• Хотя проект кажется красиво разделенным в модулях, между ними есть много нежелательных точек соединения. Специально в Shared, где модули, нуждающиеся в «кросс-модули» доступ положить свои услуги
• Все интеграционные тесты находятся в специальном модуле (не знаю, почему)

Идеи, чтобы сделать его лучше

• Добавить модуль MessageBroker, чтобы обеспечить свободное соединение, если это необходимо. Может быть, JMS, или просто тупой компонент в памяти для синхронной связи
• Избавиться от Shared модуля
• Убедитесь, что модули имеют крупнозернистый начальный точки
• Удалить нежелательную связь между братьями и сестрами и предпочитают сообщение брокер когда возможно
• Возможно сохранение Entities. По крайней мере, основные компании (Customer, CustomerFile, ...). Но некоторые сущности, очевидно, принадлежат к одному модулю (а информация исполнения партии будет в Batch модуле)

Таким образом, любой желающий сделать изменения в ModuleA бы большую часть времени только строить и запускать тесты в этом модуле без опасаясь разорвать заявку.

Вопросы

• ли это, кажется, как хороший план?К счастью, я имею в виду будущие доказательства с хорошими шансами улучшить ситуацию и не требуя чрезмерного объема работы, учитывая ситуацию.
• Если у нас есть 1 проект Eclipse/IJ на уровне, дайте IDE построить артефакт и развернуть его для Tomcat, или у нас есть 1 проект на модуль и зависимости от Nexus? Или, может быть, последний вариант является излишним?
• Любые другие предложения?

Некоторые показатели

• для Windows 7, Java 8, Maven 3.0.3, TestNG.
• SSD или HDD 7200rpm (ограниченное воздействие)
• 6Gb RAM
• Heap 1Gb (специалист)
• CI с Дженкинс

Благодаря кучу!

Answer 1

CI был бы реальным ответом, но, похоже, ваш проект не является модульным, как и должно быть. Каждый раз вы не строите весь проект с нуля. Вы строите банки, проверяете их в разных проектах, а затем используете как отдельные элементы. Каждый проект должен быть достаточно маленьким и охватывать только одну область. Считаете ли вы, что Java-сборки, скажем, банки безопасности, когда они работают с пакетом io? Разделите и победите - вот и вся идея ООП и инкапсуляция.

Answer 2

Это может быть не так плохо, как вы думаете. Вложенные проекты с модульными тестами и статическим анализом занимают некоторое время.

Компания, в которой я работал, имела> 1hr build + unitTest + CodeCoverage. Это не учитывает время, необходимое для отправки артефакта в vSphere для автоматического тестирования сквозного тестирования установщика на 26 языках, поддерживаемых операционными системами x 8.