Verwaister und undokumentierter Bestandscode - was tun?

**4dk2**

zum einen, will das jetzt nicht auf dich beziehen, aber was ich damals 2 Jahre nach Ausbildung also Optimalen Code empfunden habe, hat sich zum Stand heute auch noch stark verändert

Dann zu legacy Code.
Hab schon so manche Adaptierungen von früheren Kollegen gesehen die so aussahen:

markieren

Delphi-Quellcode:

			...

begin

  ...

  //Ab hier startet das Chaos, viel Spass beim debuggen ;)

  FormX.Start();

  ....

end;

**mensch72**

..."Das Problem ist, dass es ein daily business gibt und wie erwähnt, nur meine Ressource.
Es geht mehr um die Entscheidung was sinnvoller/schneller/wirtschaftlicher ist. Eine Neuentwicklung beginnen oder die bestehenden Struckturen anpassen."...

Solange altes aktuell "noch richtig" funktioniert, ist es wirtschaftlich sinnvoll das zunächst weiter zu nutzen und zu verkaufen, denn davon lebt ihr.
Wenn ihr im altem echte BreakingErrors habt, und die nicht in Zeit X im Altsource gefunden&behoben werden, dann muss da intern oder extern ein Ersatz her.
Wenn man nich alles selbst neu machen kann, baut man Schnittstellen zu anderen fast imer irgendwie findbaren Zukaufmodulen, welche man im Hintergrund als Ersatz einbindet.

..."neue Funktionen in den Bestandscode bringen. Aber genau das möchte ich ja nicht. Ich möchte ja nicht unsauber weiterarbeiten und alles noch schlimmer machen, sondern etwas verbessern."...
- wenn eure Kunden und dein Chef dich fürs "will verbessern" bezahlt, dann ist das toll... Die meisten Kunden und Chefs verlangen und zahlen aber nach realisierter Funktionalität, und das in Zeit X.
Ich würde oft auch gerne alles aus einem Guß mit einheitlicher CodeStruktur haben, aber die Zeit gibt es zumeist nicht her. Mein einziger Vorteil mit 25 Arbeitsjahren in dem Gebiet... ich habe erstens schon viel gesehen, zweitens selbst schon viel gemacht und drittens mittlerweile Erfahrung wie Copy&Paste "sinnvoll" eingestezt zwar keinen einheitlichen Code ergbit, aber doch oft recht fix zumindest gut modularisierten Quelltext... den Ergeiz alles wie man es selbst mag zu verändern(also z.B. Variablen & Methoden Namen) habe ich bald sein lassen, denn wenn meine Copy&Paste Quelle der Basissource nach altem Namensschema weitergemacht hat, musste ich bei Übernahme der neunen Variante stets wieder alles umbenennen.(es gibt unter Kollegem böses Blut, wenn einer meint "seine" Variante ist die "schönste/beste")

Wenn etwas für mich garnicht geht, dann schreibe ich mir einen Funktionalen oder Objektorientierten Wrapper, da kann ich alles benennen und vor/nach Prüfen wie ich es für nötig halte.

Aber trotzdem ganz pragmatisch:
- im "daily business" für Geld programmiere ich nach Vorgabe auf Ziel mit dazu nötigter Funktions und Code Dokumentation
- wenn man Glück hat, wird ein vorheriges umfassendes Konzept als wichtig erkannt, und man bekommt das Datenmodel, Softwarestrukturmodel, sowie Software+Testkonzept ausgearbeitet zur Verfügung gestellt, oder man bekommt diese Arbeit vorab bezahlt
- "privat" oder als "bezahlten Forschungs-/Optimierungsauftrag" mache ich mit bei zunächst "ziellosen" Grundlagenentwicklungen durchaus die Arbeit, da man etwas so elegant und schön wie möglich, bzw. auch mal was so schnell&effektiv zu realisieren... das wandert dann erstmal NiceToHave in meinen Copy&Paste Source Fundus

Wenn du (aktuell) der einzige Entwickler bist, hast du im "daily business" incl. Support für so ne Fallanalyse kaum die Zeit und dir fehlt der Abstand.
Sag im Meating, das du in die Firma gekommen bist, um im Team(und sei es nur zu zweit) bestehendes zu pflegen und neues zu schaffen, du als OneManShow da aber aktuell an die Grenzen des zeitlich machbaren stößt. Schlage also vor die einen neuen internen oder sei es auch externen Partner/Berater zur Bestandsanalyse zu beschaffen.

Es heiß ja nicht das du es nicht kannst oder willst, aber es ist einfach besser wenn du bei solch perspektivischen Entscheidungen dich absicherst!... Klar bist du der neue "OneManKing" wenn es klappt, aber wenn du auf deinem Fachgebiet die einzige Person mit Kernkompetenz bist und es geht was schief, ist das immer doof weil niemand anderes fachlich weiß, wie gut/schlecht das ist was du da gemacht hast...

**jobo**

Es ist schon mehrfach gesagt worden, das Alte pflegen, Erweiterungen nach Möglichkeit neu. Alles andere ist schwer zu finanzieren und umzusetzen.
Wenn Backend / SOA nicht so chaotisch ist wie der Client, dann hast Du doch eigentlich auch ganz gute Karten, glaube ich.

Ich würde sowieso sagen, dass Systeme mit der Zeit dazu neigen, heterogen zu werden, wenn nicht schon so angelegt. Ein zentrales Backend, wo die Fäden zusammenlaufen, ist der Punkt, an dem ich mich orientieren würde.
Erweiterungen modular auf/anbauen, Interfacing wo es nur geht, Pflegemaßnahmen ggF. darauf abklopfen, ob die Pflege mit wenig Mehraufwand durch eine Neuentwicklung erledigt werden kann.

Pflege kann auch bedeuten, zentrale Dienste oder Funktionen durch (zuschaltbares) Logging anzureichern. Das kann Fehlersuche und Verständnis der Abläufe gerade in Streßsituationen ungemein erleichtern. Bei komplexen Systemen kann es sogar helfen, Dinge zu "entdecken", deren protokollierter Ablauf zwar bekannt, aber unverstanden ist. Irgendwelche Datenläufe die keinen Sinn ergeben, außer es ist Geschäftsjahresabschluss, usw. usf.

Interfacing scheint mir sehr wichtig, bezüglich Namensgebung, Rechteabgrenzung, Verantwortungsabgrenzung. Das sollte man auf jeden Fall mit Neuentwicklungen machen und nach Möglichkeit auch irgendwo einschleichen, wo man sowieso gerade etwas gerade ziehen muss.

Wenn Du die Möglichkeit hast, eine autarke (Client)Anwendung zu "ergattern", also einen Arbeitsauftrag unter Deinem Namen, (mit neuer Technologie) neue Themen umzusetzen, würde ich das natürlich auch nicht ablehnen.

**p80286**

Zum einen, alle anderen sind nicht so gut wie ich

und damals hab ich einen Mist verzapft...
In der Praxis hieß das für mich Finger weg von dem Code der das getan hat was er sollte, da wurde nur Doku ergänzt. Bei allen anderen Teilen wurden die Renovierungen von unten herauf ausgeführt, und in einer stillen Stunde wurde dann auch irgendwelcher Zaubercode durch etwas sauberes ersetzt. Und natürlich auch die Doku aktualisiert!

Ach ja , nichts ist selbstverständlich! Das ist ganz klar ein Irrtum.

Gruß
K-H

**TigerLilly**

Das ist eine unbefriedigende Situation + man bekommt rasch den schwarzen Peter, wenn was nicht oder nicht rasch genug funktioniert. Was ich aus meiner Erfahrung beitragen kann:

- Der Aufwand, etwas "neu" zu machen wird meistens dramatisch unterschätzt
- Bevor man auch nur überlegen kann, ob man etwas neu macht, muss man den Legacy Code + die Infrastruktur rundherum in seinen Abfolgen+Zusammenhängen verstanden haben. Das braucht Zeit, in der man für das Management scheinbar unproduktiv ist.
- Bevor so etwas - egal ob neu machen oder anpassen - angegangen werden kann, braucht es das Commitment und das Verständnis des Managements, dafür, was das Problem ist + dass die fehlende Doku ihr Problem ist und nicht deines.
- Legacy Code heißt immer, dass Probleme gelöst werden, die es gar nicht mehr gibt. Es geht also nicht nur darum, zu verstehen, was der Code tut, sondern auch darum, zu verstehen, ob das noch sinnvoll ist.

Deine vordringlichen Aufgaben sind also, egal ob neu machen oder nicht:
- verstehen, was der Code tut
- verstehen, was er noch/neu tun sollte
- jede Zusage auf Technologie oder Modell oder wie oder was bis auf weiteres verweigern

Wenn möglich hol dir eine/n ExpertIn dazu, als Freelancer, der dich in der Anfangsphase unterstützt. Da kannst du viel lernen + ein/e Externe/r tut sich leichter so richtig dumme Fragen zu stellen.

**Der schöne Günther**

Ich kann nichts mehr beitragen außer dem was schon gesagt wurde. Nur folgendes würde ich noch einmal unterstreichen:

Zitat von TigerLilly:

- Der Aufwand, etwas "neu" zu machen wird meistens dramatisch unterschätzt

Vor allem wenn sich die Anforderungen mittendrin dergestalt ändern dass Features die seit Jahren niemanden mehr interessiert haben und auch nicht mehr vorgesehen waren nun doch wieder plötzlich verkauft werden. Schlechte Projektplanung und Kommunikation im Unternehmen macht so eine Neuentwicklung von Grund auf nicht einfacher wenn sich nur ein Bruchteil der Betroffenen (also außerhalb der Softwareentwicklung) damit wirklich auseinandersetzt.

**bernau**

Zitat von Xzeer:

Dieser Code ist ein wilder Mix aus verschiedenen Ansätzen und Konstrukten: Code-behind, MVVM, Databinding, Events, Commands... Nichts ist wirklich einheitlich durchgezogen worden.

Handelt es sich etwa um meinen Code.

Nein im Ernst. Man entwickelt sich weiter. Dem entsprechend sieht ein Code aus, der über 10 und mehr Jahre gewachsen ist.

Wenn ich mir meinen "alten" Code anschaue, dann stechen mir sämtliche "Ansätzen und Konstrukten" ins Auge, die mich im ersten Augenblick begeistert haben und später mich zur Weisglut gebracht haben. So ist das, wenn man sich weiter entwickelt.

Ich bin zu 1/3 meiner Zeit mit refactoring meines alten Codes beschäftigt. Das ist nicht nur bei fremden legacy-code so.

Ich habe auch schon mal meine Software komplett neu geschrieben, weil ich mit der Alten an die Grenze der Erweiterbarkeit gestoßen bin. Die veranschlagte Zeit hat sich leider vervierfacht (oder war es noch mehr?). Und dass, obwohl ich das Hintergrundwissen zur Anwendung dann nicht erst aufbauen musste sondern bereits seit Jahren angeeignet hatte.

**Codehunter**

Hallo!

Ich finde, das ist einer der interessantesten Threads der letzten Zeit. Vielleicht kann ich noch eine andere Sichtweise beisteuern.

Ich habe über Jahre eine Software aufgebaut und gepflegt als sie fertig war. Der Grundstein wurde zu Delphi-7-Zeiten gelegt. Der Anforderungskatalog war recht klar definiert. Hin und wieder kam mal ne Kleinigkeit dazu, manchmal musste was angepasst werden um das neueste Windows zu unterstützen, aber im großen und ganzen eine kleine heile Welt.

Dann kam plötzlich jemand in der Geschäftsleitung auf die Idee, wir expandieren jetzt auf den russischen Markt! Außerdem war das bisherige Warenwirtschaftssystem nicht mehr genehm, es musste unbedingt ein anderes her. Da wurde einerseits die Front beim Thema Unicode geöffnet, andererseits auch noch bei den Schnittstellen zum Wawi.

Also stand ich vor der Entscheidung, das bestehende Programm anzupassen oder von Grund auf neu zu bauen. Nun war es schon 2013 und ich immer noch mit D7 unterwegs, da war ein Upgrade sehr verlockend - aus meiner egoistischen Sicht

Außerdem war ich an vielen Stellen mit dem vorhandenen Code unzufrieden. Wie es immer so ist bei gewachsenen Projekten: Man probiert mal was aus (auch aus Richtung Geschäftsleitung) und überlegt es sich wieder anders. Es bleiben halbfertige Altlasten zurück.

Es wurde also neu entwickelt. Zwei Jahre gingen dafür drauf. Pflege der alten Anwendung nahezu unmöglich, weil Mannstunden begrenzt. Zwischendurch kam Windows 7 mit etwas Verspätung in "mein" Ökosystem, die alte Anwendung lief darauf nicht mehr, also wurde der halbfertige Neubau ausgerollt. Mit dem entsprechenden Stress und Frust auf Seiten der Anwender. Derweil war es Ende 2015.

Der doofe Programmierer war natürlich schuld, weil der hatte ja in drei Jahren nix brauchbares zustande gebracht. Derweil hat sich das Projekt Russland-Expansion in blassen Dunst aufgelöst, weil der Wladimir gern Krimsekt trinkt und auf den Flaschen eine andere Flagge sehen wollte

Sich verändernde Rahmenbedingungen, die nicht vorhersehbar waren.

Irgendwann hab ich mir dann die Frage gestellt: Was wäre gewesen, ich hätte die ganze Unicode-Baustelle sein lassen und mich ausschließlich auf die Wawi-Schnittstellen (die lustigerweise auch nur 128-Byte-ANSI beherrschen) und die Windows-Kompatibilität beschränkt. Vereinfacht gesagt, wir hätten summa summarum keine halbe Million Euro in den Wind geschossen und dafür eine ziemlich angestaubte Softwarelösung. Stattdessen haben wir jetzt eine sündhaft teure Neuentwicklung mit sauberer Codebasis.

Was davon wäre nun besser rückblickend besser gewesen? Für mich Stand heute ganz klar die Variante mit D7 und Altcode. Ich hätte weniger Stress gehabt und in kürzerer Zeit flexibler auf die ein oder andere veränderte Rahmenbedingung reagieren können. Aber wie das für die Zukunft aussieht ist schwer zu beurteilen. Microsoft kann sich irgendwelche Dummheiten beim Windows ausdenken, wo sich unser neuer Code einmal bezahlt macht. Oder statt Kyrillisch wird auf einmal Chinesisch interessant. Niemand weiß es heute.

Das zwischenzeitlich neu ausgerollte Wawi entpuppte sich übrigens nach nur einem Jahr als grandioser Schuss in den Ofen. Unterm Strich 10x teurer als die vorherige Lösung, instabil und mit lausigem Anwendersupport. Letztlich auch nicht durchgehend Unicode-fähig. Das auch noch zum Gesamtfazit hinzu gerechnet, schlägt das Pendel endgültig zur Pflege von Altanwendungen aus. Das mag aber durchaus fallspezifisch sein. Für eine umfassende frühzeitige Einschätzung fehlt einem als Entwickler nicht selten die nötige Weitsicht und fachübergreifendes Knowhow. Dafür gibt es, IMHO sogar hier im Forum, Leute die das als Dienstleistung anbieten. Dies ist auf jeden Fall günstiger als wenn man wie in unserem Fall eine teure Fehlentscheidung trifft. Die ist zum Glück nicht allein auf meinem Mist gewachsen...

Wenn ich jetzt den Altcode von jemand anderem übernehmen müsste: Ich kann mir schon vorstellen, dass die Einarbeitung eine elende Sisyphus-Arbeit sein kann. Aber A) lernt man was dabei, B) kann man die durchgearbeiteten Teile gleich Stück für Stück dokumentieren und C) dabei gleich ein Ranking der zu überarbeitenden Teile aufstellen. Man schaue sich auf jeden Fall auch gründlich auf dem Markt für Zuliefer-Komponenten um. Wann immer es für bestimmte Probleme fertige Lösungen gibt, sollte man die einkaufen statt selbst das Rad nocheinmal zu erfinden. Das ist stets langfristig teurer. Man muss aber genau schauen, Pflichtenheft aufstellen, damit man sich nicht eine Krücke einkauft.

Grüße
Cody

PS: Im vorliegenden Fall scheint den größten Fehler eure Geschäftsleitung schon gemacht zu haben: Den alten Entwickler gehen zu lassen. Ohne die genauen Umstände zu kennen: Vielleicht hätte er sich seinen Verbleib vergolden lassen. Aber unterm Strich hat man da auf die "In-Brain-Dokumentation" dessen verzichtet, das man in Form eines Firmenaufkaufs teuer ins Haus geholt hat und das jetzt durch euch mit entsprechenden Reibungsverlusten nachgeholt werden muss.

**Xzeer**

Schon mal vielen Dank für alle eure Antworten.

Es hilft, die Meinung und Erfahrungen von Entwicklern zu hören, die schon lange im Berufsleben stehen. Gegen min. einen weiteren Kollegen hätte ich auch überhaupt nichts einzuwenden. Ganz im Gegenteil. Gerade den Austausch untereinander finde ich eine gute Sache, die mir aktuell fehlt.

Was ich aus vielen Beiträgen so raushöre, ist die Erfahrung, dass neu entwickeln zwar schön ist, aber oftmals aufwendiger und stressiger sein kann, als den Bestandscode nach und nach zu verbessern. Außer der Projektleiter trägt die Entscheidung einer Neuentwicklung zu 100% mit und kennt die damit verbundenen Risiken.

Bei mir ist es zusätzlich auch so, dass mir der wirklich komplette Überblick über die Lösung aktuell auch noch fehlt, da ich ja erst seit Anfang des Jahres frisch dabei bin. Die Zeit, um den Bestandcode zu analysieren und aufzuarbeiten ist also wahrscheinlich tatsächlich nicht verschwendet.
Auch wenn bei mir da so ein bisschen der Beigeschmack bleibt, etwicklungstechnisch im Leerlauf zu laufen. Sprich es gibt so viele interessante und neue Möglichkeiten (Technologien, Frameworks, Patterns) die dann erstmal nicht eingesetzt werden und an mir vorbeigehen.
Zusätzlich ist das Programm leider eben keine kleine und heile Welt, die es weiterzupflegen gilt. Sondern es stehen zum Teil große, neue Features auf dem Plan, die es so unter iOS schon gibt und über kurz oder lang in das Windows Frontend müssen, aber damals logischerweise natürlich noch nicht bedacht wurden. Daher rühren meine persönlichen Überlegungen, ob es wirklich Sinn macht, in eine metaphorisch alte Rostlaube noch zu investieren.

Aber eure Argumente gegen eine Neuentwicklung sind natürlich nicht wegzudiskutieren und sind für mich absolut nachvollziehbar.

Ich denke, ich werde also eher vorsichtig mit Vorschlägen zu einer Neuentwicklung sein.

EDIT:

Zitat von Codehunter:

PS: Im vorliegenden Fall scheint den größten Fehler eure Geschäftsleitung schon gemacht zu haben: Den alten Entwickler gehen zu lassen. Ohne die genauen Umstände zu kennen: Vielleicht hätte er sich seinen Verbleib vergolden lassen. Aber unterm Strich hat man da auf die "In-Brain-Dokumentation" dessen verzichtet, das man in Form eines Firmenaufkaufs teuer ins Haus geholt hat und das jetzt durch euch mit entsprechenden Reibungsverlusten nachgeholt werden muss.

Genau das denke ich auch. Die "In-Brain-Dokumentation" würde an manchen Stellen extrem helfen und fehlt jetzt.

**sh17**

Es spricht natürlich nichts dagegen, an den alten Entwickler noch einmal heranzutreten, aber vielleicht gibt es auch andere Differenzen oder verletzte Befindlichkeiten. Als Entwickler einer riesigen Lösung über einen langen Zeitraum baut man auch eine gewisse Bindung dazu auf. Es muss schon einiges geschehen, um sich persönlich davon zu verabschieden.