Verwaister und undokumentierter Bestandscode - was tun?

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

[Bernhard Geyer]

Zitat von OlafSt:

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.

Das mit den "überall Fremdkomponenten nehmen" ist aber keine allgemeine Meinung.
Und vor allem nicht soll man nicht für jede Funktion eine andere Komponenten nehmen.

Wir hatten auch schon so einen Wildwuchs den ich mittlerweile halbwegs "eingestampft habe".
Ein Komponente für DB (Unidac von Devart), 1-2 für die GUI (LMD wegen Unicode), eine Komponenten für Kommunikation, und natürlich (gibt ein paar Stellen wo es nötig ist) JCL ...
RX, TNTWare, VCLZip sind über die Jahre rausgeflogen.

Zitat von OlafSt:

... tauschen die Datenbankkomponenten von "keine Ahnung, was das ist" auf FireDAC

Schau dir mal die Unidacs an. Ist günstiger und 1a Qualität. Bei Delphi musst du sonst immer die IDE hochziehen wenn du neu DB-Unterstützen willst.

[himitsu]

Gerade bei Fremdkomponenten versuchen wir für Alles nur noch Welche inkl. Quellcode zu verwenden, weil man da theoretisch wenigstens noch die Möglichkeit hätte das mal auf ein neues Delphi zu portieren, selbst wenn der Hersteller verschwunden ist.
Und auch kleinere Bugfixes sind so noch möglich, auch wenn der Hersteller nicht schnell genug das beheben kann/mag.

Da hat man dann oftmals noch mehr undokumentierten Fremdcode im Programm, aber alles selber machen ist auch keine Lösung.

[Der schöne Günther]

Deine Situation ist ja doch recht ähnlich wie bei mir. Ich war auch neu (2013) und langfristig sollte dann eine bestehende Software "neu gemacht" werden, hauptsächlich durch mich.

Die Wahl fiel hier auf eine komplette, saubere Neuentwicklung von Anfang an. Es hat gedauert und gedauert und irgendwann haben wir den Stecker gezogen und eingesehen dass man nicht eine Software die über 15 Jahre gewachsen ist, innerhalb von 18 Monaten von Grund auf neu schreiben kann, vor allem hauptsächlich von jemandem der neu ist. Und besonders dann nicht, wenn die Anforderungen so "agil" sind dass Features die seit 10 Jahren keinen mehr interessiert haben jetzt doch plötzlich wieder rein müssen und bitte bis nächste Woche.

Innerhalb von 1-2 Wochen haben wir in einer Gewaltaktion dann die bestehende Software genommen (die ja auch weiterhin supported werden muss), eine neue Oberfläche gemacht, im Backend ein paar Dinge neu gemacht (z.B. Teile Persistierung) oder aufgebohrt und was dann heraus kam war echt schon fast besser als das woran monatelang gearbeitet wurde.

Klar lag der Fehlschlag beim "Neumachen" wohl hauptsächlich an nicht vorhandenem Projektmanagement und dem festen Glauben an das Chinesen-Prinzip. Trotzdem war die Entscheidung die bestehende Software zu nehmen, auseinanderzupflücken, Tests zu schreiben und Schritt für Schritt zu erneuern die vielleicht beste Entscheidung die ich hier bislang durchbringen konnte

[Sherlock]

Gegen eine Neuentwicklung spricht vor allem eines: Es werden garantiert Funktionen fehlen, die von den Anwendern schmerzlich vermißt werden. Sowas kann einem dann ganz schnell und ganz rabiat den Hals brechen.

Hab das schon zweimal gesehen, als eine Firma ihr bewährtes Produkt, daß auf einer recht angestaubten Codebasis und reichlich individuellen Anpassungen baute mal so eben nach .net wuppen wollte. Hinterher sah alles Supi aus, und war bestens dokumentiert, aber es konnte die Anwender schlicht nicht zufrieden stellen, weil eben viele der nützlichen aber undokumentierten Funktionen fehlten. Das brach beiden Firmen das Genick. Ich würde lieber versuchen, die Dokumentation nachzuziehen. Es gibt heutzutage ja viele Tools, die dabei helfen.

Sherlock

[OlafSt]

Gerade bei meinem Projekt hier ist das nicht ganz so einfach Die Umstellung auf [irgendein]DAC allein wird schon ne Weile dauern. Denn [irgendein]DAC gibt es nicht für Delphi 5. Die im Projekt verwendeten DB-Komponenten existieren nur noch hier, Hersteller und Websites sind längst im Nirvana verschwunden. Bedingt durch Delphi 5 ist die Portierung auf Tokyo nahezu aussichtslos, das geht bereits bei nicht existenter Unicode-Unterstützung los...

Den Wildwuchs an Komponenten konnte ich soweit eindämmen. Hier lief ein Subset von TMS, LMD, RXLib, drei veschiedene PDF-Generatoren, Fastreports, QuickReports, FastNet, vier verschiedene Excel-Komponenten, diverse DBGrids und Treecontrols usw... Alles in allem ein riesengroßer Haufen Mist

Nachdem wir uns eine Weile im Code umgeschaut haben, kamen wir dann zu dem Entschluß, erstmal die allerheftigsten Bugs zu beseitigen. Nach 6 Monaten gibt es nun eine Version, die nicht nach dem dritten Mausklick mit ner Schutzverletzung zum Desktop rausbombt Nun können wir langsam die Controls für die GUI gegen Standards tauschen und irgendwann Q3 2018 gehts an die DB-Geschichten.

Am Anfang war ich auch der Ansicht: Wegwerfen, neu machen. Aber das Projekt hier ist einfach zu komplex, zu verworren, zu undokumentiert und zu unstrukturiert. Hier geht es nur über ein langsames Refactoring, sonst geht das Projekt direkt an die Wand.

[sh17]

Nochmal was aus der Sicht des Anwenders, wie auch schon oben angesprochen. Angenommen, es soll eine Neuentwicklung werden, dann läuft die alte Anwendung während der Entwicklung nebenbei weiter. Wenn man dann mal in 3-4 Jahren "fertig" ist, hat man definitiv 2 verschiedene Produkte mit ggf. noch fehlender Funktionalität in einem von beiden. Jetzt geht der Spass mit dem Support erst los. "Alles neu, alles doof, früher ging das doch, wieso ist das jetzt so?, ich will das alte Programm wieder haben".

[OlafSt]

Zumindest mein Boss ist da eisenhart: "Dieses Programm gibt es nicht mehr". Basta.

Dann erklärt er, wie es in der neuen Software geht (meist dann viel einfacher) und alle sind glücklich.

[Towmuz]

Zitat von sh17:

"Alles neu, alles doof, früher ging das doch, wieso ist das jetzt so?, ich will das alte Programm wieder haben".

Diese bornierte Haltung ist später das größte, wenn nicht einzige, Problem, wenn man alles richtig gemacht hat.
Angefangen mit einem: "Warum ist der Knopf jetzt 2cm weiter rechts und wieso ist der nicht mehr in clAqu...clVergewaltigung eingefärbt, ich hab jetzt 10 Jahre immer an der Stelle auf den Knopf gedrückt...und wieso ist das Fenster jetzt so groß? Ich will die Liste erst durch die horizontale Scrollbar sichtbar machen...".

Bis hin zu: "Boah muss das so kompliziert sein? 3 Werte eintragen? Echt jetz? Ihr könnt doch die Programme nicht einfach an die Geschäftsprozesse anpassen, verdammt. Wer macht denn sowas?".

[sh17]

kommt sicher auch darauf an, wie die Zielgruppe aussieht. Aber generell möchten die arbeiten und sich nicht ständig in neue Arbeitsabläufe der Software reindenken. Aber ok, war nur ein Gedanke.