class operator OnesComplement ? o.O

[Mavarik]

Zitat:

Zitat von Uwe Raabe (Beitrag 1293329)

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:

Zitat von Mavarik (Beitrag 1293355)

Zitat:

Zitat von Uwe Raabe (Beitrag 1293329)

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.

:stupid:

[Uwe Raabe]

Zitat:

Zitat von smallie (Beitrag 1293370)

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:

Zitat von Mavarik (Beitrag 1293355)

Zitat:

Zitat von Uwe Raabe (Beitrag 1293329)

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:

Zitat von Stevie (Beitrag 1293390)

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:

Zitat von Uwe Raabe (Beitrag 1293392)

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?

[Bernhard Geyer]

Zitat:

Zitat von Stevie (Beitrag 1293390)

Zitat:

Zitat von Mavarik (Beitrag 1293355)

Zitat:

Zitat von Uwe Raabe (Beitrag 1293329)

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

[Uwe Raabe]

Zitat:

Zitat von Stevie (Beitrag 1293426)

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 :thumb:

[Mavarik]

Zitat:

Zitat von Stevie (Beitrag 1293390)

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 gebe ich Dir zu 100% Recht!

Edit: [OT]

Man(n) hat irgendwo im Jahr 1984 mit dem Code angefangen... Turbo Pascal 1.5/2.0
Aus dieser Zeit existiert noch Code der bis heute unverändert ist.

Der Tag hat nur 24h, die Woche nur 7 Tage... Die Kundenanzahl wächst, die Wünsche auch...
Also bleibt Code so lange unangetastet, bis dafür Bedarf besteht.

Dann Mitte 96 die versuchen mit Delphi 1 den DOS-Bildschirm in einem Windowsfenster zu emulieren verworfen. Denn Delphi 2 ist rausgekommen...

Also schnell im RAD-Style die nötigen Fenster zusammen geklickt...
Button -> Doppelklick -> Code rein... Genau wie es in JEDER Präsentation gezeigt wurde...

JEDER hat so programmiert... Es soll mir keine erzählen er hätte mit Delphi 2 MVVM gemacht und nur gegen Interfaces programmiert...

Also:
Der Tag hat nur 24h, die Woche nur 7 Tage... Die Kundenanzahl wächst, die Wünsche auch...
Also bleibt Code so lange unangetastet, bis dafür Bedarf besteht.

Dann kommt plötzlich jemand auf die Idee das "alle" Strings plötzlich Unicode "seien müssen"...
Und schon bleiben unzählige Projekte auf D2007...

Hätte man es 1984 wissen können?
Hätte man früher etwas machen müssen?

Alles Fragen nach der verschütteten Milch...

Ein Monster-Projekt auf MVVM umbauen? Eher nicht... Das wäre eine Neuentwicklung..

Dem Kunden ist es auch egal wo der Code ist, wenn er einen Button drückt...
Es bezahlt keiner für "schönen" Code, damit wir Programmierer uns um Kreis stellen und gegenseitig auf die Schulter klopfen können.

Denn:
Der Tag hat nur 24h, die Woche nur 7 Tage... Die Kundenanzahl wächst, die Wünsche auch...
Also bleibt Code so lange unangetastet, bis dafür Bedarf besteht.

Und die ein oder andere "dunkle Ecken im System" bleibt uns noch ein bisschen erhalten...

Aber hin und wieder wird eine beseitigt... Alles wird gut...

Edit: [/OT]

Mavarik