class operator OnesComplement ? o.O

[Uwe Raabe]

Zitat von Mavarik:

Ein paar Longstrings in einem Record haben jetzt schon 6 Monate mit nahezu 18/7 Programmierung gekostet... Bei Projekten > 500 Units und > 2 Mio. Zeilen ist nix "mal eben" gemacht. Da gibt es auch keine Inseln die man mal eben umbaut... Jede Änderung zieht sich durch mindestens 350 Units. Immer wenn schon der Grep mehr als 10000 Stellen ausgibt, sucht man nach besseren Lösungen. Besonders, da es 5000 Stellen gibt die weder grep noch der Compiler findet...

An so einer Stelle war sicher jeder von uns schon mal und die meisten (wenn nicht alle) werden dort auch immer wieder ankommen - selbst mit aktuell akzeptablen Code-Strukturen. Es entwickelt sich halt alles weiter und der Aufwand für die Code-Pflege muss irgendwie mit eingerechnet werden. Du bist somit auch sicher nicht der erste und einzige der hier ein gehöriges Pack an Technical Debt angesammelt hat. Man kann das entweder aussitzen oder doch in den sauren Apfel beißen. Dabei kann sowohl das eine wie auch das andere eine Firma ganz gehörig belasten. Man darf die dadurch entstehenden (teils virtuellen) Kosten nicht einfach ignorieren. Insofern kann ich eine gewisse Zurückhaltung durchaus verstehen. Eine solche Investition muss gut überlegt sein.

[himitsu]

Zitat von Uwe Raabe:

An so einer Stelle war sicher jeder von uns schon mal und die meisten (wenn nicht alle) werden dort auch immer wieder ankommen - selbst mit aktuell akzeptablen Code-Strukturen. Es entwickelt sich halt alles weiter und der Aufwand für die Code-Pflege muss irgendwie mit eingerechnet werden.

Dank Mobile, NextGen, AutoRefCount, ZeroBasedStrings, UnitNamespaces usw. wird es auch nicht leichter.
Man muß seine Codes weiterentwickeln, sich neue Wege überlegen und kann die schöne Abwärtskompatibilität genauso vergessen, wie die problemlose Wiederverwendbarkeit in allen Platformen.

[Mavarik]

Zitat von himitsu:

Man muß seine Codes weiterentwickeln, sich neue Wege überlegen und kann die schöne Abwärtskompatibilität genauso vergessen, wie die problemlose Wiederverwendbarkeit in allen Platformen.

Ich rede ja nicht von neuen Plattformen... Da kann man ja noch sagen: OK! Neue Plattform, neuer Sourcecode!

Aber wir reden von Compiler D2007 auf XE7 und dann ggf. noch auf 64Bit... Kaum machbar bzw. der Aufwand einfach seht groß. Hier muss man sich gut überlegen ob es das Wert ist!

Der Eigenantrieb ist natürlich schon groß, wenn man auf der einen Seite iOS&Android programmiert mit Generics, Parallel.Library und anonymen Proceduren und dann wieder zurück geht um die Windows Version zu pflegen und "alles" fehlt.

Mavarik

[Uwe Raabe]

Zitat von Mavarik:

Aber wir reden von Compiler D2007 auf XE7 und dann ggf. noch auf 64Bit... Kaum machbar bzw. der Aufwand einfach seht groß. Hier muss man sich gut überlegen ob es das Wert ist!

Das kannst du aber nicht so allgemein sagen. Bei meinen Projekten war der Umstieg von D2007 auf D2009 innerhalb weniger Stunden erledigt, nachdem alle verwendeten Libraries verfügbar waren. Der Sprung nach 64-Bit ging nicht ganz so reibungslos, da in alten Zeiten noch Extended-Werte in externe Dateien geschrieben wurden und ich zumindest das Lesen dieser Dateien noch sicherstellen musste. Aber auch hier war durch eine zwischengeschaltete Leseroutine der Drops schnell gelutscht.

Auch andere Projekte meiner Kunden, die z.B. von D5 nach XE3 portiert wurden, machten zumindest in diesem Punkt keine Probleme. Der Löwenaufwand steckt dort meistens im Aufräumen der im Laufe der Jahre verwachsenen Architektur.

Wenn man sich frühzeitig von PChar-Arithmetik, AnsiStrings und ShortStrings verabschiedet hat, sind solche Umstellungen eigentlich kaum der Rede wert. Es hilft wirklich, seinen Code ständig so zu pflegen, wie manche Leute ihr Auto.

[Mavarik]

Zitat von Uwe Raabe:

Es hilft wirklich, seinen Code ständig so zu pflegen, wie manche Leute ihr Auto.

Dem entgegen steht: Never change a running System...

[Uwe Raabe]

Zitat von Mavarik:

Zitat von Uwe Raabe:

Es hilft wirklich, seinen Code ständig so zu pflegen, wie manche Leute ihr Auto.

Dem entgegen steht: Never change a running System...

Es sei denn, es läuft auf dem Holzweg oder vor die Wand. Ich habe auch (ehemalige) Kunden, die ihr "Running-System" solange nicht angefasst haben, daß jetzt jede noch so winzige Änderung das Budget sprengen würde. Das ist leider kein Einzelfall. Bei einem Kunden hat dann letztendlich wirklich der Blitz eingeschlagen (ernsthaft!) und quasi eine Erneuerung erzwungen.

[smallie]

Catch-22:

... man müßte das System tiefgreifend ändern, um es testfähig zu machen.
... ohne ein testfähiges System zu haben, kann man es nicht tiefgreifend ändern.

[Stevie]

Zitat von Mavarik:

Zitat von Uwe Raabe:

Es hilft wirklich, seinen Code ständig so zu pflegen, wie manche Leute ihr Auto.

Dem entgegen steht: Never change a running System...

Typisches Totschlagargument wenn man einfach nix machen will - oder Angst vor Änderungen hat.

Diese Angst beruht aber oft darauf, dass es dunkle Ecken im System geht, die man nicht kennt oder versteht. Hat man Code, den man versteht, der abgetestet ist und wo keine schwarze Magie drin steckt, dann ist eine Änderung genauso painless wie nen Öl- oder Reifenwechsel.

Da die meisten Programmierer aber immer noch vorgehen wie Meister Röhrig, sieht der Code halt auch oft "zusammengetüdelt" aus.

[Uwe Raabe]

Zitat von Stevie:

Typisches Totschlagargument wenn man einfach nix machen will - oder Angst vor Änderungen hat.

Diese Angst beruht aber oft darauf, dass es dunkle Ecken im System geht, die man nicht kennt oder versteht. Hat man Code, den man versteht, der abgetestet ist und wo keine schwarze Magie drin steckt, dann ist eine Änderung genauso painless wie nen Öl- oder Reifenwechsel.

Da die meisten Programmierer aber immer noch vorgehen wie Meister Röhrig, sieht der Code halt auch oft "zusammengetüdelt" aus.

Es kommt ja auch vor, daß man selbst gar nichts für diese Situation kann. Wer hat nicht schon mal ein solches Projekt geerbt oder den Auftrag bekommen, "mal eben" eine kleine Änderung daran zu machen? Sei es, daß der Verursacher gar nicht mehr da ist oder auch einfach nur nicht mehr klar kommt. Ein "das müssen wir neu schreiben" ist dann nur selten die richtige Antwort.

[Bernhard Geyer]

Zitat von Stevie:

Zitat von Mavarik:

Zitat von Uwe Raabe:

Es hilft wirklich, seinen Code ständig so zu pflegen, wie manche Leute ihr Auto.

Dem entgegen steht: Never change a running System...

Typisches Totschlagargument wenn man einfach nix machen will - oder Angst vor Änderungen hat.

Vor allem gibt es heute keine Statisches System mehr.
Alle 4 Wochen gibts Windows-Updates (OS-API-Verhaltensänderungen), Alle 2 Woche Adobe-Updates (PDF-Integration), alle 5 Jahre wird der Rechner ausgetauscht (Neues OS, Ander HW mit unterschiedlichen Treiberverhalten), alle 5 wird ein ERP/PLM/CRM-System mit dem man Arbeitet durch ein anderes ersetzt...