Projekt Java staje się zbyt duży

Question

Mamy duży projekt Java 8 Spring Hibernate Maven, który jest coraz większy.

Problemy:

• czas budowy wynosi 10-12 minut w najlepszym wypadku; 3 minuty bez testów
• Mamy już przełącznik wiersza polecenia, który pomija rzadko modyfikowane moduły, co jest symptomem procesu kompilacji osiągającego praktyczne granice.
• Eclipse walczy z zarządzaniem projektem (chociaż IntelliJ jest w porządku na razie)
• Sytuacja pogarsza się wraz z rozwojem projektu, a kolejne scenariusze z zespołu testowego zostają zindeksowane jako testy integracyjne w bazie kodu.

Jak pracujemy teraz

• Projekt jest skonfigurowany w około 20 modułów Maven, tak:

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

• Aplikacja zbudowana jest w postaci pojedynczej WOJNY
• Deweloperzy wdrażają pojedynczą warstwę (typicall) y WebTier) jako artefakt od Eclipse lub IntelliJ do lokalnego Tomcata
• Chociaż projekt wydaje się ładnie podzielony na moduły, istnieje wiele niepożądanych punktów sprzężenia między nimi. Specjalnie w Shared, gdzie moduły wymagające „cross-moduły” dostęp umieścić swoje usługi
• Wszystkie testy integracyjne są w dedykowanym module (nie wiem dlaczego)

Pomysły zrobić to lepiej

• Dodaj moduł MessageBroker, aby zezwolić na luźne sprzężenie, jeśli jest to konieczne. Może JMS, lub po prostu głupie składnikiem pamięci dla komunikacji synchronicznej
• Pozbądź modułu Shared
• Upewnij się, że moduły mają gruboziarnistych entry-punkty
• usunąć niepożądane sprzężenia pomiędzy rodzeństwem i wolą brokera wiadomość, gdy możliwe
• Może zachować Entities. Przynajmniej podmioty core-business (Customer, CustomerFile, ...). Ale niektóre podmioty oczywiście należą do jednego modułu (a Informacje wykonanie partii byłoby w module Batch)

W ten sposób, każdy dokonywania zmian do ModuleA będzie przez większość czasu tylko budować i testy zakończą się w tym module bez obawiając się złamania aplikacji.

Pytania

• Czy to wydaje się dobry plan?Przez dobro, mam na myśli przyszłość, z dużymi szansami na poprawę rzeczy i nie wymagającą nadmiernej ilości pracy z uwagi na sytuację.
• Powinniśmy mieć 1 projekt Eclipse/IJ na poziom, niech IDE zbuduje artefakt i wdroży go do Tomcat, czy powinniśmy mieć 1 projekt na moduł i zależności od Nexusa? A może ta druga opcja to przesada?
• Jakieś inne sugestie?

Niektóre dane

• Windows 7, Java 8, Maven 3.0.3, TestNG.
• SSD lub dysk twardy 7200 obr./min (ograniczony wpływ)
• 6Gb RAM
• Heap 1GB (Maven)
• CI z Jenkins

Dzięki kilka!

Answer 1

CI byłaby prawdziwą odpowiedzią, ale wygląda na to, że projekt nie jest modułowy, jak powinien. Nie budujesz całego projektu od początku za każdym razem. Budujesz słoiki, testujesz je w różnych projektach i używasz jako pojedynczych przedmiotów. Każdy projekt powinien być wystarczająco mały i obejmować tylko jeden obszar. Czy myślisz, że Java buduje powiedzmy słoiki bezpieczeństwa, gdy pracują na pakiecie io? Dziel i rządź - to cała idea OOP i enkapsulacji.

Answer 2

To może nie być tak źle, jak myślisz. Zaangażowane projekty z testami jednostkowymi i analizą statyczną wymagają czasu.

Firma, w której pracowałem, miała> 1 godz. Kompilacji + czasy integracji unitTest + CodeCoverage. To nie liczy czasu potrzebnego na wysłanie artefaktu do vSphere w celu automatycznego testowania kliknięcia instalatora na obsługiwanych systemach 26 języków x 8.