Verwaister und undokumentierter Bestandscode - was tun?

**mensch72**

sicher nicht schön, aber sieh es positiv:
"Ich rede übrigens nur vom Frontend. Im Backend sieht die Situation besser aus."... das ist doch super, also ist Backend doch dut dokumentiert... Also sind Schnittstellen,Daten und Funktionen auf dieser Seite klar, und somit ist indirekt ja auch klar, was das Frontend bekommt/liefert(egal "wie" es das macht)

Letzendlich willst du ein neues Frontend anfangen, wenn du da nur Argumente ala "der aktuelle Code ist Mist und nicht dokumentiert" bringst, kommt das nicht gut wenn du es 2Jahre ausgelernt hast, denn du kannst aktuell ja nicht beweisen das du nach eigenem Konzept und soviele Jahre es "besser" kannst.

Also biete an, einen Teilbereich des Frontends mit was aktuellem sauber neu zu machen, was optimaler Weise trotz zunächst gleicher Funktion einen für Dritte erkennbaren Mehrwert hat... also z.B. realisiere das Frontend als WebInterface, oder realisiere das Frontend auf anderer Platform (z.B. für Mobile oder Mac).

Wenn das gut ankommt, dann bekommst du im Optimalfall StepByStep die Zeit weitere Frontendfunktionen so umzusetzen und auch die passenden Tools zu erstellen.
Sieh die Tatsache das alter Quellcode weil/trotz nicht Standardkonform ist und vieles da undokumentiert mehr für dich als Möglichkeit da an Erfahrung zu gewinnen, sich in fremden Code auch im Blackbox Verfahren funktional einzuarbeiten... sowas lernst du in keiner Schule, aber es wird dir in der Realität oft weiter helfen, denn "irgendwelchen" fremden Code mit "irgendwie" mit eigenen zu verbinden sollte man "auch können", das Gefühl was sich zeitlich lohnt entwickelt sich da nur durch Versuch und Irrtum

**himitsu**

Zitat:

und nicht dokumentiert

Nja, du wirst bestimmt auch nicht alles perfekt dokumentieren, wenn du es neu machst und in paar Jahren dann jemand anderes deinen Code sieht und das Selbe sagt.

Altcode dokumentieren (kürzer)
Neucode scheiben, vorher perfekt planen und alles dokumentieren (länger)

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

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

**OlafSt**

Vielleicht kann ich auch noch etwas beitragen. Ich mache schon 3 Jahrzehnte in Software-Entwicklung und habe schon eine Reihe großer bis sehr großer Programme "unter den Fingern" gehabt. Groß beginnt bei mir ab ner Million Codezeilen, ohne Fremdkomponenten.

Zwei dieser Projekte sind deutlich über 20 Jahre alt, eines davon noch mit Delphi 5. Dieses ist nur noch mit Mühe unter Windows 10 zum laufen zu bringen. Es ist absehbar, wann der Compiler einfach nicht mehr funktionieren wird.

Hier wurde erwähnt, das man für alles am besten Fremdkomponenten nehmen sollte. Dem widerspreche ich in aller Form

Denn hier, in diesem Projekt, sind das inzwischen an die hundert solcher Komponenten geworden, von denen ich vier (!) auf ein neues Delphi bringen konnte. Die restlichen Komponenten sind nicht austauschbar, es gibt auch keine neuen Versionen davon - sie müssen also hart refaktoriert werden.

Der restliche Code ist der übliche Alptraum, hier haben sich an die 20 Entwickler versucht, in den unterschiedlichsten Kompetenzgraden. Aber eines ist klar: Neu schreiben kommt nicht in Frage. Wir portieren Fenster für Fenster in DX10, ziehen Unicode nach, tauschen die Datenbankkomponenten von "keine Ahnung, was das ist" auf FireDAC etc. Das wird auf lange Sicht deutlich billiger werden, als es neu zu implementieren. Die Software ist in der Werbebranche zu Hause, da wird so oft ne neue Sau durchs Dorf getrieben... Da macht das schrittweise Umschreiben mehr Sinn.