Verwaister und undokumentierter Bestandscode - was tun?

[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