Herangehensweise an ein Projekt?

[javalui]

Hi,

ich hab schon mehrere miniProjekte geschrieben. Dazu habe ich mir bisher immer erst ein GUI auf einem Block skizziert dieses dann umgesetzt und dann angefangen die Funktionen dahinter zu packen.
Jetzt plane ich allerdings ein etwas größeres Projekt und daher wollte ich einmal fragen ob es irgend eine Lektüre gibt die ich mir zu gemüte führen kann die einem in etwa zeigt wie man an ein "größeres" Java (oder im allgemeinen) Projekt rangeht?

greez
javalui

 

[Spellsleeper]

Schau mal ob dir hier was zusagt:
Highscore - Der moderne Softwareentwicklungsprozess mit UML
Galileo Computing :: Objektorientierte Programmierung - Das umfassende Handbuch
Galileo Computing :: IT-Handbuch fuer Fachinformatiker – 11 Software-Engineering

Gruß Spellsleeper

 

[Antoras]

Das Wichtigste ist grundsätzlich die eigene Erfahrung. Erst wenn du etwas falsch machst kannst du lernen wie es besser geht.
Man sollte sich am Anfang deswegen nicht zu sehr den Kopf über Software Architektur zerbrechen - es geht sowieso schief, egal ob man auf Erfahrungswerte anderer zurückgreifen kann oder nicht.

Ich kann dir auch gleich sagen, dass du alles, was du versuchst neu zu erfinden, am Ende in die Tonne kippen kannst, weil nichts vernünftiges dabei rauskommen kann. Weiter kann ich dir alle möglichen Frameworks aufzählen und dir raten, dass du sie benutzen sollst (eben weil sonst kein gescheiter Code rauskommt).

Das lasse ich aber und sag dir statt dessen, dass dir nichts anderes übrig bleibt, als einfach anzufangen, Fehler zu machen und zu lernen warum du das was du die letzte Zeit so alles gemacht hast nicht nochmal machen sollst.

 

[Spellsleeper]

Ich gebe Antoras hauptsächlich recht, allerdings gibt es viele Methoden die bei der Planung von Projekten nützlich sind. Natürlich ist es bei privaten Projekten nicht sinnvoll mit Netzplantechniken oder ähnlichem anzufangen aber UMLs und auch andere Planungsmethoden können ein Projekt zumindest teilweise deutlich übersichtlicher und erfolgsversprechender machen.

Und damit meine ich nicht das du dein komplettes Projekt erst einmal grafisch festhalten sollst, sondern an kritischen Stellen ,wie sie bei größeren Projekten manchmal vorkommen, diese Techniken benutzt.

 

[homer65]

Wichtig ist erst mal - unabhängig von der Programmierung - das du verstehst wofür das Projekt überhaupt gut ist.
Eben, was damit erreicht werden soll.
Danach kannst du versuchen das Projekt in kleinere Teile zu zerlegen.
Die kleinen Teilprojekte packst du dann nach und nach einzeln an.
Und zum Schluß bastelst du alles zum großen Projekt zusammen.

 

[Landei]

Ein wichtiger Teil der Projektplanung, der oft vergessen wird: Gucken, welche ähnlichen Projekte es gibt (und es entweder besser machen oder sein lassen - oder beim anderen Projekt mitmachen), und welche Bibliotheken man verwenden kann.

 

[Gast2]

aber UMLs [...] können ein Projekt zumindest teilweise deutlich übersichtlicher und erfolgsversprechender machen.

UML ist erst der zweite Schritt ... Untersuchung haben gezeigt das man bei UML-Diagrammen (bzw. sämlicher CAD-Software) mehr damit beschäftigt ist sich durchs Programm zufinden als kreative Arbeit zu Leisten ... Bleistift und Zettel (am besten blank) sind am Anfang die richtige Wahl ... nach dem Papierchaos und -krieg kommt UML um das ganze übersichlicher darzustellen ... dann kommen mit dem UML auch die Feinheiten und die Architecktur (?)

ansonsten - ein Fahrplan für ein Projekt ist immer gut

 

[mkuballa]

Hi,

hast du vor alleine oder in einem Team zu entwickeln?

 

[noobadix]

Hallo,

den Vorrednern zum Trotz und als Verfechter der These "Man muss nicht jede Generation dieselben Fehler machen lassen.", erzähle ich dir was ich bei meinem nächsten Projekt besser machen würde:

A)
Erst die Spezifikation, dann den Code
Bislang habe ich das im Kopf erledigt, aber wenn ich dann nach zwei Jahren auf eine Klasse gestoßen bin, habe ich mich schon mal gefragt, was ich mir dabei gedacht habe oder war der Überzeugung, dass ich irgendeinen Aspekt dabei nicht mehr rekonstruieren kann. Es ist auch machbar, die Spezifikation als Dokumentation zu schreiben.

B)
Platz für Neues lassen/Aufgaben differenzieren und in eigene Klassen tun
Weil mir beim Schreiben dann noch Ideen kamen, teilweise auch nach vermeintlicher Beendigung des Projekts, war ich verärgert, dass ich so viel ändern musste. Z.B. wollte ich dann noch einen Logger einbauen und musste dann in ca. 80 Klassen das Exception-Handling bearbeiten. Was besser gewesen wäre: Ein Objekt, das diese Funktion übernimmt und beim Nachrüsten wäre dann nur dessen Klasse zu bearbeiten gewesen.

C)
Wissen, was man tut
Es ist mühsam und scheint (und ist auch leider oft) überflüssig, über die verwendeten Bibliotheken und Funktionen alles zu wissen. Jedoch können einem dabei Vorteile entgehen und der Code ist freilich fehleranfälliger. Z.B. erfuhr ich erst spät, dass AWT und SWING nicht so gut zusammen passen.

D)
Teamarbeit
Ein Mitentwickler kann von Vorteil sein und den Freudenfaktor erhöhen. Arbeit kann geteilt werden und mehr Ideen-Potential vorhanden sein.

Joa, das ist, was mir so aus dem Ärmel fällt.

Gruß und eine gute Frustration/Erfolg-Ratio

 

[Naaram]

Ein Paar Tipps von mir, auch exact Diametral zu meinem Vorredner:

Aufgabe immer in kleine Teile zerlegen, dann agilem Ansatz folgen:

1. Was ist das kleinste Programm, was schon was macht (wo man was sieht, was etwas berechnet usw.). Dieses wird dann irgendwie umgesetzt. Für ein Paar Frameworks (Logging, GUI, Netzwerk) muss man sich meist davor entscheiden, der Rest ist egal.

2. Das Umgesetzte Programm wird dann getestet. Manuell reicht meist nicht, ein Paar automatische Tests sind Pflicht. Manche (aber sehr wenige) schreiben die Tests sogar zuerst.
Wichtig: Tests sind die wichtigste Dokumentation und Spezifikation, weil sie immer die Wahrheit sagen. Papier ist geduldig, aber nur wenn der Test durchläuft ist die Funktion drin und fertig.

3. Nun fängt das Design an. Man schaut das Programm an und überlegt sich was man besser machen kann. Dann heist es refactoring, refactoring und nochmal refactoring. Bis man selber sagt das Design ist sehr gut.

4. Man nimmt das nächste Feature und fängt bei 1 an.

Ich hätte vor 5 Jahren nie geglaubt, dass das so funktionieren kann, aber nun bin ich in einem Projekt, und zwar seit über 1 Jahr zudritt, und das Produkt hat fast keine Bugs bei wöchentlich wechselden Anforderungen. Dabei sieht der Code auch noch extrem gut designed aus, obwohl alles on the fly entstanden ist.

 

[javalui]

Danke schonmal für die vielen guten ansätze. Bisher bin ich auch mit zettel und bleistift an die sachen ran gegangen. Das Problem war nur immer, dass mir oft im nachhinein sachen einfallen und ich dann wiederum alles umwerfen musste wodurch mein ganzer plan auf dem papier jedes mal nutzlos oder unübersichtlich wurde.
Mein Hauptproblem ist denke ich, dass ich bisher kaum Projekte erstellt habe bei denen ich etwas mit dem GUI zu tun hatte. Jetzt mache ich das alleine und verstehe manche zusammenhänge nicht oder nicht richtig.

z.B. Ich habe meine main klasse und meine gui klasse wenn ich in meinem Gui z.b. einen button klicke dann führt dieser button mit einer action code aus... aber den code sollte doch eigendlich meine main klasse verwalten oder liege ich da falsch??? Wird beim gui die gui klasse zur main klasse?

wäre super wenn ich dazu ein mini abstractes beispiel bekommen könnte

nochmal danke für die vielen antworten bisher

 

[javalui]

meine güte das frustriert einen ja... ich werde mir jetzt nochmal das kapitel über statische methoden und variablen zu gemüte führen weil ich langsam den überblick verliere. Man sollte einfach nicht immer eclipse vorschläge annehmen