Software planen - Wie vorgehen?

M

mas666

Mitglied
Hallo zusammen

Ich habe jetzt schon ein paar Jahre Java-Erfahrung und habe einige kleinere Projekte realisiert. Ich stehe aber immer ab einem bestimmten Zeitpunkt vor einem mittleren Chaos das ich dann aufräumen und strukturieren muss. Dann gibt es duplizierten Code oder schlechten Stil, weil ich die Applikation nicht richtig geplant habe.

Deshalb suche ich für mein nächstes Projekt (Klassische Client/Server Applikation mit Daten aus DB; Client als Desktop-App, Server als Windows-Dienst) Strategien zur Planung und Entwicklung meines Projektes. Anders als sonst möchte ich vorgängig evaluieren anstatt einfach drauf los zu hacken...

Deshalb folgende Fragen:

  • Welches Framework würdet ihr für das DB-Management benutzen? JPA? Hibernate? Java Ultra-Lite Persistence? Habt ihr gute Erfahrungen mit einem bestimmten Framework?
  • Wie stellt ihr GUIs her? Von Hand? Mit NetBeans oder Eclipse?
  • Wie testet ihr? Ich bin endlich von meiner System.out.println-Methode weggekommen und habe mich mit UnitTests auseinandergesetzt. Schreibt ihr Tests und implementiert dann? Oder umgekehrt?
  • Ich habe keine Ahnung von Java EE. Wäre meine Anwendung nicht eigentlich eine klassische Java EE Anwendung? Wo liegen die Unterschiede zur klassischen Entwicklung? Welche Vorteile bietet sie?

Ich bin dankbar für jede Bemerkung zum Thema. Danke für eure Bemühungen.

Gruss
mas
 
Hallo mas,

deine Fragen sind alle zu generell und lassen sich ad hoc nicht präzise beantworten. Das hängt immer von den funktionalen und nichtfunktionalen Anforderungen ab. Worum geht es in dem Projekt genau? Wie umfangreich wird es? 10 Views? 100 Views? 1000 Views? Welche Domainobjekte hast du? Muss auf vorhandene Hardware geachtet werden? Gibt es in Bezug auf Performance, Sicherheit etc. Vorgaben... es gibt eine Menge Fragen die geklärt werden müssen.

Auch wenn du es nicht gern hörst, empfehle ich dir ein wenig Literatur zum Software Engineering. Sprich: Anforderungsanalyse, Design, Implementieren usw. Hier hilft ein wenig strukturierteres Vorgehen, auch wenn es am Anfang ein wenig schwieriger wird.

z.B.:
Welches Framework würdet ihr für das DB-Management benutzen? JPA? Hibernate? Java Ultra-Lite Persistence? Habt ihr gute Erfahrungen mit einem bestimmten Framework?
Wie stellt ihr GUIs her? Von Hand? Mit NetBeans oder Eclipse?
Zum Vergrößern anklicken....
Das hängt davon ab was gefordert wird. Unter bestimmten Umständen benötigst du vllt gar kein ORM-Framework, da reicht es vielleicht wenn auf Domainobjektebene die Persistenz gesteuert wird, spricht wozu Hibernate, wenn du nur eine Hand voll Objekte mit simplen CRUD-Operationen hast usw. Das gilt es abzuwägen.

Bei der GUI dasselbe, ist die Applikation recht simpel und gibt es keine besonderen Anforderungen an die GUI (z.B. keine Custom Elemente, Standarddesign...) ist es sicherlich sinnvoll und schneller einen GUI-Builder zu nehmen. Hast du spezielle Anforderungen, bekommst du damit sicherlich Probleme.
Wie testet ihr? Ich bin endlich von meiner System.out.println-Methode weggekommen und habe mich mit UnitTests auseinandergesetzt. Schreibt ihr Tests und implementiert dann? Oder umgekehrt?
Zum Vergrößern anklicken....
Die Antwort hier kann eigentlich nur lauten, testen ist immer sinnvoll. Test first, testen während der Entwicklung oder danach, wie auch immer es aussehen mag, da streiten sich die Leute. Ich bevorzuge den Test zuerst zu schreiben, oder zumindest die Interfaces in der Designphase zu deklarieren und anschließend den Test vor der Implementierung zu schreiben.

Ich habe keine Ahnung von Java EE. Wäre meine Anwendung nicht eigentlich eine klassische Java EE Anwendung? Wo liegen die Unterschiede zur klassischen Entwicklung? Welche Vorteile bietet sie?
Zum Vergrößern anklicken....
Auch hier: Nicht zu beantworten. Meinst du eine Webanwendung generell oder meinst du eine Enterprise Anwendung? Java EE hat diverse Funktionalitäten wie Transaktionen und Security...

Gruß
 
Hey Socke,

Herzlichen Dank für Deine Antwort.

Deine Annahme, ich sei lesefaul, empört mich ;) Natürlich habe ich mir Literatur besorgt. Balzerts "Lehrbuch der Objektorientierung" macht den Anfang und dann schaue ich weiter. Aber im Grunde hast Du natürlich Recht. Mir brennt es unter den Fingern und am liebsten würde ich sofort losprogrammieren und nicht zuerst viel lesen... Aber eben gerade das will ich diesmal vermeiden.

Ich verzichte hier darauf, Details zu meinem Projekt zu nennen. Erstens will ich nicht euch meine Arbeit machen lassen und zweitens habe ich ja kein Interesse, dass ihr mir sagt, was ich jetzt genau machen, sondern wieso ich mich für einen bestimmten Weg entscheiden soll.

In dieser Beziehung hast Du mir schon einmal weiter geholfen.

- Ich habe nur wenige Objekte (10 DB-Tabellen) deren Persistenz ich mit CRUD-Operationen gut im Griff habe. Ich werde auf Hibernate o. ähnl. verzichten.
- Die GUIs werden je nach DB-Eintrag verschieden generiert. Ich werde deshalb meine GUIs von Hand erstellen.
- Ich werde versuchen, die Testfälle vor der Implementation zu schreiben. Ich empfehle dazu den Artikel: http://www.objectmentor.com/resources/publishedArticles.html --> Craftsman

Ich melde mich, wenn ich konkretere Fragen habe.

Gruss
mas
 
Ich würde mich auch nicht zu früh an die GUI wagen – das ist so ziemlich das letzte, was du brauchst. Außerdem hängt die GUI von der dahinter liegenden Struktur ab, aber nicht umgekehrt.
 
Mein Senf:
Anforderungsanalyse: Je mehr man da vorzeitig investiert, desto weniger wird man später überrascht. Komplexe Anforderungen sind im Nachhinen immer teuer.

Testing: Vorher anfangen, das heisst: Prozesse definieren/dokumentieren/zeichnen. Änderungen werden zuerst im Prozess geändert. Und dann im Code. Erst wenn man die Prozesse komplett abgebildet hat, also auch Fehlerfälle, und versteht, kann man sie auch testen. Ob du die Tests vorher oder nachher schreibst ist insofern irrelevant, weil das wichtigste ist, dass du sie 1. überhaupt geschrieben hast und 2. dass du sie immer up to date hälst. Also nach Änderungen müssen sie immer noch grün sein, bei weiteren Use Cases müssen diese auch durch Tests abgedeckt werden. Wenn du Tests schreibst, empfehle ich, sie vorher zu schreiben.

Syso: Nimm ne logging-api wie zum Beispiel log4j

Grundlegendes zum Thema "schöner programmieren":
http://de.wikipedia.org/wiki/Lose_Kopplung
http://de.wikipedia.org/wiki/GRASP#High_Cohesion
Das sind zwei Grundprinipien in der Objektorientierten Programmierung, mit denen hat man so prinzipiell eigentlich schon viel gewonnen: Möglichst wenig Abhängigkeit zwischen Klassen und "nur das in eine Klasse reintun, was auch wirklich reingehört".

viel Spass =)
slowfly
 
Um antworten zu können musst du eingeloggt sein.

Neue Beiträge

Zurück