PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Wartung von fremdem Code


Eazy
2020-04-03, 13:16:53
Kennt Ihr das Motivationsproblem, wenn man ein ziemlich unbekanntes Programm warten muss und zunächst keine Ahnung hat, wie dieses funktioniert und was es tut?

Habe hier ein ABAP Programm mit ca. 4.000 Zeilen, das irgendwann 1997 geschrieben wurde. Und ich muss jetzt etwas ändern und ein Auswertungsprogramm schreiben, das die Funktionalität des Programms nachahmt.

Und wie man an diesem Beitrag merkt, kann ich mich einfach nicht motivieren mich mit diesem uralten Ding zu beschäftigen...

Kennt Ihr das? Ein neues Programm schreiben macht meistens einigermaßen Spaß, da kann ich mich motivieren. Meine eigenen Sachen zu warten geht meistens auch, da ich vom Prozess weiß was sie tun, und da ich versuche einigermaßen wartungsfreundlich zu programmieren. Aber >4.000 Zeilen alter Code? Kotz!

P.S. Laut Wikipedia schafft ein Programmierer ca. 10 bis 50 Codezeilen am Tag. Was meint Ihr, ist das realisitisch?

Viele Grüße!

EPIC_FAIL
2020-04-03, 19:43:30
Zur Motivationsproblematik kann ich nix sagen, du verdienst doch damit dein Geld, das muss doch als Motivation reichen :freak:

Zum Vorgehen kann ich aber "Refactoring" von Fowler und "Working Effectively With Legacy Code" von Feathers empfehlen.

TL; DR:

Schreib automatisierte Tests, die die wichtigsten Funktionen abdecken. Ohne eine Grundabsicherung kannst du nicht sinnvoll neue Funktionen hinzufügen oder etwas Refactoren. Im besten Fall hast du noch eine Spezifikation zur Software, die beschreibt was das Ding eigentlich tun soll und was für Use-Cases unterstützt werden.

Monger
2020-04-03, 20:12:43
Klar kenn ich das. Und wie jede Prokrastination steckt da üblicherweise die Angst vor Rückschlägen dahinter. Die Angst ist berechtigt. Alles was diese Angst mindert, macht es wahrscheinlicher dass man tatsächlich zu arbeiten anfängt:

1) Quellverwaltung
2) Build Skript
3) Automatische Tests
4) CI Server...

Quellverwaltung ist essentiell, damit man überhaupt eine Zeile ändert. Ein Build Skript nimmt einem all die repetitiven Arbeitsschritte ab die so nerven. Sobald der erste Test existiert, kann man das Build Skript auch um einen Testlauf ergänzen.
Das ist mMn das, was jeder Entwickler braucht, selbst wenn er allein entwickelt. Wenn man im Team arbeitet, macht es schnell Sinn einen Build Agent und Source Server aufzubauen. Und von da aus geht es dann weiter...
Alles Maßnahmen, die verhindern sollen dass alter Code unwartbar wird.

Marscel
2020-04-05, 16:37:17
Kennt Ihr das? Ein neues Programm schreiben macht meistens einigermaßen Spaß, da kann ich mich motivieren. [...] Aber >4.000 Zeilen alter Code? Kotz!

Wenn man nicht unter NIH leidet, dann ist das mEn eher üblich, dass man sich durch Tausende Zeilen Code hangelt, der fremd und teilweise recht alt ist. Workflows, Klassen, Variablennamen auf ein Blatt Papier und los gehts.

kA, was du sonst tust, aber da ich sowas als Standardfall in der SE sehe, muss man seine Einstellung ändern. Sieh es als Stück Reverse Engineering, das es zu knacken gilt, als Archäologie-Expedition nach dem Stein der Weisen, als terminalen, alten Patienten, den man am Leben erhalten will. Such dir was aus.

Gliese
2020-04-05, 18:34:57
Ich kenne das Problem auch.
Am schlimmsten finde ich, wenn dann auch noch mit der Abstraktion übertrieben wurde und etwas funktioniert nicht mehr und muss schnellstens repariert werden.

Hatte ich letztens, es war ein uralt-PHP-MVC, es gab bloß 2 Routen für Bilder und Dokumente, alles andere lief in eine Default-Route rein, und wer da sich traute, reinzuschauen, war im Klassen-Labyrinth gefangen. Doku und Tests gabs auch keine.
Überall waren Klassen, die nichts anderes machten als die Sache weiter zu delegieren. Und überall waren nichtssagende Variablen wie $helper, $manager und $handler und es war überhaupt nicht ersichtlich, was für ein Typ die Variablen hatten und wo für das ganze.
Durch Trial und Error hat es sich rausgestellt, dass alles supersuperdynamisch in Komponenten abgebildet war und viel von der Seiten-Logik aus der Datenbank kam, selbst PHP-Code war in der Datenbank zu sehen, was natürlich nicht in der Versionsverwaltung abgebildet war (und eh nicht gepflegt war).
Um das ganze Rund zu machen: die Testinstanz wurde so schlecht gepflegt, dass sie gar nicht funktionierte und man direkt auf Produktion debuggen musste.

Ihr glaubt nicht, wie oft ich auf Klo oder in der Küche war, weil der Kopf sowas von geraucht hat. Solche Arbeiten sind so mies, ich kenne das.

Noch schlimmer, aber länger her war ein vom Wasserkopf abgesegnetes Major-Update eines Shops, welches tief in ein Online-Spiel integriert wurde und daher bis in die hinterste Ecke "customized" war. Das Zusammenspiel der SAP, Ingame-Währung, Anbindung am Bezahldienstleister, evtl. Versand und die daraus resultierenden speziellen MwSt-Reglungen wurde sehr "spannend" gelöst, denn es gab zig Sonderreglungen, wie was ins System gebucht werden muss. Wir waren zu mehreren Leuten und alle haben geflucht.

So ist es nun mal, fast jeder Beruf hat seine Schattenseiten. Es kommen sicher immer wieder auch mal bessere Projekte ins Haus (sonst sollte man wechseln ... ok jetzt nicht, aber wenn Corona vorbei ist).

Demirug
2020-04-05, 18:37:56
Wenn man nicht unter NIH leidet, dann ist das mEn eher üblich, dass man sich durch Tausende Zeilen Code hangelt, der fremd und teilweise recht alt ist. Workflows, Klassen, Variablennamen auf ein Blatt Papier und los gehts.

kA, was du sonst tust, aber da ich sowas als Standardfall in der SE sehe, muss man seine Einstellung ändern. Sieh es als Stück Reverse Engineering, das es zu knacken gilt, als Archäologie-Expedition nach dem Stein der Weisen, als terminalen, alten Patienten, den man am Leben erhalten will. Such dir was aus.

Ja, den Luxus etwas völlig neues auf der "grünen Wiese" zu bauen hat man eher selten.

Persönliche wühle ich mich ja gerne durch fremden Code weil man dort immer wieder interessante Sachen entdecken kann. Probnlematisch wird es nur an dem Punkt wenn man erkennt das die Software eigentlich völlig unbrauchbar für die Aufgabe ist und es besser wäre wirklich etwas neues zu machen man es aber aus verschiedenen Gründen nicht machen kann.

Ich bin da aber vielleicht auch eine Ausnahme. Ich vermute mal nicht sehr viele würden als Freizeit Projekt ein altes Apple II Spiel von 1985 das in Basic und 6502 Assembler geschrieben wurde nach C und 6808 Assembler portieren.

Monger
2020-04-06, 23:58:55
Ich bin da aber vielleicht auch eine Ausnahme. Ich vermute mal nicht sehr viele würden als Freizeit Projekt ein altes Apple II Spiel von 1985 das in Basic und 6502 Assembler geschrieben wurde nach C und 6808 Assembler portieren.
Wobei ich finde, Spieleportierungen klingen zumindest noch nach Spaß. Du hast ein fest definiertes Ziel, eine relativ klare Vorstellung wie es am Ende aussehen soll, und lauffähigen Code, der sich nicht mehr ändert. Es ist wie ein Puzzle. Das ist quasi noch die schönste Art von Legacy Code.

Aber wir kennen wahrscheinlich alle diese gruseligen Monster, die man lieber erschießen als heilen möchte. Wo man in diesem tiefen, tiefen Tal steckt was mit vielen Mannjahren gegraben wurde, und man jetzt alleine unter Zeitdruck wieder zuschütten soll.

Rabiata
2020-04-11, 19:25:44
Ja, den Luxus etwas völlig neues auf der "grünen Wiese" zu bauen hat man eher selten.

Persönliche wühle ich mich ja gerne durch fremden Code weil man dort immer wieder interessante Sachen entdecken kann. Probnlematisch wird es nur an dem Punkt wenn man erkennt das die Software eigentlich völlig unbrauchbar für die Aufgabe ist und es besser wäre wirklich etwas neues zu machen man es aber aus verschiedenen Gründen nicht machen kann.

Ich bin da aber vielleicht auch eine Ausnahme. Ich vermute mal nicht sehr viele würden als Freizeit Projekt ein altes Apple II Spiel von 1985 das in Basic und 6502 Assembler geschrieben wurde nach C und 6808 Assembler portieren.
Code-Archäologie mag ich grundsätzlich auch. Das Problem ist eher daß es meist "gestern schon" fertig sein soll. Nun braucht es meiner Erfahrung nach etwa 1/3 der Zeit die der Erstentwickler reingesteckt hat, um ein System umfassend zu verstehen. Speziell bei Spaghetticode.

Jetzt übernimm mal die Wartung einer umfangreichen Software, die über 10-20 Jahre "historisch gewachsen" ist. Drei Jahre oder mehr bekommst Du üblicherweise nicht zur Einarbeitung. Bestenfalls endet es damit, daß du ein Teilsystem identifizieren kannst in dem du dein Problem mehr oder weniger isoliert bearbeiten kannst.
Wenn es dumm läuft mußt du improvisieren und verschlimmerst die technischen Schulden.
Schlimmstenfalls wird das Projekt irgendwann vom Management abgebrochen, weil es nicht voran geht und die Leute die Geduld verlieren.

Was die 10-50 Codezeilen pro Tag angeht, hängt dies sehr vom Problem ab.
Anspruchsvolle Mathematik umsetzen? Da können 10 Zeilen/Tag schon gut sein.
Banale Geschäftsregeln runter programmieren? Da habe ich schon 200 Zeilen/Tag geschafft. Die Regeln waren leider nicht ganz so konsistent daß eine stärkere Abstraktion Sinn ergeben hätte, also war viel Tipparbeit angesagt.

Hasenpfote
2020-07-06, 21:30:12
Also ich bevorzuge bestehende Code* zu ändern, als auf der grünen Wiese neu anzufangen. Einfach weil ich es mag, konkrete Probleme zu lösen, statt abstrakt zu überlegen, wie man was bauen könnte, damit es auch erweiterbar und wartbar bleibt. Das ist mir oftmals einfach eine zu diffuse Wolke.

*kein PHP oder Visual Basic oder Shell Skripte :D

Persönliche wühle ich mich ja gerne durch fremden Code weil man dort immer wieder interessante Sachen entdecken kann.Schön sind folgende Momente:
"Was ist das denn für'n Müll, das geht doch viel besser. Was für ein Idiot! Ich mach mal fix"
drei Stunden später
"Joah, meine Lösung sieht quasi genauso aus, wie das was da ist.... Hab einfach Problem A, Randbedingung B und Einschränkung C nicht bedacht" :freak:
Das setzt das eigene Ego doch immer wieder an die richtige Position ;D

TheRaven666
2020-07-08, 18:37:20
Offtopic: Danke für den Thread. Ich bin nicht allein.

PatkIllA
2020-07-08, 18:44:44
Top finde ich ja, wenn man was warten soll, man erstmal die ganzen Compilerfehler behebt und sich dann der Autor beschwert, dass man soviel geändert hat.

Demirug
2020-07-09, 14:47:04
Top finde ich ja, wenn man was warten soll, man erstmal die ganzen Compilerfehler behebt und sich dann der Autor beschwert, dass man soviel geändert hat.

Kein continuous integration system oder war es deine Aufgabe auf einen neue/anderen Compiler umzustellen?

PatkIllA
2020-07-09, 16:00:54
Kein continuous integration system oder war es deine Aufgabe auf einen neue/anderen Compiler umzustellen?
CI schon aber Testabdeckung lässt zu wünschen übrig.

Aufgabe war eher Bugfixing oder Komponenten an neue Schnittstellen anpassen.
Da gibt es dann einerseits Dinge wie unbenutzte private Member Parameter, unnütze Zuweisungen usw.

Und dann gibt es in C# mittlerweile einige Dinge die Code wesentlich schlanker/besser lesbar machen, die es früher noch nicht gab. Die kann man automatisch mit einem Klick bei sehr geringem Risiko beheben.

Grendizer
2020-07-09, 16:11:40
Naja ... der Vorteil von ABAP ist doch aber, das er beständig ist. Klar ist es von 1997 kein ABAP Objects, aber kennt man noch die funktionale Ausprägung von ABAP ist das doch kein grosses Thema. Am Datenmodell der Anwendung (ERP?) hat sich ja vermutlich auch nie so viel geändert, sonst würde das Ding ja nicht mehr funktionieren.

Im ABAP Umfeld ist es doch aber relativ normal, das man uralten Code bekommt und dann daran rumbasteln darf :biggrin:

Habe deshalb auch die Programmierung schnell sein gelassen und habe mich auf die SAP Basis gestürtzt. Ist auch nicht wirklich schlechter bezahlt und man hat mehr "Ruhe".