Produktpflege in Softwareunternehmen

g. k. schrieb:
> Im Prinzip ist das, was du beschreibst leider häufig der Standard in
> Unternehmen und das unabhängig von der Größe. Bei größeren Firmen sind
> es halt 10-20 Mann Abteilungen, die ihre Süppchen kochen (so ist es bei
> uns leider :().

Das kann ich so bestätigen.

Hermann schrieb:
> Neben dem Wachstum ist auch ein anderes Problem, dass keine neuen
> Technologien verwendet werden. Eines unserer Produkte hat z.B. eine
> Weboberfläche die noch auf dem Stand von vor 15 Jahren ist.
> Einen Technologieschwenk durchzuführen ist aber schwierig, da ja alle
> 1000 Anpassungen der Bestandskunden mit auf die neue Technologie
> migriert werden müssten.

Es macht selten Sinn, wegen einer neuen Technologie das ganze Produkt 
neu zu entwickeln. Wenn man schon von vorne beginnt, setzt man erst 
einmal nur eine Minimalversion um, und zieht Kundenfeatures bei Bedarf 
nach. Da stellt man nicht selten fest, dass viele Features gar nicht 
mehr gebraucht werden.

Es wäre unrealistisch zu denken, dass alle Kunden auf das neue Produkt 
umsteigen wollen.

Idealerweise entwickelt man aber wirklich ein neues Produkt, welches 
vielleicht auch neue Kunden erschließt.

Hermann schrieb:
> Auch ich musste mich dann immer wieder dem „Tagesgeschäft“ widmen, da
> dies ja die Kohle reinbringt.

Das ist langfristig eine sehr gefährliche Unternehmensstrategie. Wenn 
man überhaupt keine Ressourcen für Vorentwicklung freimachen kann, ist 
das eine Fehlplanung, wenn auch eine sehr beliebte Form davon.

Ich will das mit den Technologien nochmal konkretisieren:

Eines unserer Kernprodukte (eine Steuerungslösung) wird seit 25 Jahren 
immer weiter entwickelt. Unter der Haube wird aber noch nicht einmal 
objektorientiert gearbeitet.
Die zuständigen Entwickler sind auch schon ein wenig älter und auch 
nicht wirklich daran interessiert, hier noch vor der Rente etwas dran zu 
ändern.

Bei diesem Produkt ist meiner Meinung nach eine komplette Neuentwicklung 
erforderlich, da der aktuelle Stand, vor allem für die jüngeren 
Kollegen, nicht mehr Wartbar ist.

Das Problem ist allerdings, dass für den Endkunden diese Neuentwicklung 
keine Vorteile bringt, da die alte Lösung sehr stabil läuft.
Man muss alle bestehenden Features unterstützen, da erwartet wird das 
ein neues Produkt mindestens das kann, was das alte leistet.
Sicherlich werden einige Funktionen rausfliegen können, da sie nicht 
mehr gebraucht werden. Jedoch ist der Entwicklungs Aufwand enorm einen 
Mindestumfang neu aufzubauen.

Eventuell bin ich ja mit meinem 8 Jahren Berufserfahrung noch zu naiv... 
Oder ich muss mir einen anderen Arbeitgeber suchen.

Interessiert mich halt, ob es bei anderen besser läuft. Man will ja 
nicht vom Regen in die Traufe kommen.

Hermann schrieb:
> Bei diesem Produkt ist meiner Meinung nach eine komplette Neuentwicklung
> erforderlich, da der aktuelle Stand, vor allem für die jüngeren
> Kollegen, nicht mehr Wartbar ist.

Muss aber. Ist eine Frage der Einarbeitung.

Es gibt durchaus Ansätze, wie man ein Altprodukt besser wartbar machen 
kann und wie man Erweiterungen in einer neueren Technologie umsetzt.

Dokumentation kann man übrigens auch nachträglich erstellen.

Hermann schrieb:
> Das Problem ist allerdings, dass für den Endkunden diese Neuentwicklung
> keine Vorteile bringt, da die alte Lösung sehr stabil läuft.

Dann bezahlt auch keiner ein neues, instabiles Produkt.

Hermann schrieb:
> Man muss alle bestehenden Features unterstützen, da erwartet wird das
> ein neues Produkt mindestens das kann, was das alte leistet.

Deshalb muss das neue Produkt auch neu sein und nicht einfach eine Kopie 
des Altproduktes.

Hermann schrieb:
> Eines unserer Kernprodukte (eine Steuerungslösung) wird seit 25 Jahren
> immer weiter entwickelt. Unter der Haube wird aber noch nicht einmal
> objektorientiert gearbeitet.

Wozu auch ?

OO sollte die Erstellung erleichtern.

Die Programme sind aber schon erstellt.

Daß OO die Anpassbarkeit verbessert, ist nur Theorie. Ein Produkt wie 
das eure, das 15 Jahre erfolgreich angepasst werden konnte, hat 
bewiesen, daß es anpassbar ist. OO stört da nur.

Hermann schrieb:
> Eines unserer Produkte hat z.B. eine
> Weboberfläche die noch auf dem Stand von vor 15 Jahren ist

Funktioniert vermutlich auf allen Browsern und muss nicht mal hässlich 
aussehen.
Deine "moderne" wird nicht überall funktionieren und vermutlich mehr 
Daten transportieren, also langsamer sein.
Wo ist da der Fortschritt ?

Nutze die Technologie, die das Problem löst, und selberverliebe dich 
nicht in eine Technologie.

Hermann schrieb:
> Eventuell bin ich ja mit meinem 8 Jahren Berufserfahrung noch zu naiv...
> Oder ich muss mir einen anderen Arbeitgeber suchen.

Eine praktikablere Denkweise. Dinge sind nicht schlecht, bloss weil sie 
vor dir erfunden wurden. Es gibt elegant geschriebene C Programme und 
elegant geschriebene C++ Programme und wenn beide dasselbe leisten, 
werden beide auch ungefähr dieselben Maschinenbefehle auf dem Prozessor 
ausführen, nämlich genau die, die nötig sind, um das Problem zu lösen.
Und es gibt schlechte C und schlechte C+++ Programme. Unnötig komplex, 
unübersichtlich, und womöglich noch fehlerhaft. Die Technologie sagt 
also nicht, was es taugt.

Gibt es eigentlich geführte Statistiken darüber auf welcher Codebasis, 
welchen Tools Software in mittelständischen Unternehmen beruht? Es wird 
doch sonst immer gerne alles mögliche statistisch erfasst und 
ausgewertet.

Ich weiß von einem Bekannten aus einem Großunternehmen (Chemie), dass 
zumindest ein Teil der dort älteren Laborrechner noch bis vor kurzem mit 
Windows 3.11 liefen (kein Witz!) einschließlich MS-DOS Programme. 
Desweiteren hatten sie viele Rechner mit XP. Zuletzt wurde von der 
IT-Abteilung verstärkt Win7 angeschafft.

MaWin schrieb:
> Nutze die Technologie, die das Problem löst, und selberverliebe dich
> nicht in eine Technologie.

Ja, ist ja alles richtig was du sagst. Das OO besser ist, war ja auch 
nur ein Beispiel.

Das Problem, über das wir bei uns fallen ist aber meistens, dass unsere 
Software zur Unterstützung von Hardware vor 25 Jahren entwickelt wurde. 
Diese Hardware wurde über bestimmte Befehlssätze angesprochen. Heute 
müssen wir ganz andere Hardware unterstützen, die bei der Ansteuerung 
komplett andere Ideen verfolgt.
Da der Hauptteil aber nicht allzu flexibel ist, muss der Befehlssatz der 
neuen HW immer in das "Korsett" des alten Befehlssatzes gequetscht 
werden.

Man muss also immer kompatibel zu dem alten Kram sein, wodurch die 
Entwicklungsszeit verlängert wird, man sich einschränkt und viele Bugs 
auftreten.

Die "alte" Hardware gibt es übrigens auch gar nicht mehr im Markt, d.h. 
man könnte im Rahmen einer Produktpflege die alten Zöpfe abschneiden.

Hallo Hermann,

pass mal auf was passiert, wenn einer von den "alten" Softwarentwicklern 
vorzeitig aus dem Leben scheidet. Dann bist Du garantiert glücklich eine 
vernünftige Dokumentation zu haben und wirst nicht überrascht von 
seltsamen Codekonstrukten und ähnlichem.

War auch grad mal in ner Firma mit uralt SW aus den Neunzigern. 
Hunderttausende Zeilen C, jeden Tag wurde gebugfixt oder etwas neues kam 
dazu. Das hatte schon lange kein System mehr.
einem kam die Idee, alles auf C++ umzumodeln, vergiss es. dieses Moloch 
war schon über ein Jahrzehnt beim Kunden und es wurde immer wieder etwas 
geändert.
am besten wäre es gewesen, den Code in C zu lassen, zu refactoren und 
mal aufzuräumen, bereinigen.
wenn man mal in File xy.c auf Zeile :3458 im vi etwas anpassen muss, wo 
der letzte mal im Jahre 1998 einen ironischen Kommentar zu ner Funktion 
reingehackt hat, und noch ein paar If Schleifen drum herum in die 
Funktion inkl. irgendwelchen Pointern fragt man sich schon nach dem 
Sinn..

klausi schrieb:
> wenn man mal in File xy.c auf Zeile :3458 im vi etwas anpassen muss

Wow, gut dass du den vi erwähnt hast, jetzt denken alle hier du bist 
voll der üble Hacker und Vollprofi!

Nur Leider passt
> und noch ein paar If Schleifen drum herum
da nicht so ganz...
http://www.if-schleife.de/

Hermann schrieb:
> Das Problem, über das wir bei uns fallen ist aber meistens, dass unsere
> Software zur Unterstützung von Hardware vor 25 Jahren entwickelt wurde.
> Diese Hardware wurde über bestimmte Befehlssätze angesprochen. Heute
> müssen wir ganz andere Hardware unterstützen, die bei der Ansteuerung
> komplett andere Ideen verfolgt.
> Da der Hauptteil aber nicht allzu flexibel ist, muss der Befehlssatz der
> neuen HW immer in das "Korsett" des alten Befehlssatzes gequetscht
> werden.

Das heißt es wäre vorrangig erst einmal nötig einen neuen Kern oder eine 
Schnittstelle zu schaffen, die zwischen der alten Welt und einer neuen 
Welt vermitteln kann. Dann kann man neuen Code in der neuen Welt 
schreiben und alten Code bei Bedarf nach und nach portieren.

Ob und wie das in deinem konkreten Fall funktionieren kann, kann man 
ohne Blick auf den Code nicht sagen.

> Was kein Nachteil sein muss. Es reicht(e), wenn es halbweg strukturiert
> und mit einem guten Grundkonzept ausgestattet ist.

Das krasseste Beispiel ist eine(!!!) Datei mit mittlerweile 25.000 
Zeilen C-Code (inkl. Kommentar).
Ich übertreibe nicht!

Da ist ein Zustandsautomat mit switch-case implementiert. Schon die 
Variablendeklaration nimmt hunderte Zeilen ein.

Keiner hat hier mehr den Durchblick, wann der Automat in welchen Zustand 
springt, da Ballast von langer Zeit mitgeschleppt wird.
Die Folgezustände hängen natürlich von diversen kundenspezifischen 
Parametern  ab. Jede Änderung kann hier bedeuten, dass andere Sachen 
nicht mehr funktionieren.

So einen Zustandsautomaten kann man auch nicht in überschaubarer Zeit 
testen.

Dieser Molloch ist tatsächlich gespickt mit Kommentaren von 1998, 
geschrieben von Mitarbeitern die seit 10 Jahren nicht mehr im 
Unternehmen arbeiten.

> Wollen sie es nicht, weil es nicht cool und hipp ist, oder können sie es
> technisch WIRKLICH nicht?

Ich glaube nicht, dass das was mit hipp oder cool zu tun hat...

Man will diesen Haufen am liebsten nicht anfassen. Aber um Kundenwünsche 
zu erfüllen, wird jeder Wunsch da irgendwie mit Biegen und Brechen 
eingebaut. In der Hoffnung, dass keine Seiteneffekte auftauchen.

Ben schrieb:
> Wow, gut dass du den vi erwähnt hast, jetzt denken alle hier du bist
> voll der üble Hacker und Vollprofi!
>
> Nur Leider passt
>> und noch ein paar If Schleifen drum herum
> da nicht so ganz...
> http://www.if-schleife.de/

Jo mei, kack dich nicht ins Hemd. Was interessiert mich heute mein K.ck 
von gestern.  sind auch genug while loops eingebaut.
und ja, in vi bin ich mittlerweile Profi, da können mir so Anfänger Ings 
nichts mehr erzählen.
Hab schon in schlechtester Molloch Software mit C Files mit Tausenden 
LOC Code gefixt und dazugebaut, das entzieht sich natürlich deinen 
Vorstellungen. Genauso wie unser Kollege Hermann da.

Hermann schrieb:
> Das krasseste Beispiel ist eine(!!!) Datei mit mittlerweile 25.000
> Zeilen C-Code (inkl. Kommentar).
> Ich übertreibe nicht!
>
> Da ist ein Zustandsautomat mit switch-case implementiert. Schon die
> Variablendeklaration nimmt hunderte Zeilen ein.
>
> Keiner hat hier mehr den Durchblick, wann der Automat in welchen Zustand
> springt, da Ballast von langer Zeit mitgeschleppt wird.

krass!
Genau solche Probleme hatte ich in meinem letzten Job. Uralt Moloch C 
Files ;-)
Evtl gleiche Firma?! Arbeitest du in ner Automations-Firma?

P. M. schrieb:
> In der Wartung eines Maschinenparks oder in der Finanzabteilung
> ist völlig klar, dass man sauber und nachhaltig arbeiten muss und das
> "Feuerwehr-Prinzip" nichts verloren hat.

Das (klar) ist es in der SW-Entwicklung auch.

Gerade in den Finanzabteilungen und Banlen vermute ich hohes "kreatives" 
Potential, wo im Fall des Falles Heerscharen "forensischer Buchhalter" 
Monate/Jahrelang nach dem Geld suchen (müssen).

klausi schrieb:
> krass!
> Genau solche Probleme hatte ich in meinem letzten Job. Uralt Moloch C
> Files ;-)
> Evtl gleiche Firma?! Arbeitest du in ner Automations-Firma?

Ja, auch in der Automation. Ich nenne jetzt aber keine Namen...

Ich bin ja auch an sich zufrieden mit meinem Job, Bezahlung ist super, 
usw.
Ich frage mich nur, wie die beiden Inhaber da ruhig schlafen können.

Das Problem ist vllt. auch die Branche. Den Kunden interessiert nicht, 
ob hinter den sichtbaren Teilen ein Riesen Chaos herrscht. Hauptsache es 
funktioniert wie er will.
Daher gibt es nie Kundengetriebenen Bedarf etwas zu ändern.

Irgendwann hat ein potentieller Kunde mal gefragt, ob seine 
SW-Entwicklung auch eigene Teile einbauen könnte. In diesem Zusammenhang 
wollte er natürlich wissen, ob die Struktur flexibel ist. "Klar, alles 
OOP und super einfach".
Intern hieß es dann: "wenn der Auftrag kommt, müssen wir alles schnell 
komplett neu machen".

Hermann schrieb:
> Ich frage mich nur, wie die beiden Inhaber da ruhig schlafen können.

Wer weiß, ob die Inhaber überhaupt für die Ewigkeit planen? Wenn der 
Laden schon 25 Jahre läuft, haben die ganz sicher ausgesorgt.

Unruhig schlafen wäre nur angebracht, wenn es Probleme mit 
Produkthaftung gibt. Aber es klingt ja nicht so, als wäre Euere Software 
instabil und gefährlich.

Hallo,

vielleicht gibt es hier einen Zusammenhang?

> Kurze Reaktionszeiten auf Kundenwünsche
> Hohe Flexibilität, d.h. wir können in der Regel alle Kundenwünsche
> erfüllen
> Gute Preise im Vergleich zu größeren Mitbewerbern

vs.

> Wir haben aber
> keine Ressourcen, um die Umsetzung voranzutreiben, so dass die Projekte
> wieder einschlafen.


EinfacheRegel: Es wird nur investiert, wenn aus diesem Invest ein 
entsprechend hoher Gewinn erzielt werden kann.

Hermann schrieb:
> Das krasseste Beispiel ist eine(!!!) Datei mit mittlerweile 25.000
> Zeilen C-Code (inkl. Kommentar). Ich übertreibe nicht!

Du bist noch ein Kindergartenkind, 28000 Zeilen sind nichts
(und immerhin sind sie in 1 Datei, stell dir vor es wären 100 Dateien a 
280 Zeilen, spiecht jeweils ein case)
wer da schon den Überblick verliert, ist für Softwareentwicklung 
untauglich. 1 Mio Zeilen sind handelsüblich.

> Da ist ein Zustandsautomat mit switch-case implementiert. Schon die
> Variablendeklaration nimmt hunderte Zeilen ein.
>
> Keiner hat hier mehr den Durchblick, wann der Automat in welchen Zustand
> springt, da Ballast von langer Zeit mitgeschleppt wird.

Glaubst du, das wird besser, wenn du den Automaten in Tabelle und Code 
trennst ?

Es liegt eher an dir, wenn du da erwartest, daß es einfacher wird, wenn 
es neu entwickelt wird.

Es wird gar nicht funktionieren, weil dir Projekte der Komplexität 
offenbar zu gross sind.

Der Zustandsautomat ist vermutlich eine effektive Lösung, und egal ob 
als case oder als Tabelle: Die kundenspezifischen Wünsche werden drin 
bleiben müssen. Eine Dokumentation würde auch nicht helfen, denn wer 
will kontrollieren, ob der Automat der Dokumentation entspricht ? Das 
gibt Redundanzprobleme. Kommentiert ist es offenkundig auch.

Mir scheint, das Problem liegt eher bei Dir. Du bist überfordert.

Natürlich spricht nichts dagegen, gewachsenen Code aufzuräumen. 
Vielleicht gibt es ja Kudnenwünsche, für die es schon lange keinen 
Kunden mehr gibt. Vielleicht gibt es code, der zu 
Zukunftserweiterbarkeit angelegt wurde, der nie verwendet wurde sondern 
nur den Blick aufs Wesentliche versperrt. Vielleicht gibt es Strukuren, 
die nicht universell genug waren und geflickt wurden, die man besser 
strukturieren könnte. Aber alles mit Augenmass, und dazu muss man nicht 
erst mal alles wegschmeissen und neu machen.

MaWin schrieb:
> Du bist noch ein Kindergartenkind, 28000 Zeilen sind nichts
> (und immerhin sind sie in 1 Datei, stell dir vor es wären 100 Dateien a
> 280 Zeilen, spiecht jeweils ein case)
> wer da schon den Überblick verliert, ist für Softwareentwicklung
> untauglich. 1 Mio Zeilen sind handelsüblich.

Ich verstehe nicht warum du so aggro hier reagierst. Gut das du der 
Mega-Hero bist, der den ganzen Tag in 1 Mio Zeilen Code navigiert.

Es gibt halt auch genug Leute die ihren Code nicht ordentlich 
strukturieren um sich unabkömmlich zu machen.

Ich habe schon in anderen Firmen gearbeitet, da wurden solche Probleme 
wesntlich eleganter in OOP (z.B. State Pattern) gelöst.
Die einzelnen Zustände waren sauber abgegrenzt und mind. zu 70% mit 
Testcases abgedeckt.

Ingesamt gibt dass dann auch viel Code, aber in übersichtlichen 
Strukturen.


> Es liegt eher an dir, wenn du da erwartest, daß es einfacher wird, wenn
> es neu entwickelt wird.
>
> Es wird gar nicht funktionieren, weil dir Projekte der Komplexität
> offenbar zu gross sind.

Klar... daran wirds liegen. Ich bin dumm und MaWin hat voll den 
Mega-Durchblick.

Ich habe mich hier nicht beklagt. Ich habe hier lediglich nach 
Erfahrungen aus anderen Unternehmen gefragt. Es interessiert mich, ob 
andere es anders machen oder ob so eine Arbeitsweise Standard ist.

Ich weiß nicht, warum MaWin hier so assozial reagiert? Wie kannst man 
aus der Ferne diagnoszizieren, ob ich überfordert bin oder nicht.

Hallo MaWin,

MaWin schrieb:
> OO sollte die Erstellung erleichtern.
>
> Die Programme sind aber schon erstellt.
>
> Daß OO die Anpassbarkeit verbessert, ist nur Theorie. Ein Produkt wie
> das eure, das 15 Jahre erfolgreich angepasst werden konnte, hat
> bewiesen, daß es anpassbar ist. OO stört da nur.

Kann es sein, daß Du selbst nicht besonders viel Erfahrung mit OO hast?

Liebe Grüße,
Karl

Hermann schrieb:
> Ich weiß nicht, warum MaWin hier so assozial reagiert? Wie kannst man aus
> der Ferne diagnoszizieren, ob ich überfordert bin oder nicht.

Sieht man schon an deiner Rechtschreibung, asozial und diagnostizieren 
bitte.

War doch einfach, du selbst sagst, du schaffst nicht den Überblick über 
ein kleines Programm zu bekommen.

Karl Käfer schrieb:
> Kann es sein, daß Du selbst nicht besonders viel Erfahrung mit OO hast?

Ich hab sogar dasselbe Programm in konventionell und OO hier. Immerhin 
gleich schnell aber 10 mal grösser und entsprechend unübersichtlicher.

Schade, der Anfang vom Thread war sehr interessant. Das ist ein Problem, 
vor dem viele stehen. Uralte, schlecht oder erst gar nicht dokumentierte 
Software, welche im Laufe der Jahre durch ständige Änderungen & 
Anpassungen noch unübersichtlicher geworden ist.

Aber Ihr schlagt wieder einfach nur gegenseitig aufeinander ein....
Schade! Schade! Schade!

Das hätte mal ne wirklich interessante Sache werden können. Aber naja,
so sind die Leute! Schade!

Hallo MaWin,

MaWin schrieb:
> Karl Käfer schrieb:
>> Kann es sein, daß Du selbst nicht besonders viel Erfahrung mit OO hast?
>
> Ich hab sogar dasselbe Programm in konventionell und OO hier. Immerhin
> gleich schnell aber 10 mal grösser und entsprechend unübersichtlicher.

Eigentlich ist die Objektorientierung ein Werkzeug, um Code besser zu 
strukturieren -- also um ihn übersichtlicher, lesbarer, wartbarer und 
wiederverwendbarer zu machen. Wenn das bei dem Code, der Dir angeblich 
vorliegt, hat daher entweder der Autor etwas falsch gemacht -- oder Du 
verstehst den Code einfach nicht.

Liebe Grüße,
Karl

Hallo Hermann,

Hermann schrieb:
> Ich verstehe nicht warum du so aggro hier reagierst. Gut das du der
> Mega-Hero bist, der den ganzen Tag in 1 Mio Zeilen Code navigiert.

verzeih', aber ich fürchte, daß dies nicht ganz der richtige Ort für 
Deine Frage ist. Hier wird noch mit quasireligiöser Inbrunst darum 
gefochten, ob Mikrocontroller am Besten in Assembler, C, Basic oder 
Pascal programmiert werden, und wenn Begriffe aus der modernen 
Softwareentwicklung wie OO, C++, Testgetriebene Entwicklung oder 
Kontinuierliche Integration fallen, ist leider regelmäßig der Teufel 
los.

Leider ist es nicht ganz einfach, einem Schlips zu erklären, warum er 
Zeit und Geld in die Entwicklung von Funktionalität investieren soll, 
die er vermeintlich bereits hat. Daß derlei Unkenntnis und / oder 
Unverständnis leider auch bei Technikern vorkommt, vornehmlich bei den 
"gestandenen" die nichts Neues mehr lernen wollen oder können, kannst Du 
leider auch wieder hier in diesem Thread sehen. Oft versuchen solche 
Leute ihre Unsicherheit durch ein betont aggressives und provokatives 
Auftreten zu überspielen, aber davon solltest Du Dich nicht verunsichern 
lassen. ;-)

Im Unternehmen erschwert auch das die Sache mit den Schlipsen, denn im 
Zweifelsfalle hast Du gerade in Unternehmen Eurer Größe eine Reihe von 
Leuten, die wie Glucken auf ihrem Code sitzen und ihn als Garantie ihres 
Arbeitsplatzes verteidigen. Die sind dann oft schon lange im 
Unternehmen, gelten als fähig (meist, weil sie das vor längerer Zeit 
auch tatsächlich einmal gewesen sind), und flüstern dem Schlips ein, daß 
er dieses ganze neumodische Teufelszeug nicht braucht. Wie würdest Du 
dann an Schlipses Stelle entscheiden, gegen den jungen Neuling mit den 
Flusen im Kopf oder gegen Deine alteingesessenen, verläßlichen 
Mitarbeiter?

Aber laß' Dich nicht entmutigen. Nach meiner ganz persönlichen Erfahrung 
ist es viel öfter sinnvoll, bestehende Software mit modernen 
Technologien neu zu bauen, als gemeinhin angenommen wird. Oft ist es 
auch kurzfristig einfacher und billiger, als vorher angenommen wird, 
denn im vorhandenen Code hat man ja schon viele Probleme gelöst und muß 
diese Lösungen dann nur noch übertragen, statt sie vollständig neu 
entwickeln zu müssen.

In Fällen wie dem von Dir geschilderten empfehle ich meistens, zuerst 
für den vorhandenen Code so etwas wie Unittests zu entwickeln. Das hilft 
nicht nur bei der Pflege der vorhandenen Codebasis, die ja mindestens so 
lange weitergepflegt werden muß, bis Ersatz bereit steht. Solche 
automatisierten Tests helfen aber auch bei der Entwicklung von neuem 
Code, der den alten ersetzen soll und so schon während der Entwicklung 
getestet werden kann.

Für die Schlipsdiskussion kann es sinnvoll sein, sich ein paar besonders 
unschöne Stellen im Code herauszupicken. Dabei ist es wichtig, daß diese 
Stellen häufiger Probleme machen und es bekannt ist, daß sie sehr schwer 
zu warten sind. Der erste Schritt ist nun, den Schlips zu überzeugen, 
Dir ein wenig Arbeitszeit dafür zu bewilligen, Tests für diese 
Codestellen zu entwickeln, um die bekannten Probleme besser vermeiden zu 
können. Wenn Du Lösungen für Probleme anbietest, die der Schlips schon 
kennt, findest Du dort normalerweise ein offenes Ohr.

Wenn Du dann bewiesen hast, daß Deine Methoden funktionieren und bei der 
Entwicklung nützlich sind, kannst Du darum bitten, eine oder zwei dieser 
Codestellen mit modernen Methoden zu reimplementieren. Dabei solltest Du 
versuchen, die Alteingesessenen mitzunehmen -- nicht nur wegen ihrer 
über Jahre hinweg erworbenen Detailkenntnisse, sondern auch, um von 
nicht als Bedrohung ihres Arbeitsplatzes wahrgenommen zu werden.

Du siehst: solche Prozesse sind langwierig, nicht wegen ihrer 
technischen, sondern wegen ihrer sozialen Natur. Da mußt Du abwägen: 
hast Du die Zeit und die Lust, Deine Energie in solche Prozesse zu 
investieren und Deine Vorgesetzten und Kollegen davon zu überzeugen? 
Wenn ja, viel Spaß. Wenn nein, suchst Du Dir vielleicht wirklich besser 
einen anderen Job.

HTH,
Karl

Karl Käfer schrieb:
> Wenn das bei dem Code, der Dir angeblich vorliegt, hat daher entweder
> der Autor etwas falsch gemacht -- oder Du verstehst den Code einfach
> nicht.

Natürlich.

Wenn die Welt nicht so ist, wie du sie dir wünscht, muss der Fehler bei 
den anderen liegen.

Mein Leben besteht aus Erfahrungen, vielen davon, über Jahre.

Ich schrieb schon oben, dass man konventionell und in OO übersichtliche 
und unübersichtliche Programme schreiben kann. Es liegt nicht an der 
Technologie, ich habe hier sogar einen Haufen Lehrbeispiele in GOTO 
BASIC die übersichtlich sind.

Ich weiss aber, dass die meisten kommerziellen Programme unübersichtlich 
werden, egal ob konventionell oder OO, weil sie immer in Richtungen 
hingebogen werden, die nicht gedacht waren. Es liegt nicht an zu wenig 
Zeit/Geld, sondern überforderten Leuten und miesen Rahmenbedingungen 
"wir sagen ihnen was es werden soll wenn es fertig ist".

Die sauberen Programme die ich kenne sind alles kleine Projekte bei 
denen zu Beginn die Definition klar vorlag und die nach Fertigstellung 
schlicht funktionierten und nicht mehr erweitert wurden. Sogar CP/M ist 
überraschend übersichtlich.

Es ist ein absoluter Irrtum, zu glauben, mit OO werde alles 
übersichtlicher. Meine Erfahrung sagt: Das Gegenteil ist der Fall. Auch 
daran erkennbar, dass OO Programme i.A. viel langsamer dafür aber 
resourcenfressender sind. Das passiert ja nicht freiwillig, sondern weil 
der Programmierer nicht mehr überschaut, was zur Lösung des Problems 
nötig und angemessen ist.

> Es liegt nicht an zu wenig
> Zeit/Geld, sondern überforderten Leuten und miesen Rahmenbedingungen
> "wir sagen ihnen was es werden soll wenn es fertig ist".
>

Klar, die Leute haben Schuld. Wir sind allesamt dumm und unfähig.

Mal ein typisches Beispiel aus unserem Projektalltag:

Vertrieb kommt mit Auftrag rein. Fertigstellungsdatum? Am besten Sofort! 
Nicht mehr als eine Woche Zeit, obwohl mehrere Wochen veranschlagt 
werden.
Anforderungen unklar. Wirklich testbar, wegen verschiedenster 
Schnittstellen, nur in Kundenumgebung.
Dann muss erstmal drauflos gearbeitet werden, "nach besten Wissen und 
Gewissen".

Eine Woche später soll das ganze dann beim Kunden installiert werden. 
Weil keiner weiß, ob das funktioniert wird der Vetrieb und das 
Produktmanagement natürlich von einem oder mehreren Entwicklern 
begleitet.

Wenn man gut gearbeitet hat, funktioniert fast alles. Vllt noch ein paar 
kleiner Bugs entfernen.

Aber das ganze ist anders als der Kunde wollte. Der Entwickler bekommt 
dann die Aufgabe, das hinzubiegen. Obwohl es gar nicht gewünscht war und 
nicht in das vom Entwickler gebaute Konzept passt.

Flug geht um 19:30, schnell noch irgendwie einbauen bis der Kunde 
zufrieden ist und ab nach Hause: "Zuhause machen wir das dann nochmal 
ordentlich!".

Zuhause stehen andere Projekte an, also wird es nie ordentlich gemacht, 
weil keine Zeit (und kein Geld) dafür zur Verfügung steht.

Da kann meiner Meinung nach der beste Entwickler nichts für. Außer er 
setzt sich in seiner Freizeit hin und ordnet den Code.




> Die sauberen Programme die ich kenne sind alles kleine Projekte bei
> denen zu Beginn die Definition klar vorlag und die nach Fertigstellung
> schlicht funktionierten und nicht mehr erweitert wurden. Sogar CP/M ist
> überraschend übersichtlich.
Hier muss ich zustimme.

Hermann schrieb:
> Da kann meiner Meinung nach der beste Entwickler nichts für.

Ja.

Ich meine ja auch mit dem Satz

> "wir sagen ihnen was es werden soll wenn es fertig ist".

dass die Spezifikation vom Auftraggeber leider oft erst kommt,
wenn das Produkt nach Zeitplan schon fertig sein soll.

Das war vielleicht missverständlich formuliert. Der Auftraggeber ist 
schuld mit Zeitplan und Unklarheiten.

Guten Tag,

also bei uns hat es schon viel geholfen die Projekte in eine ordentliche 
Code Verwaltung zu überführen. Aktuell verwenden wir z.B. Git mit einem 
Verwaltung dazu.
Damit hat man zwar nicht den alten Kram dokumentiert, aber neue 
Änderungen werden schon mal sauber dokumentiert und wenn man darauf 
achtet das die Commits ordentlich beschrieben sind, weis man zumindest 
bei den letzten Änderungen was der Sinn war, selbst wenn jemand im Code 
nicht dokumentiert.
Ist ein überschaubarer Schritt, hilft aber schon mal ganz gut.

Bezüglich der Neuentwicklung, ist deine Beschreibung mit den Hardware 
Problemen schon eher kritisch, finde ich zumindest.
Aber da hilft es oft wenn man etwas neu baut und die Hardware günstiger 
wird und man ein paar neue Features hat, die die Leute gebrauchen 
können. Wenn man einige, für die Kunden, interessante Features hat haben 
meist auch die Entscheidungsträger ein großes Interesse an der 
Neuentwicklung, da wie schon beschrieben, man damit teilweise auch neue 
Kunden anziehen kann.

Irgendwie hat Entwicklung heute immer weniger mit richtiger Entwicklung 
zu tun, mehr mit Politik, ist zumindest meine Erfahrung, spätestens wenn 
du mit Normen und den Gremien dahinter zu tun hast ist es immer weniger 
technisches Interesse als mehr politisches.


Gruß,
Martin

Naja schrieb:
> Ich weiß von einem Bekannten aus einem Großunternehmen (Chemie), dass
> zumindest ein Teil der dort älteren Laborrechner noch bis vor kurzem mit
> Windows 3.11 liefen (kein Witz!) einschließlich MS-DOS Programme.
> Desweiteren hatten sie viele Rechner mit XP. Zuletzt wurde von der
> IT-Abteilung verstärkt Win7 angeschafft.

ich kenne sogar noch einen C64 ("Brotkasten") im Produktiveinsatz. Warum 
auch nicht, das Teil läuft, ist zuverlässig (seit Jahrzehnten) und tut 
was es soll.
Warum sollte man dann viel Geld ausgeben?

Für den Fall von Ausfällen steht ein weiterer C64 im Lager dessen 
Funktionsfähigkeit regelmäßig geprüft wird.

Windwos NT4 und Win95 sind auch bekannte Zeitgenossen, ein 
Messgerät/SPS-Programmiergerät/Telephonanlagen-Auslesgerät/was-auch-imme 
r  wirft man nicht einfach so weg. Da irgendwas zu ersetzten/erneuern 
zieht immer einen ganzen Rattenschwanz an Ausgaben hinter sich her.

Will man den Telephonanlagen-Auslese-PC ersetzen, dann muss man auch die 
Telephonanlage ersetzen. Da heute keiner mehr analoge Telephonanlagen 
verbaut müssen alle Telephone gleich auch noch ersetzt werden. Für die 
heute üblichen VOIP-Telephone darf man dann das alte Telephonkabel (eine 
Doppelader pro Telephon) teilweise durch Netzwerkkabel (VOIP über Wlan 
macht keinen Spaß) ersetzen. Da einige Telephone auch noch bei 
Stromausfall funktionieren müssen, muss man über das Thema 
Notstromversorgung nachdenken, eine USV für die gesamte Telephonanlage 
ist nicht mehr ausreichend, das Netzwerk ist natürlich nicht PoE-fähig, 
was die Stromversorgung der Telephone auch nicht gerade erleichtert...

> Autor: Schreiber (Gast)
> Datum: 26.04.2015 15:13

Du hast es erfasst !

Sehe ich genau so.

Hermann schrieb:
> Da kann meiner Meinung nach der beste Entwickler nichts für. Außer er
> setzt sich in seiner Freizeit hin und ordnet den Code.

Genau das mache ich die letzten 3 Wochenenden und werde es auch noch ein 
paar Wochenenden machen müssen :(

Ist ein Projekt das mir quasi vererbt wurde und es jeden Tag damit 
Probleme gibt, leider ist es ein Architekturproblem und nicht auf die 
schnelle zu lösen.
Solange das Problem aber nicht gelöst ist, muss ich Werktags andauernd 
danach schauen, kann keinen Urlaub nehmen und muss von 8-18 Uhr im Büro 
sein, auch die Mittagspause darf nicht zu lang werden. Noch dazu die 
dauernde Fragerei vom Vorgesetzten wann es endlich fertig ist, dabei 
komm ich im Daily Business kaum dazu was dran zu machen, zumal wir schon 
wieder recht häufig mehr als 30° im Büro haben und ich mich bei den 
Temperaturen nicht wirklich konzentrieren kann.

MaWin schrieb:
> Auch
> daran erkennbar, dass OO Programme i.A. viel langsamer dafür aber
> resourcenfressender sind.

Und Verallgemeinerungen sind grundsätzlich verkehrt.

dämlicher Entwickler schrieb:
>
> ...wieder recht häufig mehr als 30° im Büro haben und ich mich bei den
> Temperaturen nicht wirklich konzentrieren kann.

Das sind ja dritte Welt Arbeitsbedingungen. Schlimm! Ohne Klimanalage 
geht die Produktivität zurück. Das kenne ich auch von mir. Wieso 
genemigt Euch der Chef nicht einmal ein Fensterklimagerät? Von so viel 
kurzsichtigem Denken...

Nase schrieb:
> MaWin schrieb:
>> Auch
>> daran erkennbar, dass OO Programme i.A. viel langsamer dafür aber
>> resourcenfressender sind.
>
> Und Verallgemeinerungen sind grundsätzlich verkehrt.

Na namenlose Nase, keinen Mut zu deinem Beitrag zu stehen ?

i.A. heisst zwar oft, aber eben nicht ausschliesslich,
daher ist meine Aussage natürlich nicht falsch,
sondern nur von dir falsch verstanden worden.

Hättest du den Thread gelesen und nicht nur einen einzelnen Beitrag,
dann wüsstest du, daß ich die Ausnahmen durchaus erwähnt habe.

Faulpelz II schrieb:
> dämlicher Entwickler schrieb:
>>
>> ...wieder recht häufig mehr als 30° im Büro haben und ich mich bei den
>> Temperaturen nicht wirklich konzentrieren kann.
>
> Das sind ja dritte Welt Arbeitsbedingungen. Schlimm! Ohne Klimanalage
> geht die Produktivität zurück. Das kenne ich auch von mir. Wieso
> genemigt Euch der Chef nicht einmal ein Fensterklimagerät? Von so viel
> kurzsichtigem Denken...

Ist baulich bedingt nicht möglich, wir haben nur zwei Kippfenster in 
unserem Raum und da das Gebäude nur gemietet ist, darf auch nichts 
verändert werden.
Der großteil der Firma ist auch klimatisiert, wir haben halt die A-Karte 
gezogen in unserem Büro. Richtig eklig wirds dann ab 40°

dämlicher Entwickler schrieb:
> Faulpelz II schrieb:
>> dämlicher Entwickler schrieb:
>>>
>>> ...wieder recht häufig mehr als 30° im Büro haben und ich mich bei den
>>> Temperaturen nicht wirklich konzentrieren kann.
>>
>> Das sind ja dritte Welt Arbeitsbedingungen. Schlimm! Ohne Klimanalage
>> geht die Produktivität zurück. Das kenne ich auch von mir. Wieso
>> genemigt Euch der Chef nicht einmal ein Fensterklimagerät? Von so viel
>> kurzsichtigem Denken...
>
> Ist baulich bedingt nicht möglich, wir haben nur zwei Kippfenster in
> unserem Raum und da das Gebäude nur gemietet ist, darf auch nichts
> verändert werden.
> Der großteil der Firma ist auch klimatisiert, wir haben halt die A-Karte
> gezogen in unserem Büro. Richtig eklig wirds dann ab 40°

Zumindest könnte man die Arbeitszeit im Sommer nach früher hin 
verschieben. (Ich arbeite von 6-14:00. Allerdings hat das nichts mit der 
Klimaanlage zu tun.)

Es gibt fahrbare Klimageräte die nur einen Luftschlauch nach aussen 
brauchen. Dann gibt es noch welche mit Wasserkühlung wie man sie 
mitunter in IT-Server Räumen einsetzt.

MaWin schrieb:
> Na namenlose Nase, keinen Mut zu deinem Beitrag zu stehen ?
Warum sollte ich. Du ja auch nicht.

> i.A. heisst zwar oft, aber eben nicht ausschliesslich,
> daher ist meine Aussage natürlich nicht falsch,
> sondern nur von dir falsch verstanden worden.
Das hast du jetzt einfach so hineininterpretiert.

"i.A." heißt in diesem Zusammenhang sicher "im Allgemeinen". Damit meint 
man üblicherweise eine Ver-allgemein-erung, oder etwa nicht?

Faulpelz II schrieb:
>
> Zumindest könnte man die Arbeitszeit im Sommer nach früher hin
> verschieben. (Ich arbeite von 6-14:00. Allerdings hat das nichts mit der
> Klimaanlage zu tun.)
>
> Es gibt fahrbare Klimageräte die nur einen Luftschlauch nach aussen
> brauchen. Dann gibt es noch welche mit Wasserkühlung wie man sie
> mitunter in IT-Server Räumen einsetzt.

Ich arbeite von 8-19 Uhr, selbst wenn die die Arbeitszeit vorverlegen, 
hat das nur zur folge das ich noch länger im Büro sitze ;)

Das Facility Management hat das vor 2 Jahren mal geprüft mit dem 
Mobilgerät und kam zu dem Schluss, dass es nicht möglich sei und man das 
Problem anders lösen muss. Wir sind auch zu viert auf rund 20m², selbst 
wenn so ein mobiles Gerät gehen würde, würde das quasi unmittelbar neben 
dem Schreibtisch stehen, das ist auch keine Lösung. Bei dem Lärm könnte 
ich dann auch wieder nicht arbeiten, geschweigedenn mit nem Kunden 
telefonieren.

>Ich arbeite von 8-19 Uhr,

Super, 11h pro Tag abzüglich Pause! Entweder machst du satt Pause oder 
du solltest mal deinem Chef gestehen, daß du überfordert bist

Leistung ist nämlich Arbeit DURCH Zeit nicht Arbeit MAL Zeit!!!

Hallo MaWin,

MaWin schrieb:
> Es ist ein absoluter Irrtum, zu glauben, mit OO werde alles
> übersichtlicher.

Das hat auch niemand behauptet. Natürlich muß man OO beherrschen und 
richtig anwenden, genau wie jede andere komplexe Technologie. Aber wenn 
man das tut, also die OO a) beherrscht und b) korrekt anwendet, bringt 
das enorme Gewinne bei der Strukturierung und Organisation des Code. Daß 
Du und / oder andere diese Technologie nicht verstanden haben oder nicht 
richtig anwenden können, spricht nicht gegen die Technologie.

Liebe Grüße,
Karl

Hallo Christian,

Christian H. schrieb:
> Wenn man hier liest, wie alter, gut getesteter, der Firma viel Erfolg
> einbringender Code durch etwas objektorientiertes, modernes ersetzt
> werden soll, anstatt einfach nur schrittweise durch einfache Umformungen
> verbessert werden soll,

Da muß ich etwas verpaßt haben. Wo genau hast Du das denn gelesen?

Liebe Grüße,
Karl

IchGlaubeEsNicht schrieb:
>>Ich arbeite von 8-19 Uhr,
>
> Super, 11h pro Tag abzüglich Pause! Entweder machst du satt Pause oder
> du solltest mal deinem Chef gestehen, daß du überfordert bist
>
> Leistung ist nämlich Arbeit DURCH Zeit nicht Arbeit MAL Zeit!!!

Ja Pause, mal kurz was essen und die Zeit die es braucht um den Kaffee 
zu holen. Mein Chef weiß das bei uns Land unter ist, sein Chef auch, 
aber dem ist es egal. Wir suchen ja schon seit einem halben Jahr 
Verstärkung, aber der böse Fachkräftemangel... Nicht das die Suche 
äußerst intensiv wäre, aktuell ist die Stelle mal wieder nur auf der 
Webseite zu finden. Und selbst wenn sich doch mal eine Bewerbung zu uns 
verirrt, verlangt der Bewerber zu viel oder ist fachlich ungeeignet.

MaWin schrieb im Beitrag #4106824:
> Karl Käfer schrieb:
>> Daß Du und / oder andere diese Technologie nicht verstanden haben
>> oder nicht richtig anwenden können, spricht nicht gegen die Technologie.
>
> Ach Kindchen, ich guck mir einfach querschnittsmässig die Arbeiten von
> anderen an, um zu erfahren, wie die Wirklichkeit ist.

Ich werfe noch einmal meinen oben geschriebenen Satz in die Runde:

Gibt es eigentlich geführte Statistiken (von der Bundesanstalt für 
Arbeit oder sonst wem) darüber auf welcher Codebasis,
welchen Tools Software in mittelständischen Unternehmen typischerweise 
(noch) beruht? Es wird doch sonst immer gerne alles mögliche statistisch 
erfasst und ausgewertet.

Karl Käfers liebe zur reinen OO mit 100% sauber entworfenen 
Klassengerüsten scheint nicht wirklich Firmen alltagstauglich. Weil 
diese Form der reinen Lehre der OO nun mal nicht kompatibel ist mit 
Entwicklern, die permanentem Zeitdruck ausgesetzt sind, bei halbgaren 
Spezifikationen und unverhofften Änderungswünschen des Auftraggebers.

Und dort wo Objekte im Programmcode zur Anwendung kommen (so wie 
beispielsweise bei Lazarus Object Pascal) wird alles mögliche 
herumprogrammiert, nur nicht nach dem Musterlehrbuch, sondern so wie es 
passt = Firmenalltag.

Hallo Albert,

Albert M. schrieb:
> Ich kann da MaWin nur zustimmen. OK, meine Programme/Tools
> (Hobby-Bereich) sind nun nicht die Code-Monster, sondern bewegen sich im
> Bereich um die 10.000  bis 20.000 Codezeilen. Das von mir verwendete
> Delphi/Pascal bringt von Hause OO mit, aber das nun excessiv anwenden
> bringt mir keine Vorteile.

Jede "excessive" Anwendung von etwas bringt in der Regel keine Vorteile, 
egal was dieses Etwas ist. Das hat aber auch niemand behauptet. In 
kleinen Projekten kann die OO zwar durchaus nützlich sein, aber ihre 
eigentlichen Stärken kommen eher bei größeren, langfristig gepflegtem 
Code zum Tragen.

Liebe Grüße,
Karl

Lieber MaWin,

MaWin schrieb im Beitrag #4106877:
> Du bist der, der angreift.

"Du bist noch ein Kindergartenkind [...]" [1]

> Du unterstellst schon seit dem ersten Beitrag
> daß ich keine Ahnung habe und tust so, als ob du Ahnung hättest.

Was OO angeht, ist zweifellos genau das der Fall. Du redest von OO wie 
ein Blinder von den Farben und hast das ganze Thema offensichtlich 
nichtmal ansatzweise verstanden. Sonst kämst Du nicht auf Behauptungen 
wie "OO sollte die Erstellung erleichtern" [2], die schlicht und einfach 
falsch sind und beweisen, daß Du bereits die Ziele von OO nicht 
verstehst. Im Prinzip geht es dabei nämlich nicht einmal um die konkrete 
Technologie, sondern um eine Sichtweise auf komplexe Systeme und deren 
Organisation.

> Du bist der getroffene, und der Feigling der sich sicherheitshalber mal
> einen anderen Namen sucht.

... und noch eine blöde Unterstellung hinterherschieben, hm? Ich habe 
hier nur einen Namen, nämlich diesen.

> Eben ein Kindergartenkind. Nimm zur Kenntnis,
> daß dein Lieblingsspielzeug OO keineswegs so uneingeschränkt
> hochgejubelt wird.

Ich nehme zur Kenntnis, daß es eine ganze Reihe von Leuten gibt, die den 
Ansatz von OO nicht verstanden. Insbesondere hier muß man aber sehen, 
daß viele Projekte im Mikrocontroller-Umfeld einfach nicht komplex genug 
sind, nicht genug gemeinsamen Code nutzen und nicht genug langfristige 
Wartung benötigen, daß die OO ihre eigentlichen Stärken ausspielen 
könnte. Kurz gesagt: Mikrocontroller-Projekte können von OO-Features 
profitieren, aber auch ohne OO kann man das ohne größere Einschränkungen 
machen.

Aber spätestens da, wo die Komplexität, die geforderte Flexibilität, die 
Wiederverwendbarkeit und der langfristige Wartungs- und Pflegeaufwand 
die meistens trivialen Anforderungen des typischen 
Mikrocontroller-Umfeldes übersteigen, wird es ohne OO schnell recht 
aufwändig, die Komplexität zu beherrschen. Nicht zuletzt deswegen sind 
beinahe alle weit verbreiteten GUI-Frameworks auf die eine oder andere 
Weise mit OO-Techniken aufgebaut -- sogar das gerne als Gegenbeispiel 
genannte GTK+.

Im Grunde genommen ist doch auch gar nicht schlimm, daß Du die OO nicht 
verstehst. Traurig, ja, aber nicht schlimm. Trotzdem mußt Du niemanden 
anpöbeln, nur weil er die Vorteile von OO versteht und nutzen möchte.

Süße Grüße,
das Kindchen


[1] Beitrag "Re: Produktpflege in Softwareunternehmen"
[2] Beitrag "Re: Produktpflege in Softwareunternehmen"

Hallo Naja,

Naja schrieb:
> Gibt es eigentlich geführte Statistiken (von der Bundesanstalt für
> Arbeit oder sonst wem) darüber auf welcher Codebasis,
> welchen Tools Software in mittelständischen Unternehmen typischerweise
> (noch) beruht? Es wird doch sonst immer gerne alles mögliche statistisch
> erfasst und ausgewertet.
>
> Karl Käfers liebe zur reinen OO mit 100% sauber entworfenen
> Klassengerüsten scheint nicht wirklich Firmen alltagstauglich. Weil
> diese Form der reinen Lehre der OO nun mal nicht kompatibel ist mit
> Entwicklern, die permanentem Zeitdruck ausgesetzt sind, bei halbgaren
> Spezifikationen und unverhofften Änderungswünschen des Auftraggebers.

Nun, es gibt Statistiken der BA hinsichtlich der Programmiersprachen, 
für die Entwickler gesucht werden. Dabei liegen seit Jahren die 
OO-Sprachen vorne: Java, C++ und C#. Auch bei den Skriptsprachen haben 
diejenigen, welche OO-Features bieten, bislang mit Abstand gewonnen.

Im Übrigen zeigt insbesondere Java, das sich im Enterprise-Umfeld recht 
weitgehend durchgesetzt hat, daß OO auch mit den heute existierenden 
Rahmenbedingungen von Softwareentwicklung kompatibel ist. Tatsächlich 
ist es meistens sogar einfacher, eine Komponente in einem OO-System 
gegen eine andere zu tauschen, die zwar intern vollkommen anders 
funktioniert aber nach außen hin dieselbe Schnittstelle hat.

Abgesehen davon "liebe" ich die OO nicht. Das ist für mich nur ein sehr 
nützliches Werkzeug, das -- wie jedes andere Werkzeug auch -- verwendet 
wird, wenn es nutzt. Dafür sind Werkzeuge ja schließlich da. ;-)

Liebe Grüße,
Karl

Carsten Sch. schrieb:
> Wenn tatsächlich auch mal Leerlauf sein sollte dann die Codestellen die
> man nicht zwingend anpacken muss vornehmen.

Nun ja, never change a running program, es werden dir also genügend 
Leute von dem Aufräumen abraten, da damit ja neue Fehler reinkommen, die 
wieder teuer zu entfernen sind. Es ist sehr schwer so ein Aufräumen in 
einer Firma umzusetzen, da schreien gleich alle wenn nur tageweise in 
den nighty builds Fehler auftreten. Du hast offensichtlich mit der 
kommerziellen Programmierung nichts am Hut, sonst kämen solche 
Vorschläge nicht. Privat kann man das machen und macht es manchmal 
spasseshalber auch.

Zumal derjenige, der behauptet, das wäre alles Schrott und man könne das 
viel besser ganz neu schreiben, ja meist nicht mal ansatzweise 
überblickt, was das Programm tut - sonst würde er es ja nicht alles 
neuschreiben wollen.

MaWin schrieb:
> never change a running program

Auch übrigens, weil es für sich einen geschaffenen Wert darstellt, den 
man solange erhalten sollte, solang das System nach bestem Wissen und 
Gewissen mit ausreichender Vorausschaubarkeit seinen Zweck erfüllt.

Carsten Sch. schrieb:
> Bei geringer Komplexität hat dabei die prozedurale Programmierung die
> Nase Vorn, bei mäßiger Komplexität tun die sich nicht viel, bei hoher
> Komplexität hat aber dann die OO oft die Nase vorn.

Dieser Einschätzung könnte ich mich zur Not auch noch anschließen.

> Aber wie gesagt, wenn man wirklich wert darauf legt, dann kann man nach
> jedem Programmierparadigma Programme so erstellen das man selbst und
> auch andere diese nach JAhren noch problemlos erweitern und ändern
> können.
> Selbst in ASM!

Selbst in ASM! Ein wahres Wort!
Dokumentiert zur besseren Wartung wird doch auch nicht des 
hingeschriebenen Codes wegen. Es geht immer um die dahinterliegenden 
Algorithmen, die zugrunde liegende Architektur der Problemlösung.
Ganz gleich, in welcher Sprache formuliert.

Grundsätzlich muß man aber sagen, wenn eine Technologie wie OOP derart 
gestaltet ist, daß sich selbst viele gestandene Entwickler damit schwer 
tun, dann ist das immer auch eine Aussage über die Technologie selbst. 
Schließlich sollte sie die Realisierung vereinfachen, Arbeit sparen, die 
Probleme intuitiv lösen helfen- und nicht allzulange unproduktive Zeit 
bis zur Beherrschung verschwenden.

Hallo Carsten,

Carsten Sch. schrieb:
> Karl Käfer schrieb:
>> Insbesondere hier muß man aber sehen,
>> daß viele Projekte im Mikrocontroller-Umfeld einfach nicht komplex genug
>> sind, nicht genug gemeinsamen Code nutzen und nicht genug langfristige
>> Wartung benötigen, daß die OO ihre eigentlichen Stärken ausspielen
>> könnte. Kurz gesagt: Mikrocontroller-Projekte können von OO-Features
>> profitieren, aber auch ohne OO kann man das ohne größere Einschränkungen
>> machen.
>
>
> Das mit der Komplexität ist wohl in den meisten Fällen richtig.
> Aber die Sache mit der gemeinsamen Codebasis und der langfristigen
> Wartbarkeit, da liegst du völlig falsch.
> Ich wage mal zu behaupten das sehr viele Microcontrollerprogramme weit
> längere Lebenszyklen haben als die typische PC Software.

Entschuldige bitte, es ist wirklich nicht böse gemeint. Aber vielleicht 
solltest Du diese Sache mit dem "zwischen den Zeilen lesen" einfach mal 
bleibenlassen und Dich auf das konzentrieren, was Dein Vorredner -- in 
diesem Falle ich -- tatsächlich geschrieben hat. Ich habe mir nämlich 
durchaus Gedanken über meine Aussagen und Formulierung gemacht, so daß 
es bestenfalls überflüssig und schlimmstenfalls irreführend ist, wenn Du 
meine Aussagen zu interpretieren versuchst. Solche Konzepte erscheinen 
vielen Menschen heutzutage zwar fremd und ungewöhnlich, aber nach meiner 
Erfahrung funktioniert die Kommunikation einfach besser, wenn man dem 
anderen erstmal zuhört, davon ausgeht daß er am Besten weiß was er sagen 
will, und daß er das, was er sagt, auch genau so meint. ;-)

Ich schrieb von "langfristiger Wartung", also vom langfristigen Aufwand 
in Abhängigkeit von der Anzahl und vom Umfang der Iterationszyklen, Du 
aber sprichst von der Gesamtdauer des Lebenszyklus. Aber das sind doch 
zwei vollkommen unterschiedliche Dinge!

Eine Software zur Steuerung von Motoren oder Waschmaschinen wird in der 
Regel genau einmal entwickelt, dann getestet und zertifiziert, und dann 
nie wieder angefaßt, solange sie keinen Fehler hat. Sogar wenn ein neues 
Modell entwickelt wird, wird oftmals lediglich die Kennfeldkonfiguration 
verändert oder eine Temperaturberechnung von LM35- auf AD22100-Sensoren 
abgeändert. Solche Kinkerlitzchen, die zudem nur alle paar Jahre einmal 
auftauchen, bekommt man mit vertretbarem Aufwand auch ohne OO hin. Und 
auch aus Gründen von Updatemechanismen und Zertifizierungen kann man es 
sich nicht leisten, ständig an solcher Software herumzuentwickeln.

Eine komplexere GUI-Software, die vom verwendeten Betriebssystem, vom 
Compiler oder Interpreter und einem GUI-Framework abhängig ist, lebt 
hingegen oftmals zwar weniger lange, wird in dieser Zeit aber bedeutend 
häufiger an die Laufzeitumgebung angepaßt und funktional erweitert. Das 
kannst Du bei einer Waschmaschinensteuerung (derzeit noch; mal schauen 
was das "Internet Of Things" bringen wird) schlicht vergessen.

Infolgedessen wage ich zu behaupten, daß ein nicht ganz unerheblicher 
Teil der Mikrocontroller-Entwickler noch nie eine Software gesehen, 
geschweige denn geschrieben hat, die komplex genug war und oft genug 
geändert werden mußte, daß sich das Verständnis und die Anwendung von OO 
für sie gelohnt hätte. Die meisten Embedded-Entwickler haben ihre Stärke 
im mathematisch-algorithmischen Bereich und in der detaillierten 
Kenntnis ihrer Hardware. Für die meisten Anwendungsentwickler sind 
Mathematik und Algorithmen nur randständige, und Hardware, Busse etc. 
völlig nebensächliche Themen.

> Klar wirkliche Extreme gibt es bei beiden. In der µC Welt ist das der
> ARM der als einzige Funktion einen Z80 Emuliert damit die alte Z80
> Taschenrechnerfirmware darauf ohne Neuerstellung noch arbeitet,
>
> In der PC Welt sind dies die Bankensoftware in COBOL oder der KErn einer
> Simulationssoftware für die Luftfahrt aus den frühen 60er JAhren in
> Fortran geschrieben die immer noch als Black Box in die aktuellen
> Simulationsprogramme eingebunden wird.

Das ist eher das Serverumfeld, aber... Jedenfalls betreiben die diesen 
Aufwand doch gerade deswegen, weil die vorhandene Software eben nicht 
modular und darum nicht schrittweise austauschbar ist, also, anders 
gesagt: weil die vorhandene Software eben keine OO-Software ist, sondern 
ein riesiges Konglomerat an prozeduralem oder funktionalem 
Spaghetticode, das niemand mehr überblicken, geschweige denn neu 
schreiben kann.

> Bei geringer Komplexität hat dabei die prozedurale Programmierung die
> Nase Vorn, bei mäßiger Komplexität tun die sich nicht viel, bei hoher
> Komplexität hat aber dann die OO oft die Nase vorn.

Auch bei überschaubarer Komplexität hat die OO ihre Vorteile, aber erst 
bei höherer Komplexität kommen diese so richtig zum Tragen.

> Wobei im Einzelfall aber natürlich auf das zu lösende Problem in
> Verbindung mit den Fähigkeiten des Programmierers ankommt was nun
> wirklich der effektivste Weg zur Lösung ist...

Das ist immer die Grundvoraussetzung und deswegen ein 
Allgemeinplätzchen. Einen schlechten OO-Entwickler mit einem guten 
prozeduralen Entwickler zu vergleichen ist genauso bescheuert wie einen 
guten OO-Entwickler mit einem schlechten prozeduralen Entwickler zu 
vergleichen. Wenn man vergleichen will, muß man schon vergleichbar gute 
Niveaus vergleichen, sonst hat die ganze Diskussion doch gar keinen 
Zweck.

Liebe Grüße,
Karl

Hallo Carsten,

Carsten Sch. schrieb:
> Karl Käfer schrieb:
>> Christian H. schrieb:
>>> Wenn man hier liest, wie alter, gut getesteter, der Firma viel Erfolg
>>> einbringender Code durch etwas objektorientiertes, modernes ersetzt
>>> werden soll, anstatt einfach nur schrittweise durch einfache
>>> Umformungen verbessert werden soll,
>>
>> Da muß ich etwas verpaßt haben. Wo genau hast Du das denn gelesen?
>
> Also ehrlich gesagt, zwischen den Zeilen lese ich dasselbe!

Wo denn? Ich sehe nichts davon.

> Hermann schrieb:
>>... Unter der Haube wird aber noch nicht einmal
>> objektorientiert gearbeitet.

Du kaprizierst Dich IMHO zu sehr auf das "noch nicht einmal". Ich lese 
zunächst einmal nichts anderes als die Feststellung, daß der Code nach 
heute veralteten Standards entwickelt wurde, mit zunehmender Komplexität 
immer schwerer zu ersetzen sein wird und daß die Aufwände für Wartung 
und Weiterentwicklung bereits jetzt ein problematisches Ausmaß erreicht 
haben und in absehbarer Zukunft exponentiell weiter steigen.

> Hermann schrieb:
>> Neben dem Wachstum ist auch ein anderes Problem, dass keine neuen
>> Technologien verwendet werden. Eines unserer Produkte hat z.B. eine
>> Weboberfläche die noch auf dem Stand von vor 15 Jahren ist.
>
> Da wird als Kritikpunkt angeführt das ja noch nicht einmal OO "unter der
> HAube" gewerkelt wird oder aber auch das die Weboberfläche zur
> Parametrierung nicht der neueste Stand ist -

Tja, mit Speck fängt man Mäuse, und optisch ansprechende Software 
verkauft sich nun einmal besser. Was meinst Du, warum jede noch so 
kleine Bude wie Microsoft oder Apple umfangreiche Style- und 
Designguides herausgibt und bei ihrer eigenen Software penibel auf deren 
Einhaltung achten?

> Da ist also ein Code der Stabil läuft, die Kunden sind hochzufrieden mit
> der Software und bisher konnte man die auch immer noch irgendwie
> Pflegen, wenn auch mit zunehmenden Problemen.

Genau das ist der Punkt: im Moment und heute läuft der Code und die 
Kunden sind damit zufrieden. Aber Hermann sieht, daß die Probleme 
zunehmen und niemand etwas dagegen tut, so daß sich die Firma in 
absehbarer Zukunft immer weiter in eine Ecke hineinprogrammiert, aus der 
ein Ausweg immer schmerzhafter wird, und irgendwann nicht mehr mit 
vertretbarem Aufwand beschritten werden kann. Anders gesagt: er steht 
daneben und sieht, wie die Firmenleitung und die Alteingesessenen die 
Codebasis und damit die Firma langsam, aber unaufhaltsam gegen die Wand 
fahren.

Dabei steht Hermann jetzt vor der Frage, was er tun soll. Im Prinzip hat 
er drei unbequemen Möglichkeiten. Die erste ist, sich einen neuen Job zu 
suchen; das ist vermutlich die einfachste Option. Die zweite ist 
hingegen zu versuchen, den absehbaren Crash des Unternehmens abzuwenden 
und gegen die Widerstände von Geschäftsleitung und Kollegen eine 
Änderung des Kurses anzuregen. Die dritte Möglichkeit ist, den Mund zu 
halten und zuzuschauen, wie das Unternehmen gegen die Wand fährt, und 
irgendwann in der Mitte oder im Herbst des eigenen Lebens etwas neues 
suchen zu müssen.

OO oder nicht-OO sowie andere technische Belange sind dabei eigentlich 
völlig nebensächlich und dienen ihm nur zur Illustration der Situation. 
Deswegen geht die ganze Diskussion um OO etc. auch eigentlich vollkommen 
am Thema vorbei, zumal man sich natürlich, wie mit jeder Technik, so 
auch mit OO ins Abseits programmieren kann. Deswegen geht es dabei 
weniger um OO oder nicht, sondern vielmehr um die Frage, wann eine 
Refaktorierung der vorhandenen Codebasis angeraten ist -- und mit 
welchen Techniken das dann geschehen soll, ist dann erst die zweite 
Frage.

Liebe Grüße,
Karl

Wie schon oben von mir beschrieben, arbeitete ich in der gleichen 
Branche (Automation), hatte fast die gleichen Probleme wie der TO, ja 
wahrscheinlich arbeiteten wir sogar in der gleichen Firma wer weiß!

Ging um ein Materialflusssystem inkl. komplexer GUI, viel Spaghetticode. 
Teilw. natürlich Algorithmen. Aber vorwiegend viel alter C Code aus den 
Neunzigern.
Wir hatten vi im Einsatz und mit dem programmiert, zum Glück auch CVS. 
Dieses Moloch (angebl. >1 Mio. Codezeilen) ist beim Kunden immer 
gewachsen und gewachsen.

Produktions- und Ultrahotfixes waren an der Tagesordnung. Die 
Testumgebung nicht zu gebrauchen. Hatte oft Nachtschichten, meinen 
Verbesserungsvorschlägen wollte dann keiner nachkommen, hat ja bis jetzt 
immer so funktioniert.  Na dann  Pech gehabt, nam dann nen neues Angebot 
an mit 20% Lohn.

Moral der Geschicht: in Neunziger Jahre Software rumfrickeln lohnt sich 
nicht, zumindest nicht für mich.

Bei mir wars ähnlich:
Ein paar Alteingesessene natürlich, verteidigten ihre Software, würden 
wahrscheinlich in freier Wildbahn keinen Job mehr finden. Sicher haben 
die da jahrelang dem Kunden damit die Kohle aus der Tasche gezogen.

Und es gibt einen Leitsatz, der exakt auf die Firma zutraf: je 
schlechter eine Organisation, desto häufig schlechter ist auch der Code. 
Traf dort genau zu.

Versuchte denen im Abschlussgespräch einen Gefallen zu tun, indem ich 
diesen Haufen kostenlos beratete. Zwecks Refactoring,QS usw.
wollte einfach nix mehr mit denen zu tun haben, hatte schon vorher gute 
Mittel und mich abgesichert und ein exzellentes Dienstzeugnis bekommen. 
Aber das war ne andere Geschichte ;-) bin mit ein paar ehem. netten 
Kollegen noch in Kontakt, leider konnten sich die nicht von der Firma 
losreißen.

Mittlerweile wurde sogar ne kleine QS Abteilung aufgebaut. Die Firma 
ging in die Miesen aufgrund so eines Projektes und wurde von nem Großen 
geschluckt.

Ende der Geschichte.

Karl Käfer schrieb:
> Dabei steht Hermann jetzt vor der Frage, was er tun soll. Im Prinzip hat
> er drei unbequemen Möglichkeiten. Die erste ist, sich einen neuen Job zu
> suchen; das ist vermutlich die einfachste Option. Die zweite ist
> hingegen zu versuchen, den absehbaren Crash des Unternehmens abzuwenden
> und gegen die Widerstände von Geschäftsleitung und Kollegen eine
> Änderung des Kurses anzuregen. Die dritte Möglichkeit ist, den Mund zu
> halten und zuzuschauen, wie das Unternehmen gegen die Wand fährt, und
> irgendwann in der Mitte oder im Herbst des eigenen Lebens etwas neues
> suchen zu müssen.
>
> OO oder nicht-OO sowie andere technische Belange sind dabei eigentlich
> völlig nebensächlich und dienen ihm nur zur Illustration der Situation.
> Deswegen geht die ganze Diskussion um OO etc. auch eigentlich vollkommen
> am Thema vorbei, zumal man sich natürlich, wie mit jeder Technik, so
> auch mit OO ins Abseits programmieren kann. Deswegen geht es dabei
> weniger um OO oder nicht, sondern vielmehr um die Frage, wann eine
> Refaktorierung der vorhandenen Codebasis angeraten ist -- und mit
> welchen Techniken das dann geschehen soll, ist dann erst die zweite
> Frage.

Danke Karl, du hast mich verstanden!
Das mit OO oder der GUI waren lediglich Beispiele.

Mich interessiert einfach, wie solche Prozesse in anderen Unternehmen 
ablaufen. Oder ob sie gar nicht ablaufen.

Schrittweises umstellen vs. komplette Neueentwicklung.
Soziale Komponente mit den älteren Kollegen
usw.

Es geht mir auch nicht darum mich als Super-Typ hinzustellen und zu 
sagen der alte Kram ist schlecht.
Der alte Code hat sogar seht gute Konzepte und ist läuft stabil. Was die 
damals geschaffen haben ist super, wurde aber leider nicht mehr 
weiterentwickelt.

Für mich ist auch Nachwuchs ein Thema. Wenn man sich neue Leute frisch 
von den Unis und FHs ansieht, können die Java oder Ruby.
Wenn man die dann an den C-Code ransetzt gibt das nur Probleme.
Die wissen gar nicht, wie man vernünftig mit Pointern, Callbacks, usw. 
umgeht. Es werden "free" und "malloc" vergessen oder andere 
Überschreiber produziert.
Das meine ich mit
> erforderlich, da der aktuelle Stand, vor allem für die jüngeren
> Kollegen, nicht mehr Wartbar ist.

Da es sowieso extrem schwer ist hier im Ballungsraum 
Entwickler-Nachwuchs für kleine Unternehmen zu finden, verscheucht man 
die Leute leider wieder sehr schnell, wenn sie in alten C-Codes arbeiten 
müssen.

> AHA!!! Also alles Java-Hippies, die keinen Bock auf solide Arbeit haben?

java... schön wärs. Die Leute wollen nur noch Ruby :-(

Hallo Carsten,

Carsten Sch. schrieb:
>> Jedenfalls betreiben die diesen
>> Aufwand doch gerade deswegen, weil die vorhandene Software eben nicht
>> modular und darum nicht schrittweise austauschbar ist, also, anders
>> gesagt: weil die vorhandene Software eben keine OO-Software ist..,
>
> Du Stellst hier die Behauptung auf das "Modular == Übersichtlich == OO".
> Und zwar Exklusiv.

Entschuldige bitte, das war leider sehr unglücklich formuliert. Mit 
"weil die vorhandene Software eben keine OO-Software ist" meinte ich 
nicht, daß modulare Software nur mit OO möglich ist, sondern, daß man 
auch ohne eine explizite OO-Unterstützung durch die Programmiersprache 
objektorientierte Methodiken zur Modularisierung einsetzen kann. 
Schließlich ist die OO aus genau diesen Modularisierungstechniken 
hervorgegangen, ...

> Natürlich ist es leichter in OO Modularer zu schreiben weil das ganze
> Konzept dahinter in diese Richtung geht.
> [...]
> OO ist nur ein anderes Paradigma das teilweise im Gegensatz zum
> Prozeduralen steht.

Im Prinzip ist die historische Entwicklung ja so verlaufen, daß mit der 
zunehmenden Leistungsfähigkeit der Rechenwerke, Computersysteme und den 
zunehmend komplexeren Aufgaben auch der Code immer leistungsfähiger und 
komplexer wurde, so daß der Aufwand zur Wartung und Pflege des Code 
immer weiter anstieg. Um diese Aufwände beherrschbar zu machen, ging man 
dann immer stärker dazu über, den Code zu modularisieren. Wohlgemerkt: 
dabei ging es zunächst nur um die Modularisierung von prozeduralem Code, 
siehe dazu auch [1] und [2].

Alsbald ging man dann dazu über, diese Modularisierung von Code durch 
neue Sprachmittel zu unterstützen; Bjarne Stroustrup beschreibt die 
Entwicklung in "Design and Implementation von C++" sehr anschaulich. Im 
Prinzip begann die Entwicklung von C++ damit, die bekannten 
Modularisierungstechniken aus der prozeduralen Entwicklung mit neuen 
Schlüsselworten zu unterstützen, die dann anfangs von einer Art 
Präprozessor wiederum in prozeduralen Code übersetzt, und dieser dann 
kompiliert wurde. Ähnlich macht das heute Qt mit dem Meta-Object 
Compiler für die "Signals and Slots".

Im der Folge stellte sich heraus, daß mit den neuen Sprachmitteln ganz 
neue Herangehensweisen und Softwarearchitekturen möglich und sinnvoll 
wurden; dafür etablierte sich der Begriff "Objektorientierung". Insofern 
verstehe ich die OO primär als Erweiterung der prozeduralen Konzepte und 
Entwurfsmuster zur Modularisierung, und weniger als Gegensatz.

Im Prinzip sehe ich keinen wirklichen Unterschied darin, ob ich in C so 
etwas schreibe wie:

1

#include <stdio.h>

2

#include <stdlib.h>

3

4

typedef struct {

5

    int eins;

6

    int zwei;

7

} data_t;

8

9

data_t* create_data_t(int eins, int zwei) {

10

    data_t* r = (data_t*)malloc(sizeof(data_t));

11

    r->eins = eins;

12

    r->zwei = zwei;

13

    return r;

14

}

15

16

int sum_data_t(data_t* this) {

17

    return this->eins + this->zwei;

18

}

19

20

void output_data_t(data_t* this) {

21

    printf("eins = %d, zwei = %d\n", this->eins, this->zwei);

22

}

23

24

int main(void) {

25

    data_t* d = create_data_t(1, 2);

26

    output_data_t(d);

27

    printf("sum(d) = %d\n", sum_data_t(d));

28

    free(d);

29

    return 0;

30

}

oder

1

#include <cstdio>

2

3

class data_t {

4

public:

5

    int eins;

6

    int zwei;

7

8

    data_t(int eins, int zwei):

9

        eins(eins), zwei(zwei)

10

    {}

11

12

    int sum(void) {

13

        return this->eins + this->zwei;

14

    }

15

16

    int output(void) {

17

        std::printf("eins = %d, zwei = %d\n", this->eins, this->zwei);

18

    }

19

};

20

21

int main(void) {

22

    data_t* d = new data_t(1, 2);

23

    d->output();

24

    std::printf("d->sum() = %d\n", d->sum());

25

    return 0;

26

}

Letzten Endes macht die OO hier nichts anderes, als die Funktionen zur 
Bearbeitung der Datenstruktur direkt an die Datenstruktur zu binden. Die 
Datenstruktur mitsamt den Funktionen wird dann zwar als Objekt 
bezeichnet und die Funktionen als Methoden. Aber letzten Endes ist die 
OO in diesem Beispiel nur eine Automatisierung dessen, was ich im 
prozeduralen Beispiel von Hand gemacht habe: nämlich einen Zeiger auf 
die Struktur als ersten Parameter an die Funktion zu übergehen und den 
Zeiger an den definierten Namen "this" zu binden.

Als man dann feststellte, daß ein Polizeiauto letztlich nichts anderes 
ist als ein Auto mit Blaulicht, wurde eine Möglichkeit erdacht, 
bestehende Objekte mit weiteren Datenelementen und Methoden zu versehen, 
ohne sie neu schreiben zu müssen. Das kennen wir heute als "Vererbung": 
das Polizeiauto "erbt" Datenelemente und Methoden unseres Objekts 
"Auto", und fügt diesem ein Datenelement "blaulicht" sowie die Methoden 
zum Ein- und Ausschalten desselben hinzu.

Daraus ergeben sich drei enorme Annehmlichkeiten: zum Einen kann man 
jetzt das Polizeiauto überall dort verwenden, wo auch ein Auto verwendet 
werden kann, beispielsweise kann ein Polizeiauto in ein Objekt 
"Parkhaus" fahren und dort einen Stellplatz belegen, ohne daß das 
Parkhaus angepaßt werden muß. Ebenso angenehm ist, daß eine Änderung am 
Objekt Auto sich gleich auch auf das Polizeiauto auswirkt. Der dritte 
Effekt ist -- hier sind wir wieder bei den Themen Modularisierung und 
Wartbarkeit -- daß der Auto-Code ohne Änderungen am übrigen Code gegen 
eine andere Auto-Implementierung ausgetauscht werden kann, solange die 
Schnittstelle beibehalten wird.

Deswegen sehe ich in der Objektorientierung keinen Gegensatz und keinen 
Widerspruch, sondern eine Erweiterung prozeduraler Paradigmen und eine 
sprachliche Unterstützung von Techniken, die prozedurale Entwickler in 
ähnlicher Weise nutzen, um die Modularisierung und Wiederverwendbarkeit 
ihrer Software zu verbessern. Die Aussage, gute prozedurale Entwickler 
könnten nicht gut mit OO umgehen und umgekehrt, würde ich daher nicht 
unterschreiben: prozedurale Techniken sind die Grundlage, die die OO 
gerade erst ermöglichen; wer die prozedurale Technik nicht beherrscht, 
kann niemals ein guter OO-Entwickler werden.

Liebe Grüße,
Karl

PS: Spaßeshalber habe ich die Codeschnipsel oben, und ein paar ähnliche, 
einmal kompiliert und festgestellt, daß nicht nur der Quellcode, sondern 
auch das Binary des C++-Code minimal kleiner ist als beim C-Code. Ich 
hab mich sogar bemüht, den Quellcode ähnlich zu formatieren. Das 
Ergebnis von "./compile.sh" sieht so aus:

1

k@rl: $ for i in 2 3 4; do echo "Sorted by: ${i}"; ./compile.sh | sort --key $i; echo; done

2

Sorted by: 2

3

s_main++.cpp     399     8560    6272

4

h_main++.cpp     422     8608    6280

5

ps_main.c        493     8664    6272

6

s_main.c         501     8728    6280

7

h_main.c         565     8768    6288

8

9

Sorted by: 3

10

s_main++.cpp     399     8560    6272

11

h_main++.cpp     422     8608    6280

12

ps_main.c        493     8664    6272

13

s_main.c         501     8728    6280

14

h_main.c         565     8768    6288

15

16

Sorted by: 4

17

ps_main.c        493     8664    6272

18

s_main++.cpp     399     8560    6272

19

h_main++.cpp     422     8608    6280

20

s_main.c         501     8728    6280

21

h_main.c         565     8768    6288

Man sieht: bei der Größe des Quellcode und dem nicht ge-strip(1)-ten 
Kompilat liegt C++ eindeutig vorne, bei der Größe des ge-strip(2)-ten 
Binary liegt es genau gleichauf mit den C-Implementierungen -- und dabei 
verliert auch noch ausgerechnet jene C-Implementierung, welche ich ganz 
persönlich für die modularste und wiederverwendbarste halte, weil deren 
Datenstruktur auf dem Heap angelegt wird. Soviel zur hier im Forum immer 
noch häufig geäußerten Behauptung, OO führe zwangsläufig zu sehr großem 
und ineffizientem Codebloat.

PPS: Ja, ich habe ein sehr spezielles Polizeiauto. Das keine Sirene.
Darüber macht man keine Witze!

[1] 
http://www.embedded.com/design/prototyping-and-development/4023876/Modular-Programming-in-C
[2] http://c2.com/cgi/wiki?ModularProgramming

Hallo Carsten,

entschuldige bitte, daß ich den Anhang vergessen hatte. Aber jetzt.

Carsten Sch. schrieb:
> Karl Käfer schrieb:
>> Du kaprizierst Dich IMHO zu sehr auf das "noch nicht einmal". Ich lese
>> zunächst einmal nichts anderes als die Feststellung...
>
> Und hier noch einmal der Hinweis.
> Ich habe geschrieben WAS ICH aus diesen Zeilen lese.

Ja, und ich habe geschrieben, warum das, was Du aus diesen Zeilen liest, 
sich nach meinem Verständnis viel zu sehr auf die Formulierung verlegt, 
anstatt des vom OP geschilderten Problems. Kein Grund zu SCHREIEN.

> Und mit meiner Interpretation bin ich offensichtlich nicht so ganz
> alleine.

Argumentum ad populum? Echt jetzt? Verarsch meine Oma.

> Das du etwas anderes liest glaube ich dir, aber es ändert ja nichts an
> der Sachlage das beides bloß Interpretationen sind und deine deshalb
> nicht "richtiger" (aber auch nicht falscher) ist als meine:
> [...]
> Die feststellung das es Wartungsprobleme geben wird ist zwar enthalten,
> aber um nur DIES zu meinen sind die Oberflächlichkeit meiner Ansicht
> doch zu sehr betont.

Leider verstehe ich nicht, was Du mir sagen möchtest. Aber wir scheinen 
beide verstanden zu haben, daß es dem OP a) darum geht, daß die Software 
des betreffenden Unternehmens nicht gerade neuesten Standards 
entspricht, b) die Software derzeit noch erfolgreich ist, c) immer 
größere Aufwände für die Pflege und Wartung verursacht und deswegen d) 
gewisse Zweifel an der Zukunftsfähigkeit der Software wie auch an der 
Zukunftsfähigkeit des von dieser Software lebenden Unternehmens geweckt 
werden.

Siehst Du das anders?

>>> Hermann schrieb:
>> Tja, mit Speck fängt man Mäuse, und optisch ansprechende Software
>> verkauft sich nun einmal besser. Was meinst Du, warum jede noch so
>> kleine Bude wie Microsoft oder Apple umfangreiche Style- und
>> Designguides herausgibt und bei ihrer eigenen Software penibel auf deren
>> Einhaltung achten?
>
> Microsoft oder Apple bedienen ja nun einmal auch eine GANZ ANDERE
> Zielgruppe mit einer GANZ ANDEREN Art von Software.

Das glaube ich nicht. Die Kunden, mit denen ich bisher zu tun hatte, 
waren meistens Menschen mit Augen und Gehirn.

> Wobei zumindest Microsoft in der Vergangenheit alles andere als ein
> Händchen für die Wünsche seiner Kunden bewiesen hat. Wenn die nicht im
> Betriebssystembereich und Office Bereich einen derart hohen MArktanteil
> hätten

Wo haben sie den hohen Marktanteil denn her? So ein Marktanteil fällt 
schließlich nicht vom Himmel. Meinst Du nicht, daß da ein ursächlicher 
Zusammenhang damit besteht, daß Windows 95 einfach besser aussah als 
Apples MacOS/7, Solaris' CDE und Linux' fvwm2? Ich glaub schon.

> Im Industrieellen/Produktiven Umfeld geht es aber überhaupt nicht um
> BlinkBlink oder tolles Design oder was auch immer. Das Interessiert
> überhaupt nicht. ISt sogar manchmal eher als Minuspunkt gewertet.
> Es gibt genau 9 Anforderungen die erfüllt werden müssen:
>
> EINFACH, ÜBERSICHTLICH, und STABIL - STABIL - STABIL - STABIL -
> STABIL - STABIL - STABIL

Du glaubst, gutes UI-Design hätte was mit "BlinkBlink" zu tun? Heiligs 
Blechle! Das ist doch wohl nicht Dein Ernst?!

>> Genau das ist der Punkt: im Moment und heute läuft der Code und die
>> Kunden sind damit zufrieden. Aber Hermann sieht, daß die Probleme
>> zunehmen und niemand etwas dagegen tut, so daß sich die Firma in
>> absehbarer Zukunft immer weiter in eine Ecke hineinprogrammiert, aus der
>> ein Ausweg immer schmerzhafter wird, und irgendwann nicht mehr mit
>> vertretbarem Aufwand beschritten werden kann. Anders gesagt: er steht
>> daneben und sieht, wie die Firmenleitung und die Alteingesessenen die
>> Codebasis und damit die Firma langsam, aber unaufhaltsam gegen die Wand
>> fahren.
>
> Oder er meint das zu sehen.

Klar, oder das. Aber ich möchte ihm nicht einfach pauschal unterstellen, 
daß er ein unfähiger Schwachkopf ist. Im Gegenteil habe ich den 
Eindruck, daß da ein businessmäßig unerfahrener, jedoch technisch 
durchaus fähiger Entwickler die Probleme des Alltagsbetriebs versteht 
und helfen möchte, die von ihm erkannten Probleme zu beheben.

> Wobei er damit vermutlich Recht hat. Nur ist die Frage ob er das
> richtige aus den richtigen oder aus den falschen Gründen tun will
>
> Mit "HauRUCK" und "OO ist sowieso in allem Besser" wird er auf jeden
> Fall bei Kollegen und Vorgesetzten keinen Blumentopf gewinnen können.

Vielleicht hast Du mein Posting von oben [1] gelesen, in dem ich anrate, 
mit kleinen Schritten anzufangen um das Vertrauen der GL und der 
Kollegen zu gewinnen. "Hauruck" geht ohnehin nicht, wenn man mit anderen 
Menschen zu tun hat und mit denen gemeinsam Probleme lösen muß. Aber 
sowas setze ich eigentlich als selbstverständlich voraus.

> Eine vernünftige und langfristige Strategie muss her. Dazu bedarf es
> aber auch der Mitwirkung der Kollegen und die bekommt man nur mit
> vernünftigen Argumenten. GANZ AM ENDE darf dann auch gerne ein komplett
> in OO realisierter Code stehen. Aber doch bitte schrittweise.
> Also zuerst vernünftige Testszenarien entwerfen, dann Modularisieren und
> danach erst Schritt für Schritt (Modul für Modul) umsetzen.

Also genau das, was ich weiter oben [1] empfohlen hatte.

Liebe Grüße,
Karl


[1] Beitrag "Re: Produktpflege in Softwareunternehmen"

Hallo Hermann,

Hermann schrieb:
> Mich interessiert einfach, wie solche Prozesse in anderen Unternehmen
> ablaufen. Oder ob sie gar nicht ablaufen.

Es geht nicht um die Prozesse, sondern um die Menschen.

Lebe Grüße,
Karl

Karl Käfer schrieb:
> Es geht nicht um die Prozesse, sondern um die Menschen.

ISO9001/14001, also jede ernstzunehmende Firma ausser Hobbybastlern und 
Klitschen wie du, interessiert sich für die Prozesse, nicht für die 
Menschen, die sind austauschbar.

1

#include <stdio.h>

2

3

int eins=1,zwei=2;

4

5

int main(void) 

6

{

7

    printf("eins = %d, zwei = %d\n", eins, zwei);

8

    printf("sum = %d\n", eins+zwei);

9

    return 0;

10

}

ist entschieden kürzer als deins, schneller überblickbar und genau so 
änderungsfreundlich, läuft schneller und kostet weniger Speicher.

Es interessiert hingegen nicht, daß deines "erweiterungsbarer" und 
"gekapselter" ist, wenn es nicht erweitert wird, denn es ist nicht 
änderungsfreundlicher: Du hat bereits zu viel Overhead reinprogrammiert, 
der ebenfalls geändert werden müsste.

Man überlege sich bloss mal, wie viel Arbeit es ist, bei deinem Code 
einen dritten Wert hinzuzufügen. 6 Zeilen müssten geändert werden und 
müssen danach konsistent zueinandner sein, während es im prozeduralen C 
Fall nur 3 Zeilen sind.

1

#include <stdio.h>

2

3

#define EINS 1

4

#define ZWEI 2

5

6

int main(void) 

7

{

8

    return printf("eins = %d, zwei = %d\n"

9

                  "sum = %d\n", EINS, ZWEI, EINS+ZWEI);

10

}

Wäre übrigens noch kürzer und effizienter, wenn man weiss, daß das 
Programm eigentlich fertig ist und nur noch optimiert gehört, die Zahlen 
aber leicht anpassbar bleiben sollen.

Die Ausrede, deines wäre ja kein konkretes Problem sondern nur ein 
Beispiel, und die wahren Gründe stecken in dem was nicht gezeigt ist, 
ziehen übrigens nicht, denn genau das ist das Problem der Schwätzer:
Immer von Dingen schwätzen, die nicht real sind.

Karl Käfer schrieb:
> Du glaubst, gutes UI-Design hätte was mit "BlinkBlink" zu tun? Heiligs
> Blechle! Das ist doch wohl nicht Dein Ernst?!

Du glaubst, gutes UI Design müsste "modern" sein und ist Mist, wenn es 
schon 10 oder 20 Jahre vor dir geschrieben wurde ? Ach du grüne Neune. 
Viele aktuelle Programme zum selben Problem sind heute unergonomischer, 
als sie es in älteren Versionen waren, weil man z.B. bestehende 
Frameworks übernehmen wollte (z.B. Eclipse, Browser) die nicht optimal 
anpassbar sind, oder weil man jede Mode mitgehen wollte (z.B. Ribbons). 
Nicht unbedingt aus Faulheit, sondern meist aus Fehlentscheidungen.

Manche Leute hier halten HP Taschenrechner für optimal wegen RPN und 
wollen gar kein "moderneres" UI.

> ist entschieden kürzer als deins, schneller überblickbar und genau so
> änderungsfreundlich, läuft schneller und kostet weniger Speicher.

Also ganz ehrlich...
Bei einem "Eins Zwei Drei" Beispiel hat OO natürlich mehr Overhead.
Daran kann man jetzt ja nicht zeigen wollen, dass OO nicht wartbar ist.

Interessant wird es doch wenn diverse Threads laufen, Nachrichten durch 
die Software geschickt werden, Status-Objekte verwaltet werden müssen, 
Daten aus DBs geladen und konvertiert werden müssen, usw.

Klar, geht auch alles in reinem C mit structs, Handles, usw. OO ist da 
aber wesentlich besser zu schreiben, zu lesen und zu warten.

"Vollkommenheit ensteht offensichtlich nicht dann, wenn man nichts mehr
hinzuzufügen hat, sondern wenn man nichts mehr wegnehmen kann. Das
Embedded System in seiner höchsten Vollendung wird unauffällig."

--- frei nach Antoine de Saint-Exupéry

P. M. schrieb:
> Eine gute Firma wird darin investieren, langfristig besser zu werden.

Nö, das machen die Grossen Firmen mit ihren BWL Schlipsen schon lange 
nicht mehr.

Sie warten, bis eine Kleine Firma ein interessantes Projekt erfolgreich 
umgesetzt bekommt und kauft dann einfach die Kleine Forma auf - für viel 
zu wenig Geld, denn sie zahlt nur den Erfolg, die 100 anderen Kleinen 
Firmen, die es auch mit Innovation versucht haben aber gescheitert sind 
zahlt sie nicht.

Damit hält sich die Grosse Firma die Fehlschläge vom Leib und der BWL 
Schlips ist zufrieden. Der gesamten Wirtschaft fehlen damit 
finanzkräftige Entwicklungen, so daß viele Projekte, die eigentlich 
technologisch reif wären und gemacht werden müssten, nie gemacht werden, 
da (wie geschrieben) die Grossen Firmen nichts investieren und die 
Kleinen Firmen solche Finanzierungen nicht stemmen können.

Das quartalsbilanzoptimierte Verhalten der BWL Schlipse ist also 
volkwirtschaftlich kontraproduktiv und fortschrittsverhindernd.

Nun ja, zum Verkaufen gehören Zwei und wenn eine kleine Firma wirklich 
etwas Marktfähiges hat, wird sie es nicht verschleudern, sondern selber 
das Geld abstauben. Meistens führt ein solcher Verkauf ja auch nur dazu, 
dass die Geschäftsführer das Geld rausziehen und in die Karibik gehen. 
Da kenne ich zwei Beispiele!!!  Die Entwickler ziehen weiter und bauen 
IHR Produkt dann wieder in einer neuen Firma weiter, womit in sehr 
kurzer Zeit wieder ein Konkurrent existiert und der Kauf nur ein 
Zeitvorteil ist. Spätestens beim zweiten mal geht die Grossfirma dann 
aber her und kauft gleich die Schlüsselentwickler mit.

Eine kleine Zwischenfrage sei gestattet:

Warum wohl gibt es für den klassischen Mikrocontroller kaum OO-Compiler, 
sprich C++, C# oder ähnliches? Vielleicht, weil der OO-Ansatz dort eben 
nicht sinnvoll ist, im Gegensatz zu einer Software, hinter der ein 
Betriebssystem wie Linux oder aber Windows steht.

M. E. reden hier die 2 Fraktionen aneinander vorbei. Für den klassischen 
Mikrocontroller ist OOP der falsche Ansatz. Für große Maschinen mit 
Betriebssystemen eher richtg. Übrigens wurden viele Betriebssytemkernel 
in C, also prozedural, programmiert, viele Compiler für OOP-Spachen 
auch.

Mal darüber nachdenken, ob man jedem Hype hinterher rennen muß, nicht 
umsonst hat sich C im Embedded-Markt bis heute halten können und alle 
anderen Sprachen, die so toll waren (z. B. Modula 2) sind verschwunden.

Darüberhinaus ist Stabilität im Embedded-Bereich ein hohes Gut, das man 
nicht eben mal aufgeben soll, weil ein junger Entwickler den alten Hasen 
zeigen will, wie viel besser es doch mit einer neuen Hype-Sprache geht. 
Den Endkunden interessiert ein stabiles Produkt und nicht das Werkzeug 
dahinter.

le x. schrieb:
> Wär mir nicht wert soviel Text für diese zu vergeuden, zumal der TE wohl
> eh nicht mehr reinschaut.

Also ich (TE) lese noch mit und beteilige mich teilweise auch an der 
Diskussion...

Die Diskussion driftet aber eher in die Richtung OOP vs. Konventionelle 
C-Programmierung. Ist zwar auch ein interessantes Thema, jedoch 
interessiere ich mehr eher für den Prozess der Softwarepflege an sich. 
Und wie er in "gestandenen" Unternehmen abläuft.

Ich habe ganz am Anfang von drei Kernproduktion gesprochen. Das eine ist 
unsere Automatisierungslösung in Old-school-C.
Wir haben jedoch auch eine Serverlösung im Angebot. Diese ist in Java 
und daher auch komplett Objektorientiert entwickelt.

Die Lösung ist ca. 12 Jahre alt. Hier wird zwar schön Objektorientiert 
entwickelt. Das Problem ist aber auch hier, dass es immer größer wird 
und die Qualität sinkt.
Am Anfang wurden große Teile der Anwendung Test-Driven entwickelt oder 
es waren zumindest viele Unit-Tests vorhanden.
Zwei der ursprünglichen Entwickler sind nicht mehr im Unternehmen und 
das ganze wurde von anderen so nebenher weitergeführt.

Mittlerweile ist das Resultat, dass 90% der Unit-Tests fehlschlagen, 
weil sich der Code geändert wurde und die Tests nicht nachgezogen 
wurden. Oder weil die Umgebung sich geändert hat.

Es wird auch sehr viel Code kopiert, da sinnvolle Vererbung zwar möglich 
wäre, aber die Leute keine Lust haben sich das genauer anzusehen. Lieber 
kopieren und bisschen was anpassen als sinnvolles Refactoring zu machen.
Doku gibts natürlich auch immer weniger.

Auch sowas ist ein Beispiel für mich, wo nicht in Produktpflege 
investiert wird. Hat also auch nichts mit OOP zu tun.

Für mich wäre Produktpflege an dieser Stelle:
- Code aufräumen
- Tests nachziehen
- Sinnvolles Refactorn
- Doku nachziehen

Man merkt mir meine Frustration vielleicht ja ein wenig an, aber die 
letzten Jahre sind einige Entwickler gegangen oder wurden entlassen.
Mit weniger Personal leisten wir von der Kundenanzahl und Aufträgen zwar 
wesentlich mehr, aber es hat sich eine Quick-and-Dirty-Kultur 
eingeschlichen.

Chef freut sich zwar, weil die Kunden uns die Tür einrennen und wir alle 
schnell und zufriedenstellend bedienen. Ich bin aber unzufrieden damit, 
wie wir die Arbeit machen. Weil wir es eben besser können.

Bernd K. schrieb:
> Ihr habt also einen Berg von ehemals guter Software geerbt (überliefert
> von Programmierern mit weißen Bärten im wohlverdienten Ruhestand) und
> eure neuen Programmierer haben keine Lust (!) sich irgendwie mit dem
> Produkt der Firma auseinanderzusetzen oder es gar zu verstehen und
> machen es daher mutwillig kaputt?

Leider nicht unbedingt mutwillig. Der Druck vom Management nötigt uns 
dazu, schnell zu arbeiten. So schnell, dass die Qualität leiden muss.
Da wir nebenher noch supporten, gibt es Wochen wo man keine 20min am 
Stück konzentriert arbeiten kann.

Bernd K. schrieb:
> lso wird ja wohl genug Geld da sein um noch ein paar Leute einzustellen
> um diese 20-Minuten-Unterbrechungen abzustellen und mal genug Zeit zu
> haben was gebacken zu bekommen was Hand und Fuß hat.

Dieses Geld sacken aber kurzfristig die GL ein und denken sich, es wird 
sowieso immer so weiter gehen, so lange es läuft, läufts halt. Von 
langfristiger Planung und Softwareentwicklung hat dort anscheinend kein 
Schwein eine Ahnung. So wie in meiner letzten Firma.

Keine Sorge, so eine Firma löst sich irgendwann von selbst auf oder wird 
geschluckt/zugesperrt und reorganisiert..

Die Manager denken dort nur quartalsweise und an ihre nächsten Boni. 
Dazu irgendwelche faulen Seilschaften und sogar noch selbst initiierte 
Schnellprogrammierwettbewerbe und das Chaos ist perfekt.

Bei manchen Posts erkenne ich schon ganz deutlich meinen AG wieder.
Da wird auch nicht sehr weit gedacht, zumindest nicht weiter als bis zum 
nächsten Quartalsabschluss.
Nachdem ein paar Mitarbeiter gegangen sind, leidet auch die Qualität.
Wir suchen nun aber auch schon eine ganze Weile nach weiteren 
Entwickler, leider hält sich das Bewerberaufkommen sehr in grenzen und 
was wirklich brauchbares war nicht dabei. Zumindest von dem was bei mir 
in der Fachabteilung noch an Bewerbungen ankam, ob eventuell schon 
vorher welche wegen den Forderungen aussortiert wurden, weiß ich nicht.

Leider steigt mittlerweile das Arbeitsaufkommen sehr und heute bin ich 
auch wieder am arbeiten, da es einige nicht so stabile Programme gibt, 
die zwar nur unter der Woche laufen, aber eben auch an einem Feiertag. 
Noch dazu werde ich dann das restliche Wochenende auch noch arbeiten um 
diese Instabilen Programme mal richtig zu "refactoren", sonst habe ich 
dieses Jahr keine Chance mal wieder einen Tag frei zu machen.

Hallo le,

le x. schrieb:
> Schade Karl Käfer, du hast hier eine wunderbare Erklärung verschwendet.

Vielen Dank! Aber wenn die Erklärung Dir gefallen hat, war es das wert.

Liebe Grüße,
Karl

Hallo MaWin,

MaWin schrieb:
> Karl Käfer schrieb:
>> Es geht nicht um die Prozesse, sondern um die Menschen.
>
> ISO9001/14001, also jede ernstzunehmende Firma ausser Hobbybastlern und
> Klitschen wie du, interessiert sich für die Prozesse, nicht für die
> Menschen, die sind austauschbar.

Wenn es darum geht, eine Unternehmenskultur zu verändern, geht es primär 
um die Menschen. Wenn die Deine Prozesse nicht benutzen, weil sie deren 
Nutzen nicht erkennen oder weil sie sie nicht beherrschen, fällst Du auf 
die Nase. Dann kannst Du zwar immer noch die Menschen austauschen, aber 
das ist immer deutlich teurer, als sie vom Nutzen besserer Prozesse zu 
überzeugen. Wer mit Menschenführung zu tun hat, weiß das.

> Die Ausrede, deines wäre ja kein konkretes Problem sondern nur ein
> Beispiel, und die wahren Gründe stecken in dem was nicht gezeigt ist,
> ziehen übrigens nicht, denn genau das ist das Problem der Schwätzer:
> Immer von Dingen schwätzen, die nicht real sind.

Meine Beispiele verdeutlichen, wie sich die OO aus prozeduralen 
Techniken entwickelt hat. Deine "Gegenbeispiele" zeigen hingegen wieder 
einmal nur, daß Du Dir die allergrößte Mühe damit gegeben hast, das 
absichtlich nicht zu verstehen um daran vorbei zu schwafeln. Sollte ich 
damit jetzt Mitleid haben, oder lieber darüber lachen?

> Karl Käfer schrieb:
>> Du glaubst, gutes UI-Design hätte was mit "BlinkBlink" zu tun? Heiligs
>> Blechle! Das ist doch wohl nicht Dein Ernst?!
>
> Du glaubst, gutes UI Design müsste "modern" sein und ist Mist, wenn es
> schon 10 oder 20 Jahre vor dir geschrieben wurde ?

Als bekennender Freund der Kommandozeile benutze ich täglich Programme 
mit buchstäblich jahrzehntealten UIs. Aber wenn Du heute ein 
Webinterface an den Kunden bringen willst, muß das schon ein bisschen 
besser aussehen als eine Hobby-Homepage wie diese [1]. Die ist übrigens 
nicht nur optisch ein gutes Beispiel dafür, wie man es nicht macht.

Liebe Grüße,
Karl


[1] http://www.oocities.org/mwinterhoff/

Hallo klausi,

klausi schrieb:
> Bernd K. schrieb:
>> lso wird ja wohl genug Geld da sein um noch ein paar Leute einzustellen
>> um diese 20-Minuten-Unterbrechungen abzustellen und mal genug Zeit zu
>> haben was gebacken zu bekommen was Hand und Fuß hat.
>
> Dieses Geld sacken aber kurzfristig die GL ein und denken sich, es wird
> sowieso immer so weiter gehen, so lange es läuft, läufts halt. Von
> langfristiger Planung und Softwareentwicklung hat dort anscheinend
> kein Schwein eine Ahnung. So wie in meiner letzten Firma.

Letztlich läuft so etwas immer auf die Personen hinaus. Wenn die GL oder 
die seit langer Zeit verbundenen MA darauf fokussiert sind, vor dem 
Eintritt in die Rente noch möglichst viel Geld für möglichst wenig 
Arbeit mitzunehmen, kommt es häufig zu solchen Effekten -- sogar dann, 
wenn dort jemand Ahnung von langfristiger Planung und 
Softwareentwicklung hat.

Die eigentliche Frage des OP war aber doch, wie man als AN damit umgehen 
kann. Und ich fürchte, daß einem da nicht viel mehr andere Möglichkeiten 
bleiben als jene, die ich in [1] dargelegt habe: gehen, Verbesserungen 
anbieten, oder abwarten, bis das Unternehmen stirbt.

Liebe Grüße,
Karl


[1] Beitrag "Re: Produktpflege in Softwareunternehmen"

>Du hast vermutlich sogar schon selbst in plain C des öfteren gewisse
>OO-Techniken angewendet ohne dir dessen bewusst zu sein. Das fängt
>schon an wenn Du irgendwann mal beim Aufräumen beschließt eine Handvoll
>zusammengehöriger Variablen die kreuz und quer herumfliegen in ein
>Struct zu stecken und alle Funktionen die damit zu tun haben von nun an
>einen Pointer auf so ein struct als Argument bekommen. Schon hast Du ein
>Objekt mit Methoden.


Recht optimistisch gedacht, wenn man das schon für OOP hält. Gerade aber 
das Offenlegen oder Sperren von Schnittstellen mit private, friend oder 
public, das Vererben ist ja im Mikrocontrollerbereich eher unüblich, da 
auch oft nicht sinnvoll. Selbst  new und delete gibt es da kaum, läuft 
alles noch über (m)alloc-Bibliotheken!
Konstruktoren/Destruktoren - Fehlanzeige!

PS.: Die massenhaften OO-Compiler für Mikrocontroller (außer ARM), 
sprich in C++, möchte ich gern sehen ;-)

Gut, einen Arduino hat man halt OO vergewaltigt, auch wenn die meisten 
Anwender gar nicht begreifen, was sie mit ihren zugekauften oder 
kopierten shields eigentlich anstellen. Wenn sie an die Basis wollen, 
werden sie wieder bei C landen.

Hallo Paul,

Paul Emil schrieb:
> Bernd K. (prof7bit) schrieb:
>>Du hast vermutlich sogar schon selbst in plain C des öfteren gewisse
>>OO-Techniken angewendet ohne dir dessen bewusst zu sein. Das fängt
>>schon an wenn Du irgendwann mal beim Aufräumen beschließt eine Handvoll
>>zusammengehöriger Variablen die kreuz und quer herumfliegen in ein
>>Struct zu stecken und alle Funktionen die damit zu tun haben von nun an
>>einen Pointer auf so ein struct als Argument bekommen. Schon hast Du ein
>>Objekt mit Methoden.
>
> Recht optimistisch gedacht, wenn man das schon für OOP hält.

Entschuldige, aber es sind genau solche Objekte, an denen sich die ganze 
Angelegenheit orientiert und deswegen "Objektorientierung" heißt. Genau 
damit hat die OO angefangen: Datenstrukturen und die Funktionen, die sie 
be- und verarbeiten, zu Einheiten zu verbinden. Also das, was Bernd K. 
(prof7bit) beschreibt und ich in [1] etwas ausführlicher aufgezeigt 
habe. Die Idee dahinter ist es, Seiteneffekte zu vermeiden, und 
Datenstrukturen ein "natürlicheres" Handling zu geben, welches an jene 
Dinge angelehnt ist, die die Datenstrukturen beschreiben. Aber, wie oben 
schon ausführlich erklärt: solche OO-Techniken hat man vorher auch schon 
benutzt, bevor die OO sie mit eigenen Sprachmitteln unterstützt hat.

> Gerade aber das Offenlegen oder Sperren von Schnittstellen mit private,
> friend oder public, das Vererben ist ja im Mikrocontrollerbereich eher
> unüblich, da auch oft nicht sinnvoll.

Die Datenkapselung, die Du ansprichst, gehört nicht zwangsläufig zur OO. 
Dabei dient sie ebenfalls der Vermeidung von Seiteneffekten, indem die 
Variablen der Struktur vor versehentlichen Änderungen geschützt werden. 
In der klasssischen C-Programmierung hat man "private" simuliert, indem 
man Variablen und Funktionen in eigene Dateien ausgelagert, sie als 
"static" deklariert und damit deren Sichtbarkeit auf die Datei 
beschränkt hat.

Übrigens ist diese Kapselung, wie wir sie aus C++ oder Java kennen, 
nicht immer Bestandteil der OO: diese gibt es vornehmlich bei streng 
typisierten Sprachen, damit der Compiler Zugriffe auf bestimmte 
Variablen verhindern kann. Andere OO-Sprachen mit dynamischer 
Typisierung und Autovivikation wie Python, Ruby oder Perl kennen keine 
Datenkapselung oder nur als Konvention -- da können sie nur emuliert 
werden, etwa mit Closures, was aber eher selten gemacht wird.

Die Vererbung und ihre wesentliche Grundlage, die Überladung, sollen die 
Wiederverwendbarkeit von Code verbessern und sind eigentlich eine 
logische Weiterentwicklung der vorgenannten Techniken und Konzepte. Daß 
sie häufig zu exzessiv angewendet wird, steht auf einem anderen Blatt 
und ist nicht die Schuld der OO, sondern der Entwickler. 
Nichtsdestotrotz ist die Vererbung tatsächlich eine Neuerung und 
konsequente Weiterführung der anderen OO-Techniken; in der prozeduralen 
Programmierung hat man so etwas meistens mit Kompositionen gelöst, die 
allerdings auch in der OO häufig das adäquatere Mittel sind.

> Selbst  new und delete gibt es da kaum, läuft alles noch über (m)alloc-
> Bibliotheken! Konstruktoren/Destruktoren - Fehlanzeige!

new() und delete() sind nur C++-Schlüsselworte, die intern nichts 
anderes machen als klassische Factory-Funktionen wie create_data_t() in 
[1]. Sie sollen die Speicherallokation vereinfachen, indem die 
Datenstruktur weiß, wieviel Speicher sie braucht, und die Größe des zu 
allokierenden Speichers dadurch nicht mehr aufwändig und fehleranfällig 
berechnet werden muß. Weil die Speicherverwaltung nach Untersuchungen 
rund 40% der Entwicklungszeit auffrißt und außerdem eine der 
beliebtesten Fehlerquelle ist, sollen new() und delete() diesen 
neuralgischen Punkt der Entwicklung vereinfachen und die damit 
verbundenen Fehlerquellen reduzieren. Übrigens gehören auch new() und 
delete() nicht zwangsläufig zur OO; zum Beispiel in Python ist der 
Konstruktor stattdessen eine Factory-Funktion.

Factory-Funktionen gibt es natürlich auch auf Mikrocontrollern, 
allerdings stellt dynamische Speicherallokation in den meist doch sehr 
überschaubaren Mikrocontroller-Programmen wohl eine Ausnahme dar. Das 
AVR-GCC-Tutorial auf dieser Seite empfiehlt: "Aus diesem Grund sollte 
man malloc() auf Mikrocontrollern sehr sparsam (am besten gar nicht) 
verwenden." Deswegen ist dieser Einwand letztlich ein kleines bisschen 
unsinnig -- schließlich kann man Variablen auch in C++ auf dem Stack 
instanziieren. Genau wie in C, denn C++'s "int a(5);" ist letzten Endes 
ja auch nichts anderes als ein "int a = 5;" in der prozeduralen 
Programmierung.

> PS.: Die massenhaften OO-Compiler für Mikrocontroller (außer ARM),
> sprich in C++, möchte ich gern sehen ;-)

Wenn Du das wirklich wissen willst, ist Google Dein Freund. ;-) Mir ist 
jedenfalls bislang noch keine einzige Mikrocontroller-Familie begegnet, 
für die es keinen C++-Compiler gibt. Kennst Du eine?

Liebe Grüße,
Karl


[1] Beitrag "Re: Produktpflege in Softwareunternehmen"

Udo Schmitt schrieb:
> Die es aber schon gab bevor der Begriff OO erfunden wurde.
> OO ist schon mehr als nur ein Struct statt Einzelvariablen zu benutzen.

Tja Udo,

du hast schon recht. Den Begriff gab es früher nicht. Trotzdem hat man 
schon objekt-orientiert programmiert, nur eben ohne dass es eine 
Bezeichnung dafür gab.

Und ja, Datenkapselung alleine macht OOP nicht aus, ist aber schon ein 
erster Ansatz.
Ob du also willst oder nicht, in dem Moment in dem du anfängst zu 
Modularisieren und Strukturieren verwendest du Konzepte die man heute 
als OOP bezeichnet. Auch wenn du rein in C unterwegs bist.
Da kannst du dich drehen und wenden wie du willst, das ist schon ein 
erster Ansatz von OOP. Aber das ist ja nichts schlimmes, davor muss man 
keine Angst haben.

Hallo Udo,

Udo Schmitt schrieb:
> Chris D. schrieb:
>> Aber wenn ich für meine Daten eine Kapselung vorsehe,
>> die den Zugriff nur über spezielle Schnittstellen erlaubt, dann ist das
>> objektorientierte Denkweise.
>
> Die es aber schon gab bevor der Begriff OO erfunden wurde.
> OO ist schon mehr als nur ein Struct statt Einzelvariablen zu benutzen.

Das haben schon Bernd K. (prof7bit) und Chris D. geschrieben, und meine 
Wenigkeit jetzt schon mindestens zweimal: es geht eben nicht nur um die 
Datenstrukturen, sondern vor allem um deren Bindung an ihre Funktionen.

> Wenn ich das lese:
> Bernd K. schrieb:
>> Das fängt
>> schon an wenn Du irgendwann mal beim Aufräumen beschließt eine Handvoll
>> zusammengehöriger Variablen die kreuz und quer herumfliegen in ein
>> Struct zu stecken und alle Funktionen die damit zu tun haben von nun an
>> einen Pointer auf so ein struct als Argument bekommen. Schon hast Du ein
>> Objekt mit Methoden.
>
> dann kann ich nur noch den Kopf schütteln. Das hat nun wahrlich noch
> nichts mit OO zu tun.

Doch, genau das ist der Ausgangspunkt des Ganzen, das habe ich nun schon 
zweimal beschrieben. Hast Du das nicht gelesen? Habe ich zu umständlich 
oder zu unverständlich formuliert? Was kann ich besser machen, damit Du 
meine Ausführungen lesen und verstehen kannst?

> Nur weil OO das Zusammenfassen von Daten (und
> Methoden) definiert heisst es noch lange nicht dass jeder, der Daten in
> eine irgendwie geartete Gruppe zusammenfasst, OO programmiert.

Wer Datenstrukturen und Funktionen zu Einheiten verbindet, nutzt 
letztlich eine objektorientierte Herangehensweise und erstellt genau 
solche Objekte, von denen die Objektorientierung ihren Namen hat. Da 
geht es um Objekte, verstehst Du, und um eine Problemlösungsstrategie, 
die sich an diesen Objekten orientiert. Alles andere, das wir heute mit 
dem Begriff der OO bezeichnen, sind nur Erweiterungen und Verfeinerungen 
diser Ideen.

Liebe Grüße,
Karl

Hallo Dennis,

Dennis S. schrieb:
> Kann es sein, daß Ihr hier gerne theoretisiert?
> Mit dem unterschiedlichen Verständnis von Begrifflichkeiten spielt?
> Fragen persönlicher Präferenzen und Befindlichkeiten diskutiert?

Ja, das kann sein. Aber vor allem wiederholen wir gerne, was schon fünf- 
oder zehnmal gesagt wurde...

> Man muß bei der praktischen Problemlösung doch sehr aufpassen:
> Daß OOP diese tatsächlich erleichtert und nicht zum puren Overhead
> degeneriert! Für jedes Problem die optimale Lösung!

...und da bist Du offensichtlich keine Ausnahme. Herzlich willkommen!

Liebe Grüße,
Karl

Hallo P.,

P. M. schrieb:
> Karl Käfer schrieb:
>> Alles andere, das wir heute mit
>> dem Begriff der OO bezeichnen, sind nur Erweiterungen und Verfeinerungen
>> diser Ideen.
>
> Wer Polymorphismus und Vererbung als "Erweiterung und Verfeinerung"
> deiner Struct-und-Funktion-OOP bezeichnet, der bezeichnet vermutlich
> mobiles Internet auch als "Erweiterung und Verfeinerung" des einfachen
> Sprechfunks.

Natürlich sind Polymorphie und Vererbung nur die logische 
Weiterentwicklung dieses Ansatzes und seiner Designziele. Daß Du dagegen 
nichts Besseres als solche kindischen Unterstellungen einwenden kannst, 
sagt ja genug. Pardon, aber mit Deinen Strohpuppen mußt Du leider 
alleine spielen.

Liebe Grüße,
Karl

Endlich mal ein guter Beitrag! Warum habt ihr aufgehört?