Verwaister und undokumentierter Bestandscode - was tun?

[Codehunter]

Dann gutes Gelingen!

[Delphi-Laie]

Leider drücken Chefs nur allzugern auf's Tempo, vor allem die, die eine solche Tätigkeit und Herausforderung nicht selbst einmal erlebten.

Klar, Zeit ist Geld, und die Chefs möchten Ergebnisse sehen. Codesichtung und -verstehen sind aber nur solche im Kopfe, also unsichtbare. Und das kann schnell in einer gereizten Atmosphäre enden. Der eine muß sich oft oder andauernd rechtfertigen und sieht sich zu unrecht gedrängelt, der andere drängelt und gängelt und setzt sich damit dem Verdacht aus, "Bummelei" wenigstens implizit zu unterstellen.

Viel Erfolg!

[Der schöne Günther]

Zitat von Delphi-Laie:

Klar, Zeit ist Geld, und die Chefs möchten Ergebnisse sehen. Codesichtung und -verstehen sind aber nur solche im Kopfe, also unsichtbare. Und das kann schnell in einer gereizten Atmosphäre enden. Der eine muß sich oft oder andauernd rechtfertigen und sieht sich zu unrecht gedrängelt, der andere drängelt und gängelt und setzt sich damit dem Verdacht aus, "Bummelei" wenigstens implizit zu unterstellen.

Das kennen wir ja sicher alle

[delphirocks]

Ich war an mehreren Projekten dieser Art beteiligt. Zuerst haben wir tlw. jahrelang versucht, das Problem in den Griff zu bekommen - erfolglos. Das Neuschreiben ging dann besser und schneller als gedacht. Weil wir die Fehler der alten, "historisch gewachsenen" Software nicht mehr gemacht haben und gleich zu Anfang ein paar vernuenftige Grundsatzentscheidungen getroffen haben.

Moderne Technologien machen heutzutage viele Aufgabenstellungen um einiges einfacher. Selbst gestrickte Datenbanken, Messagequeues, Cluster Software usw. sind z.B. haeufig so Kandidaten, die einem in altem Code das Leben schwer machen. Da nehm' ich etwas "Fertiges" und erspare mir vielleicht hunderttausende Zeilen oder mehr.

Wie immer kommt es auf die konkrete Situation an.

[mensch72]

Alles beginnt mit der Istanalyse, denn erst so wird wenn wie hier ohne Doku klar, was überhaupt wie und wo funktionieren soll, ich denke da herrscht allgemein als auch unter den beschriebenen Bedingungen "Konsens".

Diese Istanalyse geschieht im laufendem Betrieb, denn nur so ergibt sich "nebenbei" was wie/wo geht, bzw. was eben aktuell nicht geht.
Der TE hat ja nach eigenen Angaben noch nicht soviel fremdes selbst gesehen.. da sei dieser Step durchaus auch eine gute Lernphase, wie man mit fremden auch suboptimalem Code umgeht.

Solange man noch nix selbst ver(schlimm)bessert hat, gilt gegenüber Chef & Kunden der Grundsatz: Sorry doof das X gerade noch nicht oder nicht mehr geht, aber ich habe das von Y wie bekannt (MM/YYYY) so übernommen und arbeite nun an einer zeitnahen und stabilen Lösung. PUNKT, zu mehr sollte man sich ohne Erfahrung nicht hinreißen lassen.
Auch kein Externer wird sich wenn er nicht zufällig schon exakt das im Schubfach fertig liegen hat, in solchen "gewachsenen Projekten" weiter aus dem Fenster lehnen oder gar irgendwelche Funktionszusagen in ZeitX verbindlich machen. (zumindest ich würde es nicht tun )