Wartung von fremdem Code

[Eazy]

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]

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]

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]

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]

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]

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]

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]

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]

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]

Offtopic: Danke für den Thread. Ich bin nicht allein.

[PatkIllA]

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]

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]

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]

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".

[medi]

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.

Bei mir ist es eher immer der "Was zur Hölle hat der sich dabei gedacht!?" Moment, der mich dann dazu veranlasst den Code umzustellen. Einfach weil es die Wartbarkeit und Effizienz erhöht.
Allerdings habe ich gerade mit nem Kunden zu tun, der sich als von Gott erwählter Programmierer sieht - auch wenn er null Durchblick hat (hat es weder gelernt noch studiert und ist eher der Typ Bastler). Da hab ich es aufgegeben seinen Code zu überarbeiten und zu verbessern weil er komplett beratungsressistent ist und das Teil rückgängig macht aber in jedem Fall seinen Stil weiter so durchzieht. Hab mir beim aktuellen Projekt sein ok gegeben, dass ich mich an seinem Stil orientiere und das so umsetze. Der Code ist dadurch müllig und schlecht wartbar aber scheiss egal - er will es ja so und ich werde nach Stunden bezahlt :freak:

[PatkIllA]

Mir würden es ja schon reichen meine eigenen Warnungen zu sehen und vorher zu beheben, wenn der Compiler mich schon drauf hinweist. Jedesmal neu filtern oder manuell durchzugehen ist da auch keine Option.
In der Mehrheit lassen die sich sogar automatisch per Knopfdruck behoben.

[BigKid]

Also ehrlich gesagt. Das einzige was ich noch ungerner mache als Fremdcode zu übernehmen (am besten noch wenn jemand plötzlich die Firma verlässt und man dann eben mal schnell neben der Arbeit her noch nen KT machen soll für Dinge wo man schon fachlich nur Bahnhof versteht) - ist - TADA - Dokumentieren ;)

[Gohan]

Ich habe aktuell den Spaß, Aufpasser für ein Projekt zu sein, das nach Indien ausgelagert wurde. Das ist ein Spaß. Ein paar helle Lichter sind dabei, aber teilweise auch echte Ausreißer nach unten. Da fragt man sich echt, was die in der Softwareentwicklung verloren haben.

Da wird in der DEV Umgebung ein select count(*) auf eine Tabelle gemacht, das Ergebnis in einer Konstanten im Code persistiert (als wirklich die Zahl hardocoded in Quelltext eingetragen) und basierend darauf dann weiter gearbeitet mit Vergleichen der Mengen auf der selben Tabelle und das ganze mir dann zum Code Review übergeben. Da fehlen mir echt die Worte, was ich dazu schreiben soll.

Ich weiß noch nicht mal wofür dieser Code gut seien soll, da er keine gestellte Anforderung löst :freak:

[BigKid]

Ich habe aktuell den Spaß, Aufpasser für ein Projekt zu sein, das nach Indien ausgelagert wurde. Das ist ein Spaß. Ein paar helle Lichter sind dabei, aber teilweise auch echte Ausreißer nach unten. Da fragt man sich echt, was die in der Softwareentwicklung verloren haben.

Da wird in der DEV Umgebung ein select count(*) auf eine Tabelle gemacht, das Ergebnis in einer Konstanten im Code persistiert (als wirklich die Zahl hardocoded in Quelltext eingetragen) und basierend darauf dann weiter gearbeitet mit Vergleichen der Mengen auf der selben Tabelle und das ganze mir dann zum Code Review übergeben. Da fehlen mir echt die Worte, was ich dazu schreiben soll.

Ich weiß noch nicht mal wofür dieser Code gut seien soll, da er keine gestellte Anforderung löst :freak:
Die Zusammenarbeit mit Indern ist nicht nur eine sprachliche Herausforderung ;) .
Ich hatte in einem Projekt in Australien mal die Gelegenheit mit einer eingebürgerten Inderin zu sprechen und die hat mir bestätigt, dass es für sie ein echter Kampf war sich an die westliche Mentalität anzupassen. Sie kriegen die Obrigkeitshörigkeit in die Wiege gelegt. Sie machen GENAU was ihnen gesagt wurde und WIE es ihnen gesagt wurde. Die besten Arbeiten dann wenn möglich "um die Fehlspecc herum" - die anderen machen die Augen zu und machen es so falsch wie spezifiziert (oder verstanden). Den Forgesetzten zu korrigieren - egal wie - käme ihnen nicht in den Sinn... (Ihre Aussage - ich hielt das bis dahin zumindest Teilweise für ein Klischee).
Eigentlich sollte jeder einen Kurs über die Interkulturellen Probleme bekommen wenn er mit outgesourcten Kräften in einem anderen Land arbeitet...
Da gibts schon Probleme zwischen Deutschen und Schweizern ...

[Monger]

Die kriegen die Obrigkeitshörig in die Wiege gelegt. Die machen GENAU was ihnen gesagt wurde und WIE es ihnen gesagt wurde.
Das hat teils mit ihrem Tarifsystem zu tun.
Ich hab jetzt ungefähr 15 Jahre Berührung mit Offshoring in Indien. Mir ist ehrlich gesagt immer noch unklar wie genau die Verträge laufen, aber Indien versteht sich halt selber immer noch sehr stark als Dienstleister, und ihr Gehalt ist teils sehr penibel an das Erfüllen von irgendwelchen Metriken gekoppelt. Wie viele Tasks wurden abgearbeitet? Mit wieviel Verspätung?
Wir haben vor ca. 5 Jahren angefangen bestimmte Themen nicht nur outzusourcen, sondern komplett an Indien abzugeben, von der Planung bis zur Umsetzung. Seitdem läuft es zunehmend besser.

Ähnliches haben wir auch schon mit Outsourcing direkt vor Ort erfahren. Anscheinend fällt die Codequalität gerne hinten runter, wenn einem der Endkunde nicht persönlich in den Arsch tritt.
Haben jetzt uns darauf geeinigt, dass wir Outsourcing für Proof of Concept und ähnliches machen. Alles was "weiche Kriterien" erfordert, machen wir selbst.

[Matrix316]

Ich kenn mich nicht mit ABAP aus, aber unsere größte Webanwendung mit ASP NET hat keine Ahnung so 200 Codebehind cs c# Seiten mit so 100~4000 oder vlt auch mehr Zeilen pro Datei - und das habe ich nicht alles alleine geschrieben. ;)

Einfach durchkämpfen. :D

[Geldmann3]

Zum Threadstart:

4000 Zeilen Code? Ich warte auf der Arbeit Applikationen mit eher 5000 Klassen und 10.000 Files an Code, den ich nicht kenne. :D

Kommt natürlich immer auch darauf an, wie sehr sich der Code an die heutigen Best-Practices hält und verwaltet ist.

Meiner Erfahrung nach kann ein Entwickler am Tag irgendwas zwischen 0 und 500 Zeilen Code schreiben, je nach der aktuellen Aufgabe.^^ Qualitätscode braucht allerdings viel Zeit und mehr als zwei Augen.

1997 waren noch andere Zeiten, da hätte ich bestimmt auch keinen Bock drauf.

[dw86]

Versuch Kontakt mit dem alten Programmierer herzustellen vielleicht kann er dir in kurzen Sätzen sagen was es tun. Ich hoffe der Programmierer hat auch ausreichend Information von ihm preisgegeben. ;)