Big_Ball_of_Mud nach 64Bit

[hubert5]

Stand: http://de.wikipedia.org/wiki/Big_Ball_of_Mud

Sorry, ich kann zwar C++ recht gut, aber nur brauche ich mal echt Hilfe von Euch. Uups, ihr wißt ja nicht, wer ich bin. Ein Stammuser, der hier oft hilft.

Die erste Zeile Code, die ich zu Gesicht bekam, sah so aus:
Zitat:

delete[] nUMKSt, AlbtPrgt, nPlgtkt, reorgt;

(Ist ja erstmal egal, bei Programmende gibt das BS den Speicher frei.)
Man fragte mich als "C++-Fachmann" (laut Lebenslauf), was die komische GCC-Warnung da soll.

Langsam kriegen wir Probleme damit, daß externe Libs nur noch in 64 Bit angeboten werden, von denen wir abhängen.

Die Codebase besteht fast nur aus C, vielleicht 10000 Dateien, zumeist unabhängig voneinander. NULL Doku und nicht selten Bezeichner wie oben. Fast alle sind zugleich als Prog aufrufbar und als DLL/so einbindbar, fast immer nur 2-3 Bildschirme voll Code. Helferprogramme für was, was man in Cobol nicht machen mag. Das Produkt lebt in Cobol. Es geht aber auch hoch bis zu Progs mit 500kB Sourcecode. Manchmal auch C++, auch zum Teil abhängig von ein paar fetten Libs wie http://xerces.apache.org/xerces-c/
Manche Brocken hat man sogar fremdprogrammieren lassen, und was soll ich sagen, auch NULL Doku, und keinen Zugriff mehr auf den Progger.

Wenn man nicht weiter weiß (also immer), flüchtet man sich in einen neuen Hype. Dank der starren Strukturen kommen Hypes aber erst 5-10 Jahre später an. Also XML zum Beispiel hat durchgeschlagen hier. Jetzt wird SCons eingeführt, ich vermute, ohne Bedarf. Und wenn eingeführt wie stets ohne Unternehmensinterne Doku, wie dann das Standardmakefile aussehen sollte/könnte (fast immer nur eine C-Datei). Neue Mitarbeiter rätseln mit jeder neuen benutzen "Technologie" ein halbes Wöchlein mehr.

Es besteht überhaupt kein Problem, nach C++ umzustellen, die strengeren Typprüfungen sind erwünscht. C++-Compiler ist ca Stand 2002.

Wie vorgehen?

Statisches Analysetool? Das wirft, fürchte ich, 500-mal mehr Fehler aus, als tatsächlich sinnvoll.

x=(int)lengthOfSqlStatement;
//Jup, alles klar, SqlStatement werden unter 1Mrd Zeichen bleiben.

//Davon und ähnliches heute viele gesehen.

Compiliert wird unter Win (MSVC), Linux(GCC) und AS/400(deshalb ca 2002).

Reimplemetieren kommt nicht in Frage. Die Sache funktioniert ja und wird fast wöchentlich so verkauft und viele Kunden kaufen zweimal im Jahr ein Update.

Bitte um Empfehlungen für Analysetools, die uns helfen könnten.

Oder andere Wege, wie man das packt.

Oder überhaupt Erfahrungsberichte zu 64Bit-Umstellungen. Andeutungen reichen, je mehr, desto besser. Ich zwirbele mir dann schon den Faden daraus.

[Nathan]

hubert5 schrieb:

Zitat:

delete[] nUMKSt, AlbtPrgt, nPlgtkt, reorgt;

(Ist ja erstmal egal, bei Programmende gibt das BS den Speicher frei.)
Man fragte mich als "C++-Fachmann" (laut Lebenslauf), was die komische GCC-Warnung da soll.

Das gibt Speicher frei, ja: von nUMKSt, der Rest ist Kommaoperator und macht gar nichts.

[manni66]

Du suchst jetzt ein Analysetool, das dir sagt, an welcher Stelle ein Problem bei der Umstellung auf 64 Bit entsteht?
Visual Studio hat da AFAIK eine Option. Ob man aber was findet zwischen den ganzen Warnungen bezüglich unsigned vs size_t?

[SeppJ]

Es ist ja nicht damit getan, einzelne Zeilen zu korrigieren. Die beiden Zeilen, die du uns gezeigt hast, werden ja nicht besser, wenn man die technischen Fehler korrigiert. Das Grundproblem ist, dass das Programm so entworfen ist, dass solche Zeilen überhaupt möglich und nötig waren.

Somit bleiben folgende Optionen, auf die du sicher auch gekommen bist, aber manchmal tut es gut, wenn einem jemand anderes noch einmal das offensichtliche erklärt:
1. Nichts tun.
2. Zumindest die einzelnen fehlerhaften Zeilen korrigieren, aber nicht die Architektur.
3. Nach und nach die Architektur refaktorn.
4. Neu schreiben.

Bleibt abzuwägen, was in deinem Fall das beste ist. 1. kommt kaum in Frage, dein Arbeitgeber will schließlich sehen, dass er was von dir hat. 2. ist wohl die bequemste Option. Nicht wirklich schwer für dich, es sieht so aus, als würdest du viel tun. Sichtbares Ergebnis: Compilerwarnungen verschwinden schnell. 3. Ähnlich wie 2, aber undankbarer. Langfristig für das Produkt besser, aber weniger sichtbare Ergebnisse für mehr Arbeit. Hohes Risiko, irgendwann versehentlich etwas falsch zu machen und dann bist du schuld mit deinem "neumodischen Quatsch". 4. ist weniger Arbeit als 3., aber ganz ohne sichtbare Ergebnisse und praktisch schon Garantie, dass es zu Anfang schlechter ist als das derzeitige Produkt. Außerdem weiß jeder, dass neue Entwickler immer zu allererst zu einer Neuentwicklung raten. Die sind bloß zu faul, sich in den bestehenden Code hinein zu arbeiten!

[hustbaer]

@Nathan
Ist das Ergebnis vom Kommaoperator nicht der Wert vom letzten Ausdruck?

[Finnegan]

Hi!

Neben den genannten Vorschlägen vielleicht noch eine Anregung, sofern es sich um ein datenbankartiges System mit Verarbeitung möglichst vieler Nutzereingaben im aktuellen Produktivbetrieb handelt:
Wenn praktikabel, nach erfolgreichem 64Bit-Build ein bisschen Blackbox-Testing - zweites System aufsetzen und parallel mit Live-Eingaben aus Produktivsystem füttern: dort, wo die Ausgabedaten dann irgendwann anfangen zu divergieren, hat man wahrscheinlich ein Problem mit der Portierung.
Das ist sicher nicht bei jedem System so machbar oder sinnvoll, und es sollte nicht die einzige Verifikation sein, aber vielleicht ist das ja eine geeignete Idee, die du noch nicht hattest

Finnegan

[otze]

In der Liste von SeppJ würde ich raten mit 2 anzufangen und dann langsam nach 3 überzugehen. Das kann ruhig zu Anfang sehr lokal sein, viele der Programme sind ja klein. Also hier mal ein array durch std::vector ersetzen, dort einen Variablennamen lesbar machen...und mit der Zeit sollte sich dann schon der Wald lichten. Je mehr der Wald sich dann lichtet, desto eher kannst du sehen, wo du mit der Axt mal ordentlich durchschlagen musst und das korrigierst du dann, wenn du Zeit hast - das kann auch ein partieller rewrite einer Komponente sein.

Das dauert natürlich und ist höchst unbefriedigend, das Endresultat könnte es aber wert sein.

[__cu]

hubert5 schrieb:

Statisches Analysetool? Das wirft, fürchte ich, 500-mal mehr Fehler aus, als tatsächlich sinnvoll.

ja, ist bei uns auch mit pclint so. Man eliminiert 99.9% überflüssige Meldungen und 1-mal pro Jahr wird ein echter Fehler entdeckt.

hubert5 schrieb:

Oder überhaupt Erfahrungsberichte zu 64Bit-Umstellungen. Andeutungen reichen, je mehr, desto besser. Ich zwirbele mir dann schon den Faden daraus.

Bei uns hat die Taktik, den unteren Speicherbereich vorzubelegen gut funktioniert. Dann crasht es sofort, wenn Pointer falsch gehandhabt werden.
Hier als Beispiel für die WinApi: https://randomascii.wordpress.com/2012/02/14/64-bit-made-easy/. Kann aber sicher auch mit gcc/linux umsetzen.

[hubert2]

__cu schrieb:

hubert5 schrieb:

Statisches Analysetool? Das wirft, fürchte ich, 500-mal mehr Fehler aus, als tatsächlich sinnvoll.

ja, ist bei uns auch mit pclint so. Man eliminiert 99.9% überflüssige Meldungen und 1-mal pro Jahr wird ein echter Fehler entdeckt.

Jo, habs befürchtet.

__cu schrieb:

Bei uns hat die Taktik, den unteren Speicherbereich vorzubelegen gut funktioniert. Dann crasht es sofort, wenn

Genial, danke!

[hubert2]

SeppJ schrieb:

Bleibt abzuwägen, was in deinem Fall das beste ist.

Deswegen bin ich hier.
Klar könnte Ihr nicht für mich abwägen, aber Euer Input ist mir viel wert.

SeppJ schrieb:

1. kommt kaum in Frage, dein Arbeitgeber will schließlich sehen, dass er was von dir hat.

So isses. Die Chefs haben viel Ahnung und wissen, daß es unmöglich ist, das einigermaßen reibungslos hinzukriegen. Deswegen wurde das auch recht vertagt, nehme ich an. Ich würde gern das Unmögliche packen. Zumal es für mich im Besonderen unmöglich ist als erstes Projekt dort.

SeppJ schrieb:

2. ist wohl die bequemste Option. Nicht wirklich schwer für dich, es sieht so aus, als würdest du viel tun. Sichtbares Ergebnis: Compilerwarnungen verschwinden schnell.

Als Nube kann ich wenig an der Architektur ändern.

SeppJ schrieb:

3. Ähnlich wie 2, aber undankbarer. Langfristig für das Produkt besser, aber weniger sichtbare Ergebnisse für mehr Arbeit. Hohes Risiko, irgendwann versehentlich etwas falsch zu machen und dann bist du schuld mit deinem "neumodischen Quatsch".

Das wirds's wohl. Nee, nur eine Mischung aus 2 und 3. Rohe Arrays ersezten durch array<>, eigenes ASSERT schreiben, das beim Entwickler hart abbricht oder in den Debugger geht und beim Kunden und in der QS-Abteilung (hat automatische Testsripts, aber noch weit weit von vollständiger Codeüberdeckung entfernt, leider) uns eine Mail schickt. Tools wie einen DirectoryIterator bereitstellen, der sich auf allen drei Plattformen gleich anfühlt, und Stück für Stück einbauen. Mit der Zeit alle #ifdefs nach Plattform im Anwender wegmachen und durch sich gleich anfühlende schlanke API-Wrapper ersetzen. Den neuen Kram dokumentieren! Breymann/Meyers/Sutter kaufen lassen und auslegen.

Hat jemand Erfahrungen, wie man sinnvollerweise sein Team hochbringt, ohne zu nerven? Dächte an einen festen Termin pro Woche, vielleicht 2h, wo ich was zu C++ und Softwareentwicklung labere, vielleicht Stück für Stück den Meyers durchgehe, vielleicht mal nette GotW-Sachen anspreche, WTFs (nach Absprache mit dem Autor) zerlege, Teilnahme freiwillig. Oder geht sowas gleich in die Hose, weil man sich nix sagen lassen will?

SeppJ schrieb:

4. ist weniger Arbeit als 3., aber ganz ohne sichtbare Ergebnisse und praktisch schon Garantie, dass es zu Anfang schlechter ist als das derzeitige Produkt.

Danke für die Zusammenfassung. Jo, so siehts wohl aus.
Wird hilfreich sein, Deinen Text dem AG zu zeigen.

[hubert2]

otze schrieb:

In der Liste von SeppJ würde ich raten mit 2 anzufangen und dann langsam nach 3 überzugehen. Das kann ruhig zu Anfang sehr lokal sein, viele der Programme sind ja klein. Also hier mal ein array durch std::vector ersetzen, dort einen Variablennamen lesbar machen...und mit der Zeit sollte sich dann schon der Wald lichten.

Klingt super. Abgesehen davon, daß von oben Ziele wie "Produkt goes mobile" mit Priorität reingehauen werden, was dafür sorgt, daß man kaum am Ball bleiben kann.

otze schrieb:

Je mehr der Wald sich dann lichtet, desto eher kannst du sehen, wo du mit der Axt mal ordentlich durchschlagen musst und das korrigierst du dann, wenn du Zeit hast - das kann auch ein partieller rewrite einer Komponente sein.

Klingt super. Abgesehen davon, daß jede Minute Arbeitszeit einer Kostenstelle zugeordnet werden muss, und immer genug Projekte auf der ToDo-Liste stehen und es deswegen keine Freizeit gibt. Ein Kernproblem des Unternehmens, deswegen auch keine Doku und an-die-wand-gefahrene Software. Das will und kann ich ändern, muss mich aber dazu schnell hochdienen, um Gehör zu finden.

[TyRoXx]

hubert2 schrieb:

Hat jemand Erfahrungen, wie man sinnvollerweise sein Team hochbringt, ohne zu nerven? Dächte an einen festen Termin pro Woche, vielleicht 2h, wo ich was zu C++ und Softwareentwicklung labere, vielleicht Stück für Stück den Meyers durchgehe, vielleicht mal nette GotW-Sachen anspreche, WTFs (nach Absprache mit dem Autor) zerlege, Teilnahme freiwillig. Oder geht sowas gleich in die Hose, weil man sich nix sagen lassen will?

Das hängt von den Leuten ab, mit denen du es zu tun hast. Wenn die ein wenig einsichtig sind, kann so ein Termin sinnvoll sein. Du solltest aber keine Wunder erwarten. Keiner von denen wird durch noch so viele Treffen auf dein Niveau kommen. Programmieren (wie alles andere nicht-triviale) kann man sich nur selbst beibringen aus eigenem Antrieb. Du kannst höchstens Schadensbegrenzung betreiben.

[Marthog]

hubert2 schrieb:

Hat jemand Erfahrungen, wie man sinnvollerweise sein Team hochbringt, ohne zu nerven? Dächte an einen festen Termin pro Woche, vielleicht 2h, wo ich was zu C++ und Softwareentwicklung labere, vielleicht Stück für Stück den Meyers durchgehe, vielleicht mal nette GotW-Sachen anspreche, WTFs (nach Absprache mit dem Autor) zerlege, Teilnahme freiwillig. Oder geht sowas gleich in die Hose, weil man sich nix sagen lassen will?

Wenn jemand mit der Einstellung "Wir haben das schon immer so gemacht und alles neue ist unnoetig" dabei ist, hast du keine Chance.

[MichelRT]

Marthog schrieb:

Wenn jemand mit der Einstellung "Wir haben das schon immer so gemacht und alles neue ist unnoetig" dabei ist, hast du keine Chance.

Solche hat man immer dabei. Du musst den Abteilungsleiter und die "Zugpferde" der Abteilung auf Deine Seite ziehen.

[Hi]

hustbaer schrieb:

@Nathan
Ist das Ergebnis vom Kommaoperator nicht der Wert vom letzten Ausdruck?

Ja, aber http://de.cppreference.com/w/cpp/language/operator_precedence

[hustbaer]

Hi schrieb:

hustbaer schrieb:

@Nathan
Ist das Ergebnis vom Kommaoperator nicht der Wert vom letzten Ausdruck?

Ja, aber http://de.cppreference.com/w/cpp/language/operator_precedence

Ah,
Danke!

[hustbaer]

@hubert2
Ich sag mal es wird vermutlich darauf hinauslaufen Stück für Stück zu entscheiden was man macht.

Teile werden mehr oder weniger OK sein, die übernimmt man erstmal 1:1, andere Teile werden kleinerer Reparaturen bedürfen, die repariert man dann halt, und andere Teile wird man gröber refactoren bis u.U. ganz neu schreiben müssen.

Wo ich SeppJ zustimme: neu Schreiben geht schneller als einen Ball of Mud sukzessive, in mehreren Runden zu refactoren bis alles halbwegs OK ist.

Geht allerdings nur wenn man "die Spec" entweder hat (interne Doku, sehr genaues und gut gewartetes Benutzerhandbuch, ...), leicht aus dem bestehenden Code rauslesen kann oder neu erfinden darf.
Wo das nicht geht muss man mit Refactoring ran, um den Code erstmal soweit kennen zu lernen und aufzuräumen dass man rauslesen kann was er eigentlich tut. Was hoffentlich nicht weit von dem entfernt ist was es tun soll.

Und weil du nach Tools gefragt hast:
Ich würde mal die Clang Sanitizer drüber lassen. Soweit ich weiss sind die speziell darauf optimiert keine false positives zu melden.

http://clang.llvm.org/docs/index.html
Da euer Code mit GCC baut, sind die Chancen denke ich gut dass er ebenfalls mit Clang baut.