class operator OnesComplement ? o.O

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

[Uwe Raabe]

Zitat von 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.

In dem Fall empfehle ich diese Lektüre: Working Effectively with Legacy Code

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

[Stevie]

Zitat von Uwe Raabe:

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.

Hab ich irgendwo was von "neu schreiben" geschrieben?
Was machst du denn, wenn du ein altes vergammeltes Haus erbst? Einziehen und drauf hoffen, dass es dir nicht aufn Kopf fällt? Oder es renovieren?

[Uwe Raabe]

Zitat von Stevie:

Hab ich irgendwo was von "neu schreiben" geschrieben?
Was machst du denn, wenn du ein altes vergammeltes Haus erbst? Einziehen und drauf hoffen, dass es dir nicht aufn Kopf fällt? Oder es renovieren?

Vielleicht habe ich mich unklar ausgedrückt. Auf keinen Fall wollte ich dir eine Aufforderung zum "neu schreiben" unterstellen. Das ist aber häufig das, was bei einem Entwicklerwechsel passiert. Dazu muss das Projekt gar nicht mal schlecht wartbar sein. Es reicht, wenn der Neue in manchen Dingen (z.B. Programmiersprache) nur andere Präferenzen hat. Mein Nachfolger bei meinem letzten Arbeitgeber hatte entgegen meiner ausdrücklichen Empfehlung keine Ahnung von Delphi. Das Projekt wurde dann in Java neu begonnen. Nach einem Jahr wurde er dann wegen nicht erfüllter Erwartungen durch einen C++-Jünger ersetzt. Nach nunmehr fast 10 Jahren ist das Projekt noch meilenweit von dem damaligen Delphi-Stand entfernt. Aber der für diese Personalentscheidungen Verantwortliche bekommt natürlich regelmäßig seinen Bonus. Sorry, ich schweife ab.

Ich wollte eigentlich nur aufzeigen, daß fehlende Pflege nicht immer in unserer Hand liegt. Das "Renovieren eines vergammelten Hauses" ist genau das, was ich eigentlich ausdrücken wollte. Danke für diese Metapher