Hallo zusammen,
ich möchte meine bestehende Software neu erfinden mit modernen Frameworks etc. Dabei möchte ich die Projektstruktur neu aufbauen etc.
Nun die Frage, wie beginnt ihr? Erstellt ihr zu allererst Use-Cases (wenn ja mit einem Tool?) Brecht ihr die Use-Cases auf kleine Aufgaben auf?
Wie startet man professionell in ein neues Projekt?
class Project {
public static void main(String args[]) {
// TODO Implement this!
}
}
Aber mal im Ernst: Die Frage ist schon seeeehr allgemein und breit. Schon zu wissen, ob es um einen Candy-Crush-Klon mit Android geht, oder um eine Datenanalyseplattform für Wettervorhersagen, oder die Notabschaltung für ein Atomkraftwerk, könnte hier helfen.
Danke für Deine Antwort. Wird eine Art Warenwirtschaft (im groben gesagt) Es werden also Produkte angelelgt und so weiter. Weiterhin werden diese Produkte zu anderen System via REST geschickt
Bist du zur Vorlesung gegangen?
Ich hab mehrere Vorlesungen dazu gehört, und es ist, wie @Marco13 schrieb, viel zu allgemein, um sie hier zu beantworten.
Welche Form des Entwicklungsprozesses usw. Und am Anfang steht zumindest mal ein langer Text vor.
Und dann:
Berufliches Umfeld? Frag’ den Projektleiter?
Ja, das ist ein wichtiger Teil von vielen Teilen…
Ernstlich, was möchtest du jetzt von uns hören?
Das Thema kann sich gar nicht zu einer konstruktiven „Diskussion“ entwickeln, es ist viel zu allgemein.
Neben der technischen Sicht dann auch noch so etwas, ob es kurze und direkte Kommunikationswege und flache Strukturen gibt usw. (welche sich gegens. ausschließen…).
Kurz: Was macht jemand, der beruflich etwas mit Computern zu tun hat… Wäre auch so eine Frage…
Ich mache das nebenbei, gibt auch kein Team - Struktur flach genug? 
Das technische steht schon fest, wie Infrastruktur usw. Mir geht es um die reine Programmierung. Alle Funktionen aufschreiben und einfach wild drauf los programmieren? Andere beginnen mit dem Frontend, wie Masken etc dargestellt werden sollen und erst dann entwickeln sie die Logik.
Gut, vielleicht zu umfangreich und viel verlangt euch das zu fragen. Ich werde einfach mal agil drauf los programmieren und Stück für Stück neue Funktionen veröffentlichen, dann wird sich schon zeigen was fehlt
Das ist ein Teil von vielen Teilen… Mock-ups!
Soll das eine Beleidigung in unsere Richtung sein? Denkst du, hier wäre jemand auf den Kopf gefallen?
Warum Beleidigung? Du sagtest doch selbst, es ist viel zu umfangreich?! Ist zu mindestens keine, wenn es falsch rüber kommt tut es mir leid.
Auch wenn “Microservices” ein Buzzword ist, ist das Wichtigste, ein monolithisches System von Anfang an zu vermeiden. Wenn es logische Einheiten gibt, die untereinander nur lose gekoppelt sind, mache Unterprojekte / Module / wie auch immer das in deiner IDE heißt draus. Später auseinanderklamüsern klappt nach aller Erfahrung weniger gut. Ein großer Vorteil ist, dass dadurch die Jar-Hölle kleingehalten wird, d.h. das es weniger wahrscheinlich wird, dass es über transitive Abhängigkeiten zu Versionskonflikten kommt.
Für die Struktur innerhalb der Projekte haben sich gewisse Standards eingebürgert, oft vom verwendeten Build-Tool getrieben (Maven, Gradle…) und der IDE unterstützt. Da würde ich ohne guten Grund nicht von abweichen (insbesondere wenn potentiell mehrere Leute mit arbeiten, eventuell mit unterschiedlichen Tools).
Zum Anfang würde ich mir überlegen, welche Teile man erst mal simulieren / mocken oder sonstwie faken kann, am besten hinter eine Fassade. Das kann z.B. die Oberfläche oder die Datenbank sein. Also immer versuchen, Komplexität zu verringern, ohne es so einfach oder unflexibel zu machen, dass man es nachher nicht mehr im vollen Umfang umgesetzt bekommt.
Auch wichtig: Von Anfang an Tests schreiben. Nicht mit “das lässt sich schlecht testen” rausreden - wenn es das ist, ist es auch schlecht geschrieben.
Danke sehr, solch eine Antwort bringt mich schon mal weiter im denken. Stichwort „Testing“ hab ich bisher ausser acht gelassen, habe alles immer ganz simpel getestet ob es das macht was ich wollte
JUntit emfehlenswert?
Mit dem monilitschen hab ich mir auch schon Gedanken gemacht, nur wie setzt man das um in Java EE? Könnte kleine Module schreiben, all diese kleinen jars in ear packen und deployen. Bisher habe ich alles in eine .war gepackt. Lose Kopplung kann ich mir grad auch nichts darunter vorstellen. Meinst du, dass die Services untereinander über Messaging oder REst oder sonst was kommunizieren und der code an sich nicht serviceübergreifend ist?
Testing ist eine eigene Vorlesung…
lose Kopplung, starke Kohäsion… siehe Wikipedia
Edit: Und mit Mock-ups meinte ich GUI-Mockups… zum Unterschied siehe hier.
Ich würde sagen, JUnit ist für Unit-Testing okay. Für ältere Herren wie mich, die sich die Reihenfolge der Argumente nicht merken können, würde ich obendrauf AssertJ mit einer Fluent API empfehlen.
Habe schon länger kein JEE mehr gemacht (bei mir hieß es noch J2EE), deshalb kann ich zum aktuellen Stand der Kunst nicht viel sagen. Aber die Grundidee von ears ist ja gerade, mherere jars einzubinden.
Lose Kopplung heißt nur, dass Module voneinander wenig „wissen“ müssen, dass also es zwischen den Modulen wenig Abhängigkeiten und Berührungspunkte gibt. Wie kommuniziert wird, ist eine andere Frage, und hängt sehr vom Anwendungsfall ab.
Na, es betrifft nicht nur dich, auch ich merke mir die Argumentenliste nur als Chunks, die nach wenigen Sekunden wieder vergessen sind…
Und hier würde ich dir empfehlen, genau das erstmal anzusehen. Bevor du dein Projekt startest solltest du dich mit den Technologien vertraut zu machen und wenigstens grob prüfen, ob das auch funktionieren kann durch pocs (Proof-of-concept).
Tests empfehlenswert? Ja! Denn abgesehen davon, dass es dir zeigt ob dein getesteter Code funktioniert oder nicht zwingt es dich dazu, testbaren Code zu schreiben. Und testbarer Code steigert schonmal die Qualität. Wenn du dich damit im Vorfeld gewissenhaft beschäftigst wirst du merken, dass du zum testen auch ein mocking-framework brauchst und dann, dass es auch sowas wie Integration Tests gibt (wenn nicht schon bekannt). Sich damit eine Zeitlang zu beschäftigen lohnt sich - denn dein Code wird durch den Anspruch an Testbarkeit einfach anders ausschauen.
Aber das ist nur ein Aspekt von dem ganzen. Mach dir einfach mal Gedanken wie deine fertige Software ausschauen soll und überleg wo du Probleme mit der Implementierung haben könntest.
Nutzt du wirklich Java EE? Eine Sache die du dann auch mal direkt hinterfragen kannst. Warum nicht Spring Boot?
Herzlichen Dank! Spring war mir bisher immer zu viel des guten. Ich wollte es alles erstmal mit “Boardmitteln” versuchen und lernen. ZB Datenbanken über JDBC ansprechen, damit ich weiß inetwa, was hinter JPA abgeht. War auch nicht die schlechteste Idee. Aber werd mich jetzt erstmal mit Testing auseinandersetzen, das find ich ganz hilfreich.