Verwaister und undokumentierter Bestandscode - was tun?

[Codehunter]

Dann fasse ich mal zusammen:

• Dem Chef gegenüber klar kommunizieren, dass vor dem Einbau neuer Features erst mal eine gründliche Bestandsaufnahme erfolgen muss
• Altcode erhalten, sichten, verstehen, dokumentieren
• In einem zweiten Schritt erkannte Probleme beseitigen
• Wenn es unbedingt eine Neuentwicklung sein soll, dann sollte sie neben der Pflege des Altcodes stattfinden
• Versuchen einen, vielleicht inoffiziellen, Kanal zum ursprünglichen Entwickler aufzubauen für Fragen zu besonders kniffligen Problemen (Vorsicht, dicke Luft!)
• Nicht jedes Rädchen neu erfinden. Im Altcode gibt es 70% fertige Lösungen, den Rest entwickelt man selber oder kauft was ein
• Den Altcode nach Abhängigkeiten durchforsten (z.B. Steinzeit-DBMS die nicht mehr supportet werden)
• Keinen Flickenteppich zusammenkaufen sondern nach Möglichkeit lieber einige wenige, dafür große Frameworks von etablierten Anbietern

Was vergessen?

[TigerLilly]

[Xzeer]

Auch wenn ich jetzt seit einigen Posts ruhig war, habe ich die ganze Zeit über intressiert mitgelesen.

Sehr spannend zu sehen, wie es in anderen Firmen und Projekten aussieht. Das Thema Altlasten scheint ja nicht unproblematisch zu sein.

Danke and Codehunter für die Zusammenfassung.

Ihr habt mich auf jeden Fall davon überzeugt, die Codebase erstmal weiter zu durchdringen, zu verstehen und stellenweise so anzupassen, dass ich darauf folgend, eingermaßen guten Gewissens, neue Funktionen einbauen kann. In dem Zug habe ich auch vor, die bisher eher spatanische Dokumentation etwas weiter auszubauen. Ich habe gemerkt, dass man eine viel bessere Grundlage im Meeting hat, wenn man anhand eines Bilds/Diagramms zeigen kann, warum eine bestimmte Funktion nicht ganz so leicht/schnell einzubauen ist, wie man zuerst vermuten könnte. Oftmals ist die Architektur oder der Code des Programms bei Projektleitern/Entscheidern immer sehr viel ordentlicher in Erinnerung, als es tatsächlich der Fall ist. Ist oft alles ganz einfach und mal eben.

Wie von Codehunter hier im Thread ja schon genannt wurde, ist ja vielleicht ein zukünftiger Projektzweig denkbar, in dem nach und nach über einen längeren Zeitraum eine neue Version entsteht.

[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 )

[Codehunter]

Zitat von Xzeer:

Das Thema Altlasten scheint ja nicht unproblematisch zu sein.

Sehr diplomatisch ausgedrückt

IMHO ist das Thema Software Lifecycle sehr schwierig. Selbst Milliardenkonzerne wie Microsoft können da auf die Nase fallen. Siehe Windows. Je älter das Produkt wird, umso häufiger scheinen Major-Releases zu floppen.

Ein Paradebeispiel sind eigentlich die Webbrowser. Man schaue sich die ganze Geschichte mal an:

Am Anfang war der Mosaic. Ein sperriges Stück Software, entsprungen aus den Untiefen elitärer akademischer Umgebungen. Es kam der Netscape Navigator mit einer hübschen Oberfläche, die jeder bedienen konnte. Aus wars mit Mosaic im breiten Feldeinsatz. Netscape wurde älter und fetter.

Es kam der IE mit vielen proprietären Non-Standard-Extensions wie z.B. Blinke- und Marquee-Text-Effekten. Das Web wurde schrecklich "zappelig" weil alle Webdesigner die lustigen Effekte des IE einsetzten. Der Netscape zeigte dagegen standardkonforme Langeweile an und verschwand bald in der Versenkung, während der IE einen Marktanteil von 96% hatte und älter und fetter wurde.

Es kam der Firefox. Genauso kostenlos wie der IE, definitiv schneller und frei vom faden Beigeschmack des "Big Brother" aus Redmond. Außerdem mit der cleveren Idee des Addon-Store. Der FF näherte sich 80% Marktanteil. Während im Hintergrund Google mit einer gigantischen Marketingmaschinerie den neuen Chrome-Browser in Position brachte, der unter der Haube mit diversen wilden Hacks "glänzte", verstrickte sich Mozilla in endlosen Diskussionen um die Schönheit des Codes. Chrome legte eine JS-Performance an den Tag, da konnte FF nur mit den Ohren wackeln. Es kam wie es kommen musste: Firefox wurde älter und fetter, Chrome dagegen hatte einen Marktanteil von über 60%.

Nun versuchen Microsoft mit Edge und Mozilla mit Firefox 57 wieder gegen zu steuern. Dabei werden ganz verschiedene Strategien verfolgt:
Microsoft nimmt die alte IE-Trident-Engine, stülpt eine mehr oder weniger hübsche neue Oberfläche ("Hausmeinung" bei Microsoft) drüber und wirft ein paar überkommene Altlasten raus. Beim ersten Release von Edge schauten sich alle an und fragten sich: Was zur Hölle soll der Blödsinn? Aus Nutzersicht konnte der Browser nicht mal die Hälfte dessen, was Firefox und Chrome konnten. Er war instabil, beherrschte nicht mal die Fähigkeit, Lesezeichen zu speichern und sah zudem auch noch mit der unbeliebten Metro-ModernUI-Oberfläche potthässlich aus. Man konfrontiert den Nutzer defakto mit einem völlig neuen Programm, anderem Aussehen und neuem Namen. Was soll ich sagen? Marktanteil 3,5% Stand heute.

Mozilla dagegen geht mit Firefox 57 einen gänzlich anderen Weg. Man modernisiert und modularisiert das Innenleben des Browsers und der Engine im Hintergrund schon seit langer Zeit. Teile der Neuentwicklungen sind bereits seit Firefox 53 eingeflossen. Mit Version 57 dann der große Wurf mitsamt neuer Oberfläche und neuen Schnittstellen. Ein ganzer Haufen veralteter Addons fliegt raus, weil nicht mehr supportete Schnittstellen genutzt werden. Ausgerollt wird das Update im normalen Service-Pfad als schlichtes Service-Update "getarnt". Marktanteil 23% Stand heute.

Chrome steht übrigens aktuell bei 35%. Die Statistiken sind hier entnommen.

Was lernen wir daraus? Software hat viel mit Psychologie zu tun. Der Nutzer will ein stabiles Programm, ohne sich ständig an neue Bedienweisen, Mauspfade und UI-Layouts gewöhnen zu müssen. Stetige kleine Veränderungen mit positiven Auswirkungen werden mehr goutiert als Knall-auf-Fall-Veränderungen. Deshalb ist die stetige Pflege von Bestandscode aus marktstrategischer Sicht die klügere weil wirtschaftlichere Vorgehensweise.

Neuentwicklungen sind zweifelsohne der einfachere Weg aus Sicht des Entwicklers. Doch was nützt einem das, wenn der Anwender am Tag X die Wahl hat, sich an ein völlig verändertes Programm von Anbieter A zu gewöhnen oder stattdessen sich in ein gleich teures, aber mit mehr Features versehenes Programm von Anbieter B einzuarbeiten. Wenn man als Anwender so oder so neu lernen muss, dann nimmt man doch zumindest die Kiste, wo die süßeren Äpfel drin sind.

[Der schöne Günther]

Tolles Beispiel mit Edge und Firefox . Bei Edge mussten sie irgendwann einfach liefern (während der IE natürlich weiter supported werden muss!) und der Browser kam absolut unfertig und mit zu wenig Features auf den Markt.

Viele gaben ihm eine Chance und wechselten dann enttäuscht. Daran ändert nichts dass der Browser mittlerweile wirklich gut ist und zumindest für mich überall ausreicht.

Grade Microsoft versteht oft überhaupt nicht dass ein drastischer Sprung ins kalte Wasser wo alles plötzlich komplett neu ist die Leute eher vertreibt als begeistert. Paradebeispiel Windows 8