Verwaister und undokumentierter Bestandscode - was tun?

[Xzeer]

Hallo zusammen,

ich wende mich an euch, da mich die Meinung von anderen Entwicklern interessiert.

Ich bin Anfang des Jahres in eine neue Firma gewechselt, um dort an der Weiterentwicklung der vorhandenen Lösung mitzuarbeiten. Zu dem Zeitpunkt waren wir primär zu zweit in der .NET Entwicklung. Der vorhandene Entwickler hat das Frontend über ~10 Jahre mehr oder weniger in Einzelarbeit entwickelt.

Die Firma ist zur Jahresmitte von einer anderen Firma übernommen worden und in diesem Zug ist dieser Entwickler kurz darauf und ziemlich kurzfristig zu einer anderen Firma gewechselt.

Ich habe also den kompletten Bestandscode geerbt. Dieser Code ist ein wilder Mix aus verschiedenen Ansätzen und Konstrukten: Code-behind, MVVM, Databinding, Events, Commands... Nichts ist wirklich einheitlich durchgezogen worden. Hinzu kommen natürlich eigene Strukturen, die irgendeinen Sinn erfüllen, aber nirgends dokumentiert wurden. Zum Frontend gehört auch noch ein Sammelsurium aus Exe-Datei Tools und PowerShell Scripts, die an verschiedenen Stellen aufgerufen werden. Insgesamt also eine recht hohe Komplexität. Ich habe überhaupt keine Dokumentation und es gibt eigentlich keine Person im Unternehmen, die Details zur Architektur wirklich kennt.

Ich rede übrigens nur vom Frontend. Im Backend sieht die Situation besser aus.

Jetzt sollen neue Funktionen in das Produkt eingebaut werden. In mir sträubt sich aber alles, weiter an diesem fremden Durcheinander weiterzuentwickeln. Es geht so viel Zeit für Reverse-Engineering drauf und teilweise weiß ich gar nicht, wo ich anfangen soll, etwas hinzuzufügen oder zu verbessern. Insgesamt frustrierend.

Noch kurz zu meiner Person. Ich bin noch relativ jung im Geschäft. Seit fast 2 Jahren aus der Ausbildung. Ich würde aber behaupten, dass ich als Entwickler grundlegend vernünftige Ergebnisse abliefern kann und nicht auf den Kopf gefallen bin.

In dieser Sache bin ich mir aber echt unsicher, auf welches Vorgehen ich in Meetings mit Kollegen plädieren soll. Ich würde ja am liebsten meine Energie in etwas neues, solides und besseres investieren, als in das alte Zeug. Langjährige Kollegen hängen aber natürlich an genau diesem Konstrukt, so wie es funktioniert und aussieht. (Die müssen die neuen Funktionen aber auch nicht einbauen) Erneuern würde natürlich einen Haufen Arbeit bedeuten. Jedoch glaube ich, dass es mindestens genauso viel Arbeit ist, den vorhanden Code zu verbessern (wenn das überhaupt vernünftig funktioniert) ...

Ich verstehe natürlich, dass man aus der Ferne schwierig eine fachliche Einschätzung vornehmen kann, aber was würdet ihr machen? Hat jemand schon mal eine ähnliche Situation gehabt?

Ich würde mich über Reaktionen sehr freuen.

[TiGü]

Nur um sicher zu gehen und die Option abzuhaken:
Du willst dort bleiben oder wäre eine neue Arbeitsstelle eine mögliche Lösung?

Bist du jetzt der einzige Softwareentwickler im Unternehmen?

[stahli]

Mit welchen Sprachen und Frameworks sind denn Frontend und Backend erstellt? Desktopanwendung oder Client/Server?

[Stevie]

Besorg dir und studier dieses Buch: Working Effectively with Legacy Code

[Xzeer]

Also eigentlich würde ich schon gerne bleiben. Weil das Produkt an sich und die Branche spannend ist.
Ich bin neben einem weiteren iOS Entwickler aktuell der einzige Kern-Entwickler im Team.

Das Frontend ist eine .NET WPF Applikation in Teilen auf Basis von Prism. Das Backend ist ein .NET WCF SOAP Service. Sowohl im Frontend, als auch im Backend gibt es noch diverese EXE-Tools und PowerShell Scripte, die immer dann verwendet wurden, wenn Teile der Logik beim/für den Kunden angepasst werden soll/sollte. Die primäre Sprache ist C#.

EDIT:
Danke für die Buchempfehlung. Das sieht echt gut aus.

[Uwe Raabe]

Zitat von Xzeer:

Ich habe also den kompletten Bestandscode geerbt.
...
Ich habe überhaupt keine Dokumentation und es gibt eigentlich keine Person im Unternehmen, die Details zur Architektur wirklich kennt.

Willkommen im Club!

Zitat von Xzeer:

In mir sträubt sich aber alles, weiter an diesem fremden Durcheinander weiterzuentwickeln.
...
Jedoch glaube ich, dass es mindestens genauso viel Arbeit ist, den vorhanden Code zu verbessern (wenn das überhaupt vernünftig funktioniert)

Das ist häufig der Standardreflex eines Entwicklers in dieser Situation.

Unterschätze den Aufwand einer Neuentwicklung nicht! In den meisten Fällen ist die einzige Dokumentation für die erforderliche Funktionalität das bestehende Programm selbst und damit auch der vorhandene Source-Code. Willst du diese Funktionalität vollständig neu entwickeln, kommst du um ein tiefes Verständnis des Programms und dessen Sourcen vermutlich nicht herum.

Solltest du nicht auch den Weg des gegangenen Entwicklers einschlagen wollen, dann empfehle ich dir dringend dich mit dem Source-Code und der Architektur auseinanderzusetzen. Nur dann hast du überhaupt die Chance abzuschätzen, wie hoch der Aufwand für eine Neuentwicklung wohl sein könnte, und nur dann hast du auch die nötige Argumentationsgrundlage deinen diesbezüglichen Vorschlag bei der Geschäftsleitung zu unterstützen. Die Erfahrung zeigt allerdings, daß ein schrittweises Erweitern und Refactoring leichter und effizienter umzusetzen ist als eine komplette Neuentwicklung.

Aus Sicht der Geschäftsleitung bedeutet deine Forderung nach einer Neuentwicklung doch nichts anderes als daß das bestehende System mit dir als Entwickler wertlos ist und die gesamten bisherigen Entwicklungskosten verloren sind (und womöglich nochmal vergleichbar hohe auf sie zukommen). Welcher Entwickler hätte demnach für die Firma einen höheren Wert: derjenige, der den alten Code wegwirft oder derjenige, der den alten Code weiterentwickelt?

[hoika]

Hallo,
die richtige Buchempfehlung hast Du ja bereits

Ich würde das Problem bei den Sitzungen genau so ansprechen (keine anständige Doku, undurchsichtige Workflows)

Ist das Projekt wenigstens in einem Versions-Management-System eingecheckt?

Ach ja:
Willkommen im Club.
Wobei es bei mir nicht so schlimm war.

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

[Xzeer]

Zitat von Uwe Raabe:

Die Erfahrung zeigt allerdings, daß ein schrittweises Erweitern und Refactoring leichter und effizienter umzusetzen ist als eine komplette Neuentwicklung.
...
Welcher Entwickler hätte demnach für die Firma einen höheren Wert: derjenige, der den alten Code wegwirft oder derjenige, der den alten Code weiterentwickelt?

Danke für die ausführliche Antwort.
Das klingt auf jeden Fall nachvollziehbar und logisch.

Mir fehlen nur aktuell gute Ansätze einen solchen schrittweisen Umbau vorzunehmen, weil vieles voneinader abhängt. Wenn ich versuche nur einen bestimmten Teil zu erneuern, passiert es schnell, dass ich viele abhängige Stellen im Code ebenfalls anfassen muss. Das grenzt dann ja fast an Neuentwicklung.

Mir fehlt da natürlich auch einfach Erfahrung. Ich habe noch kein Programm einfach mal von links nach rechts gekrempelt.

Ich werde mir auf jeden Fall mal das Buch zulegen. Ein paar der im Inhaltsverzeichnis erwähnten Problematiken habe ich eindeutig.

Zitat von mensch72:

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

Da wäre ich sofort Feuer und Flamme.
Das Problem ist ja nicht, dass man mich nicht lassen machen möchte oder es mir nicht zutraut.
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.

Zitat von mensch72:

[...] 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

Das finde ich persönlich etwas kurz gedacht. Natürlich kann ich irgendwie und auf Biegen und Brechen 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.