Wie geht man am besten ein Projekt an das einfach "zu groß" ist?
Ich programmiere beruflich eine Software. Viele "meiner" neuen Module usw. kamen auch wundervoll an und funktionieren super.
Nun bekam ich den Auftrag quasi auch ältere Module komplett zu überarbeiten und zu modernisieren.
Nur sind das teilweise riesen Klötze an code der vollkommen durcheinander und ohne Sinn und verstand entstanden ist. Vorallem auch da damals eben ein reger Mitarbeiter wechsel war. Man sieht sehr schnell das jegliche Struktur etc. fehlt, da wurde mehr oder weniger nur drauf los programmiert und eben immer von verschiedenen Leuten.
Nunja. Wie gehe ich so eine umstellung am besten an?
Bin wirklich Zwiegespalten ob ich alles "umbaue" ODER eben einfach das ganze nochmal neu programmiere.
Wird vermutlich so oder so einiges an Zeit in anspruch nehmen.
Mit "zu groß" meine ich einfach die Masse an code der da umzustellen ist. Vorallem da es teils sehr verschachtelt ist.
5 Antworten
Ja, sowas ist schwierig.
Du musst dich entscheiden: Refactoring oder Neuentwicklung?
Und Du musst die Erwartungshaltung aller Stakeholder auf ein realistisches Niveau senken. Die Modernisierung/Neuentwicklung wird mehr Fehler haben und schlechter laufen, das ist normal und gehört dazu, aber das müssen die Stakeholder auch verstehen.
Und danach steht und fällt alles mit den Anforderungen, dass heißt, Du musst genau ausarbeiten, was die Module so können (müssen), ggf. auch mit Hilfe einiger Anwender.
Danach hilft es dir ggf., die alte Version unverfänglich zu überarbeiten, also Code formatieren, in Klassen aufteilen, etc., damit Du einen besseren Überblick bekommst, egal ob Neuentwicklung oder Refactoring.
Kannst Du auf der grünen Wiese anfangen und brauchst die alte Version nicht pflegen? Dann ist die Neuentwicklung vermutlich die bessere Wahl.
Wenn Du zwischendurch noch Pflegen und Updates liefern musst, ist das mit einem Refactoring besser möglich, das ist allerdings auch deutlich aufwändiger. Dafür geht beim Refactoring aber nicht so schnell etwas unter, dir fällt ja auf, wenn Du ein Stück Code nicht in deine neue Sturktur überführen kannst.
Bei einer Neuentwicklung und wenn das Modul zu groß für dich ist, dann fang mit den wichtigsten Funktionen an und rüste danach erst weitere Funktionen nach. Plane nicht alles auf einmal ein, so scheitern größere Projekte häufiger. Wichtig ist dabei aber, dass Du die Architektur immer aktualisierst. Du kannst natürlich auch alles von vorne bis hinten durch planen, aber dann musst Du eben auch sehr sorgfältig planen, was alles andere als einfach ist.
Bei einem Refactoring solltest Du dir vorher automatisierte Tests aufbauen, die sagen dir, wenn Du was kaputt gemacht hast. Und dann überlegst Du dir, welches Detail Du als erstes umbaust, also das, was bei dem Rest am meisten aufhält. Wenn ich z.B. eine alte ASP.NET Anwendung habe, wäre mein erster Versuch, alles, was abstrahiert werden kann, in neue Projekte zu bringen, danach kann ich dann die ASP.NET Anwendung selber (idealerweise ohne viel Logik) mit dem neuen ASP.NET Core komplett neu aufsetzen und dann die ausgelagerten Inhalte nutzen.
PS:
Wenn das Modul das Geld wert ist, holt euch doch einen Berater dazu? Berater können natürlich auch ein Griff ins Klo sein, sie haben aber häufig auch sehr viele Projekte und auch Refactorings gesehen und begleitet.
Wilkommen in der Welt des legacy code. Ich arbeite auch für einen Namenhaften Automobilhersteller und stolpere teilweise über Code der so heute nie durchgewunken werden würde. Mein Tipp ist es zu modernisieren statt neu zu schreiben. Die alte Logik in Takt halten, jedoch neue Methoden und Techniken anwenden um schlechten Code zu verbessern.
Ich hab selber immer bei der großen Hauptmethode angefangen und die überarbeitet, dann Schritt für Schritt debugged um Fehler zu finden und mich dann an die Funktionen gemacht. Das hat den Vorteil dass du einen großen Brocken des Codes schon kennst und weißt was diese von ihren Unterfunktionen erwartet. Sei nur vorsichtig. Bei uns war es so dass Optimierungen teilweise dazu geführt haben dass das Programm abstürzt. Eine Methode bspw. wurde in ihrer Ausführung so flott dass der Rest des Programmes nicht hinterher kam.
ja, genau sowas ist teilweise auch mein bedenken.
Bei manchen Stellen im code dachte ich mir schon "hm, das klappt doch nur weil es so langsam ist aktuell"
Aber danke für den Tipp, ist ja neuland für mich mit dem überarbeiten von extrem altem code.
Ich denke ich schnapp mir erstmal eins der "kleineren" module und mache eine Art "Testlauf" des umschreibens.
Damit ich ein Gefühl dafür bekomme wie ich das in zukunft am besten angehe, vorallem bevor ich mich dem RIESEN Brocken stelle. Da will ich an liebsten garnicht ran um ehrlich zu sein :D
Ich bin zwar keine Programmiererin, aber man hat ja auch ähnliche Situationen, wenn man zum Beispiel überlegt, ob man alte Texte überarbeiten oder lieber gleich neu schreiben will.
Ich würde es so machen: Knöpf dir doch mal so ein Modul vor und schau, ob du es korrigieren kannst. Wenn es sich als zu verworren erweist, kannst du es immer noch komplett neu schreiben.
Und dann kannst du doch bei jedem Modul neu entscheiden, ob du überarbeitest oder neu schreibst. 💁♀️
Und dann deinem Arbeitgeber auf jeden Fall eine klare Ansage machen, was deine Schätzung ist, wie lange das dauert (und vielleicht lieber grosszügig schätzen)!
Manche AGs sind allerdings auch Idioten und würgen womöglich ein notwendiges Projekt ab, weil sie finden, es dauere zu lang.
Dann ist man gezwungen, über die Dauer zu lügen, damit das Projekt überhaupt bewilligt wird...
Und dann läuft es halt dann so, dass man die Deadline ständig hinausschieben muss, weil es von Anfang an klar war, dass es nicht so schnell geht...
So kriegt jeder Chef die Arbeit, die er verdient. ;)
Tja so läuft das leider in der Industrie, besonders dann wenn Leute die keine Ahnung vom programmieren haben über besagte deadlines entscheiden.
Ich bin zwar selber nicht in der IT, aber ich habe Informatiker oft genug über diese Umstände klagen hören. 🙄
Vielleicht wäre es hilfreich, Informatiker könnten detailiertere Pläne aufstellen, welche auflisten, welche Teilprojekte wie lange dauern dürften. Grosse IT-Firmen machen das natürlich, aber vielleicht würde es auch helfen in einer kleineren Firma.
Weil, ich glaube, viele Entscheide zur IT werden irgendwie so "zwischen Tür und Angel" gefällt. Der Chef sagt beim Kaffeeautomaten: "Du, könntest du mal das und das korrigieren, das zickt immer rum!" und der IT-Mensch sagt: "Ja, Chef mache ich" und denkt dazu: Phu, das wird ein Monster, damit bin ich mindestens 3 Wochen komplett ausgelastete und brauche noch 3 Monate für die Nachkontrolle und Nachkorrektur!
Dem Chef sagt er aber nichts davon, und der denkt, der IT-Mensch macht das bis Ende Woche. Und am Freitag kommt er und sagt: "Warum zickt das immer noch?!". Und der IT-Mensch: "Ich hab erst gerade angefangen mit der Fehleranalyse!!". 🙄😏😅
Stimmt das so (dem Sinn nach natürlich - habs extra überspitzt dargestellt!)?
Danke, JokesOnYou sagte es ja schon. Guter Tipp, werde ich beachten.
Ich bin zwar nicht so tief in der Programmierszene drin, habe aber schon mal an der Oberfläche gekratzt. Demnach habe ich schon ein paar einfachere verschachtelte Funktion programmiert.
verglichen mit anderen Dingen würde ich dir raten, den Code neu zu programmieren, da es meiner Meinung nach viel zu lange dauert, sich da rein zu denken und das Ganze im alten Code neu hin und her zu schieben. Denk dich in den alten Code rein benutze ihn als Referenz und Programmier das Modul neu.
Gut möglich das dass der beste Weg wäre.
Will nur nicht zu beginn schon das ganze "falsch" angehen. Ich warte mal noch ein paar Antworten ab.
Kleinere Verschachtelungen wären ja kein Problem.
Das sind teils zig tausende Zeilen code. Wobei ich auch da bezweifel das es bei dem ein oder anderen Modul überhaupt soviel code benötigt.
Einfach ein riesen Chaos.^^
Danke dennoch, werd noch etwas drüber nachdenken.
Mach es neu! Dann hast du schlanke Dateien und siehst durch! In einem Gefriggel von Code liegt kein Vorteil!
Das mit dem großzügig schätzen ist ein toller Ratschlag! Lieber zu viel Zeit einkalkulieren und dann alle positiv überraschen statt Deadlines zu verpassen.