Best Practice Wie geht man mit "schlechten" Projekten um?

[HolyFUT]

Hallo zusammen,
diese Frage bezieht sich auf Hobby-Projekte, also nichts arbeitsrelevantes.

Ich wollte euch mal fragen wie ihr mit schlecht entworfenen und schlecht entwickelten Projekten umgeht. Um Java zu lernen habe ich mich an ein Projekt rangemacht und habe versucht mein bisheriges Wissen aus anderen Programmiersprachen in Java anzuwenden. Dabei ist mir im laufe der Zeit, bzw. konkret in den letzten Tagen, aufgefallen dass die Struktur des Projekts sehr zu wünschen übrig lässt, was unter anderem zur Folge hat dass manche Sachen unter gewissen Umständen nicht funktionieren werden. Um teilweise Folgefehler in meinem Projekt zu vermeiden, habe ich teilweise den Eindruck dass ich manche Stellen komplett aufbohren muss.

Zugegeben: Die Planungsphase des Projekts fiel sehr klein aus, wodurch natürlich die Struktur eher mehr nach Freischnauze aufgebaut wurde.

Wie geht ihr damit um, sollten es sich um mehrerer dieser Stellen handeln? Würdet ihr euch die Zeit nehmen die Stellen zu bereinigen oder würdet ihr das Projekt mit der neuen Erfahrung refactoren?

 

[Blender3D]

Hallo zusammen,
diese Frage bezieht sich auf Hobby-Projekte, also nichts arbeitsrelevantes.

Ich wollte euch mal fragen wie ihr mit schlecht entworfenen und schlecht entwickelten Projekten umgeht. Um Java zu lernen habe ich mich an ein Projekt rangemacht und habe versucht mein bisheriges Wissen aus anderen Programmiersprachen in Java anzuwenden. Dabei ist mir im laufe der Zeit, bzw. konkret in den letzten Tagen, aufgefallen dass die Struktur des Projekts sehr zu wünschen übrig lässt, was unter anderem zur Folge hat dass manche Sachen unter gewissen Umständen nicht funktionieren werden. Um teilweise Folgefehler in meinem Projekt zu vermeiden, habe ich teilweise den Eindruck dass ich manche Stellen komplett aufbohren muss.

Da es sich um ein Hobbyprojekt handelt. Das selbe Projekt mit den neuen Erkenntnissen einfach noch einmal neu machen.

 

[wicki_]

jupp.

Da es sich um ein Hobbyprojekt handelt. Das selbe Projekt mit den neuen Erkenntnissen einfach noch einmal neu machen.

jupp.
auch gewerbliche projekte wirft man irgendwann weg und machts neu.
spätestens dann, wenn man keine fortran-entwickler mehr am markt findet....

bei der neuentwicklung kann man alte fehler vermeiden und neue einbauen. ;-)

 

[Robert Zenz]

Da es sich um ein Hobbyprojekt handelt. Das selbe Projekt mit den neuen Erkenntnissen einfach noch einmal neu machen.

Man muss es nicht direkt wegwerfen und neu machen, man kann es ja auch umbauen bis man damit zufrieden. Das ist gleichzeitig auch eine gute Uebung in Umbauarbeiten und idealerweise wie man Tests schreibt um sicherzugehen dass die Funktionalitaet noch ident ist nach dem Umbau.

auch gewerbliche projekte wirft man irgendwann weg und machts neu.
spätestens dann, wenn man keine fortran-entwickler mehr am markt findet....

Das ist in vielen Faellen auch nicht richtig. Wenn du Projekte hast mit Vielleicht 500 Personenjahren die sich im Laufe von 30 Jahren angesammelt haben, hast du kaum eine Chance das in endlicher Zeit abzuloesen. Da spielt dann auch der Mangel an Programmierer die die Sprache sprechen keine Rolle, du hast keine Wahl und nimmst jeden der es tippen kann (egal was der fuer Gehaltsvorstellungen hat). Es gibt nicht mehr viele COBOL Programmierer, aber die die es gibt, koennen sich ihr Gehalt frei aussuchen weil die Firmen einfach keine Wahl mehr haben.

Das ist jetzt ein Extrembeispiel, aber selbst wenn du ein PHP-Projekt hast, auf dem du 50 Personenjahre ueber die letzten 10 Jahre angesammelt hast, wirst du dir sehr schwer tun das abzuloesen. Da musst du dann schon mit einem echt guten Konzept um die Ecke kommen, und auch das richtige Framework haben, damit du solche Dinge noch in endlicher Zeit abgeloest bekommst. Und dann hast du immer noch das Problem dass alte Bugs zwar weg sind, du aber neue eingebaut haben wirst.

Abloesen von Projekten im gewerblichen Umfeld ist ein sehr, sehr schwieriges Thema wenn es nicht gerade um eine POS- oder ERP-Loesung geht die es bereits zuhauf gibt.

Wie geht ihr damit um, sollten es sich um mehrerer dieser Stellen handeln? Würdet ihr euch die Zeit nehmen die Stellen zu bereinigen oder würdet ihr das Projekt mit der neuen Erfahrung refactoren?

Einfach umbauen. Es ist dein Projekt, selbst wenn du das Projekt auf GitHub oder GitLab hast, glaube ich nicht dass es jemand zweiten gibt wer im Quellcode arbeitet, damit hast du freie Hand. Bau es um, lern dabei, und bau es dann wieder um. Immer und immer wieder. Wenn du wirklich an Grenzen stoeszt wo du sagen musst "Das kann ich so nicht mehr umbauen", dann ein neues Projekt beginnen. Aber das glaube ich gar nicht mal dass es wirklich solche Grenzen in kleineren bis mittleren Projekten gibt.

Zugegeben: Die Planungsphase des Projekts fiel sehr klein aus, wodurch natürlich die Struktur eher mehr nach Freischnauze aufgebaut wurde.

Es gibt auch Momente wo du etwas planst, es dann umsetzt und dann erst bemerkst das es dabei Probleme gibt und du komplett umdisponieren musst. Das kann auch passieren, also selbst eine laengere Planungsphase kann dich vor solchen Dingen nicht bewahren. Nicht zuletzt muss man auch bedenken kann das es selten Projekte gibt die einen solchen Umfang haben dass sie nach ein paar Wochen Tipparbeit "fertig" sind. Es gibt immer noch eine Funktion die man einbauen will, eine Funktion die so nicht sein sollte, ein Fehler der noch weg muss. Klar ist planen wichtig, aber es hilft dir bei einigen Dingen einfach nicht in die du laufen kannst und wirst.

Du kannst 20 Software-Architekten in einen Raum sperren fuer ein Jahr und die sollen dir eine ERP-Loesung komplett durchplanen, ich kann dir versprechen dass du sie innerhalb von zwei Monaten nach Beginn der Tipparbeit wieder in den Raum sperren musst weil sie umplanen muessen.

 

[KonradN]

Es gibt auch Momente wo du etwas planst, es dann umsetzt und dann erst bemerkst das es dabei Probleme gibt und du komplett umdisponieren musst. Das kann auch passieren, also selbst eine laengere Planungsphase kann dich vor solchen Dingen nicht bewahren. Nicht zuletzt muss man auch bedenken kann das es selten Projekte gibt die einen solchen Umfang haben dass sie nach ein paar Wochen Tipparbeit "fertig" sind. Es gibt immer noch eine Funktion die man einbauen will, eine Funktion die so nicht sein sollte, ein Fehler der noch weg muss. Klar ist planen wichtig, aber es hilft dir bei einigen Dingen einfach nicht in die du laufen kannst und wirst.

Das ist dann auch, was mir so gut an der agile Arbeitsweise gefällt. Es werden halt immer nur Iterationen geplant und vor jeder wird halt geplant. Und die Planung kann von der bisherigen Planung abweichen.

Das ersetzt nicht die Architektur, die geplant sein sollte oder die Vision, wohin es gehen soll (oder evtl. besser: gehen könnte).

 

[White_Fox]

Ich würde mir erstmal Gedanken machen, was ich am Ende haben will.
Wenn es ein Hobbyprojekt ist, ist möglicherweise der Weg selbst ein Teilziel. Hat das Projekt einen konkreten Nutzen, d.h. will ich schnell wieder was Lauffähiges haben? Was genau würde ich heute anders machen wollen?

Ein Projekt neu zu schreiben ist keine Schande und nicht schlimm, wenn es kein Geld kostet. Aber sich vorher einen Plan machen, gerne auch schriftlich, das ist auch im Hobbybereich nie verkehrt.

 

[HolyFUT]

Hallo zusammen,
ich danke euch für eure Beiträge zu diesen Thema.

Ich habe mich nun nach Überlegung, und natürlich während ich an der Application geschrieben habe, mich dazu entschieden das Projekt weiterzuentwickeln. Es gibt noch einiges zu lernen und ich will die Erfahrung nicht missen wenn ich an Stellen ankomme die ich vermutlich erst viel später gemacht habe, hätte ich das Projekt jetzt verworfen und neu angefangen. Gestern war dies auch der Fall, da war ich an einer Stelle dran an der ich etwas umdenken musste und da habe ich, trotz der bescheidenen Struktur, etwas neues gelernt.

 

[HolyFUT]

Hallo zusammen,
ich danke euch für eure Beiträge zu diesen Thema.

Ich habe mich nun nach Überlegung, und natürlich während ich an der Application geschrieben habe, mich dazu entschieden das Projekt weiterzuentwickeln. Es gibt noch einiges zu lernen und ich will die Erfahrung nicht missen wenn ich an Stellen ankomme die ich vermutlich erst viel später gemacht habe, hätte ich das Projekt jetzt verworfen und neu angefangen. Gestern war dies auch der Fall, da war ich an einer Stelle dran an der ich etwas umdenken musste und da habe ich, trotz der bescheidenen Struktur, etwas neues gelernt.

Mittlerweile habe ich meine Struktur aufgebohrt und nachgebessert, ich bin froh dass ich am Ball geblieben bin. Gibt immer wieder was neues zu lernen.