Java Projekt wird zu groß

Question

Wir haben ein großes Java 8 Spring Hibernate Maven Projekt, das immer größer wird.

Probleme:

• Bauzeit ist 10-12 besten Minuten; 3 Minuten ohne
• Tests, die wir bereits einen Befehlszeilenschalter müssen selten geändert Module zu überspringen, das ist das Symptom des Build-Prozesses zu erreichen praktische Grenzen
• Eclipse kämpfen, um das Projekt zu verwalten (obwohl IntelliJ für jetzt in Ordnung ist)
• Die Dinge werden schlimmer, wenn das Projekt wächst und mehr Szenarien vom Testteam als Integrationstests in die Codebasis integriert werden.

Wie wir arbeiten jetzt

• Das Projekt in etwa 20 Maven Module konfiguriert ist, etwa so:

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

• Die Anwendung als einzelne WAR gebaut
• Entwickler implementieren eine einzelne Tier (typical y WebTier) als ein Artefakt von Eclipse oder IntelliJ zu ihrem lokalen Tomcat
• Obwohl das Projekt in Modulen gut aufgeteilt scheint, gibt es viele unerwünschte Kopplungspunkte zwischen ihnen. Speziell in Shared, wo Module "cross-Module" Zugriff setzen ihre Dienste
• Alle Integrationstests sind in einem eigenen Modul (keine Ahnung warum)

Ideen machen es besser

benötigen
• Fügen Sie ein MessageBroker Modul hinzu, um gegebenenfalls eine lose Kopplung zu ermöglichen. Vielleicht JMS oder einfach eine dumme In-Memory-Komponente für die synchrone Kommunikation
• des Shared Modul Befreien Sie
• Stellen Sie sicher, Module hat grobkörnigen Eintrag Punkte
• entfernen unerwünschte Kopplung zwischen Geschwistern und bevorzugt den Nachrichten-Broker, wenn möglich
• Könnte halten Entities. Zumindest die Kerngeschäftseinheiten (Customer, CustomerFile, ...). Aber einige Unternehmen gehören offenbar zu einem einzigen Modul (eine Batch-Ausführung Info im Batch Modul sein würde)

So jemand eine Änderung an ModuleA machen würde die meiste Zeit nur bauen und laufen Tests in diesem Modul ohne Angst, die Anwendung zu brechen.

Fragen

• Heißt das, wie ein guter Plan zu sein?Mit gutem, ich meine zukunftssicher, mit guten Chancen, Dinge zu verbessern, und keine übermäßige Menge an Arbeit angesichts der Situation
• Sollten wir 1 Eclipse/IJ Projekt pro Tier haben, lassen Sie die IDE das Artefakt bauen und bereitstellen zu Tomcat, oder sollten wir 1 Projekt pro Modul und Abhängigkeiten zu Nexus haben? Oder vielleicht ist die letztere Option übertrieben?
• Irgendwelche anderen Vorschläge?

Einige Metriken

• Windows 7, Java 8, Maven 3.0.3, TestNG.
• SSD oder HDD 7200rpm (begrenzte Auswirkungen)
• 6 Gb RAM
• Heap 1Gb (Maven)
• CI mit Jenkins

Dank einem Haufen!

Answer 1

CI wäre eine echte Antwort, aber es sieht so aus, als ob Ihr Projekt nicht modular ist, wie es sein sollte. Sie bauen nicht jedes Mal ein komplettes Projekt von Grund auf neu. Sie bauen Gläser, testen sie in verschiedenen Projekten und verwenden sie dann als einzelne Elemente. Jedes Projekt sollte klein genug sein und nur ein Gebiet abdecken. Glauben Sie, dass Java-Builds Sicherheitsjars erstellen, wenn sie am io-Paket arbeiten? Teilen und überwinden - das ist die Idee von OOP und Kapselung.

Answer 2

Dies ist möglicherweise nicht so schlimm, wie Sie denken. Involvierte Projekte mit Komponententests und statischen Analysen dauern eine Weile.

Eine Firma, für die ich gearbeitet habe, hatte> 1 Std Build + UnitTest + CodeCoverage Integrationszeiten. Die Zeit, die für den Versand des Artefakts an vSphere erforderlich ist, wird nicht gezählt, um automatisierte Clickthrough-Tests des Installationsprogramms auf 26 Sprachen x 8 unterstützten Betriebssystemen durchzuführen.