wie fangt ihr ein Projekt an?

[musiKk]

Hi,

ich habe mehrmals die Erfahrung gemacht, dass blindes Drauflosprogrammieren bald nach hinten losgeht. Bestimmte Dinge werden erschwert oder unmoeglich, weil das Design, das man am Anfang vage im Kopf hatte, vielleicht doch nicht so optimal war.

Da ich jetzt wieder eine Idee fuer ein (erstmal) Ein-Mann-Projekt haette und das nicht auch nach ein paar Zeilen aus Frust wieder abbrechen moechte, wollte ich mal fragen, wie ihr so Projekte beginnt.

Einfach drauf los? Etwas auf Zettel kritzeln? Bestimmte Tools? UML?

Letzteres will ich mir grad mal wieder ansehen, aber ich bin mir nicht sicher, ob das so zielfuehrend ist.

Ich hoffe, ihr habt da ein paar Anregungen.

 

[AlArenal]

Erstmal die Features sammeln, die implementiert werden sollen. Dann schauen, was davon wichtig ist und in die erste Version mit rein MUSS. Der Rest ist optional und wird im Hinterkopf behalten, ebenso wie evtl. Ausblicke auf in der Ferne liegende evtl.-vllt-Features.

Dann erstmal die Domain-Schicht schnappen, Daten-Objekte und Interfaces identifizieren. Die lege ich als POJOs meist schon recht früh aber karoeinfach an. Noch kann man ja relativ schnell und flexibel was ändern, wenn einem Zusammenhänge klarer werden und einem noch was einfällt.

Dann mach ich mich meist an Models und stopf die schonmal in eine grob gestrickte Oberfläche mit Views. Erstmal hat man vielleicht noch statische Testdaten im Code, damit man schonmal was sieht. Dann kann man grundlegend an Controllern arbeiten und Stück für Stück alles miteinander verdrahten.

Es ist im Grunde ein iterativer Prozess, bei dem man nach den reinen Überlegungen erstmal mit dem Fundament, also den Daten selbst, anfängt. Der Rest wird Stück für Stück, Feature für Feature entwickelt.

Für UML war ich immer zu faul, die Teams zu klein, die Projektleiter zu borniert. Ich komme persönlich sehr gut damit klar meine Ideen aufzuzeichnen. Abseits standardisierter Methoden findet da wohl jeder so seine eigenen Wege. Ich bin auch im Web-Bereich so ein kleiner Scribble-Fan, sowohl für UIs, als auch für Strukturen, teils auch für Abläufe.

 

[Beni]

Ich kann mich da AlArenal nur anschliessen.

Was ich immer wieder gerne mache ist mir zu Beginn einen Baum von "allem wichtigen" zu zeichnen. Also einen groben Überblick über Features, Daten, Klassen, etc.. die einfach drin sein müssen.

Wie gut diese Ansätze funktionieren hat auch mit Erfahrung zu tun. Jedes Projekt ist besser als das Vorhergehende.

P.S. UML? Ist das was zum essen? :bae:

 

[Kaini]

Drauf los coden endet bei mir auch immer übel

Normalerweise skizziere ich diverse Vorgänge (z.B. bei einem Netzwerk-TicTacToe die Aktionen die ein einkommenes Paket auslöst usw.) aber ULM ist mir zu unfexibel.

Dann kommt wie AlArenal schon sagte ne Todo-Liste, ich hab auch keine Scheue Todo Kommentare Quer im Quellcode zu verteilen.

Jetzt beginnt dann das Coden, erstmal schreibe ich das Model und teste es ausgibig mit einer improvisierten Main-Methode (JUnit hab ich nicht nicht verwedet). Danach schreibe ich die Views (die ich auch mit der Main Methode anzeigen lasse). Und am Schluss kommt dann der Presenter. (MVP-Pattern; ich bevorzuge Passive View - MVC versteh ich bis heute nicht richtig)

 

[musiKk]

Danke fuer die Antworten schonmal.
Meine Probleme lagen bisher halt immer mal darin, dass z. B. Interfaces, die ich am Anfang erstellt habe, sich nach einer Weile als unzureichend, hemmend, umstaendlich, ... herausgestellt haben. Je nach dem wie weit man schon ist, kann dies gehoerige Arbeit mit sich bringen, da noch was zu aendern. Aber ich schaetze mal, da gehoert auch der Erfahrungsaspekt mit rein, dass man das nicht generalisieren kann, ist (leider) klar.

 

[maki]

TDD (Test Driven Design) hilft da wirklich imho, mach das erst seit ein paar Wochen, aber seit dem würde ich nie wieder auf die Idee kommen aus einem Design in UML, welches voller Lücken ist (schliesslich fehlen die Details), einfach so ein Domainmodell zu erstellen, welches sowieso daneben ist.

Dadurch das man gleich von Anfang an Unittests hat, ist Refactoring kein Risiko das man scheut sondern macht richtig Spass. Und "schräge" Schnittstellen sind damit auch nicht mehr in Stein gemeiselt sondern können jederzeit geändert werden.

Man vermeidet damit auch unnötige Methoden (Getter & Setter zB für jedes Attribut), sondern implementiert nur genau das, was man braucht, führt zu viel saubereren Schnittstellen.

Nebenbei kann man Prototypen erstellen, welche weder von der Persistenzlösung noch von der Container Infrastrukltur abhängig sind.
Diesen Prototypen kann man dem Kunden auch zeigen, Textausgaben reichen völlig aus um sicherzustellen das man sich gegenseitig versteht.