Hallo, ich arbeite in einem kleinem Software-Unternehmen (20 Mitarbeiter). Unsere Alleinstellungsmerkmale sind meiner Meinung nach: 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 Wir haben 3 große Kernprodukte, die wir für ca. 80% der Kundenwünsche einsetzen und relativ flexibel anpassen können. (Die anderen 20% erfüllen wir dann mit individuellen Entwicklungen, diese sind jetzt aber nicht relevant.) Alle Kundenanpassungen und natürlich auch Bugfixes fließen jeweils in die Hauptentwicklungszweige ein. Die gewünschten Features werden dann über Konfigurationseinstellungen aktiviert. Ich sehe schon seit einigen Jahren, dass unsere Kernprodukte durch die ganzen Anpassungen immer weiter wachsen und unübersichtlich werden. Auf Grund unserer Unternehmensgröße und der geringen Entwicklungszeit ist dann natürlich auch die Dokumentation schlecht bis nicht vorhanden. 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. Ich bin schon zweimal vorgeprescht und habe neue Konzepte inkl. Proof-Of-Concepts für die Kernprodukte vorgestellt. Dies ist auch jeweils sehr gut bei der Geschäftsführung angekommen. Wir haben aber keine Ressourcen, um die Umsetzung voranzutreiben, so dass die Projekte wieder einschlafen. Auch ich musste mich dann immer wieder dem „Tagesgeschäft“ widmen, da dies ja die Kohle reinbringt. Mich würde interessieren, wie das bei euch in den Unternehmen gehandhabt wird? Wo liegt der Fokus dort? Gibt es genug Resourcen für „Produktpflege“? Gruß Hermann
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 :(). Ein weiteres Problem ist die Dokumentation/Produktpflege selbst. Ich habe früher auch programmiert und habe auch heute noch viel mit Entwicklung zu tun. Und es ist klar zu sehen, dass viele mit Leidenschaft neuen Code schreiben, aber sich bei Dokumentation/Versionspflege sehr schwer tun. Das ist schlicht nicht so interessant wie sich mit neuen Problemlösungen zu befassen ;).
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.
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. Anderswo laufen noch Cobol- und Fortran-Programme aus den späten 60'ern. Und das ist kein Witz, sondern Realität.
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.
Ehrlich, was ist das Problem? Das Ding verkauft sich offensichtlich und ist offensichtlich wartbar. Mehr als man von der meisten Software sagen kann. Strukturiere neuen Code so, wie man das heutzutage mach und baue saubere Schnittstellen in den alten Code zu deinem neuen Code ein. Und nimm für deinen hoffentlich noch langen zukünftigen Berufsweg mit, dass Software, die auf Wartbarkeit ausgelegt ist, einen höheren Wert darstellt, als nach jeweils aktueller Mode und Hype voll aufgepimpter Müllcode.
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.
@Hermann (Gast) >Eines unserer Kernprodukte (eine Steuerungslösung) wird seit 25 Jahren >immer weiter entwickelt. Unter der Haube wird aber noch nicht einmal >objektorientiert gearbeitet. Was kein Nachteil sein muss. Es reicht(e), wenn es halbweg strukturiert und mit einem guten Grundkonzept ausgestattet ist. >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. Ist eben so. Wirst du in 30 Jahren ähnlich sehen. Neu ist nicht zwangsweise besser. >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. Wollen sie es nicht, weil es nicht cool und hipp ist, oder können sie es technisch WIRKLICH nicht? >Das Problem ist allerdings, dass für den Endkunden diese Neuentwicklung >keine Vorteile bringt, da die alte Lösung sehr stabil läuft. Also! Das ist ja VOLLKOMMEN nebensächlich! (Wer Ironie findet, darf sie behalten) >Man muss alle bestehenden Features unterstützen, da erwartet wird das >ein neues Produkt mindestens das kann, was das alte leistet. Logisch. >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. Möglich. Dann rechne mal betriebswirtschaftlich-logisch, und nicht aus Sicht des Nerds, der gern die neuesten Spielzeuge haben will. - Wieviel wird die Neuentwicklung schätzungsweise kosten? - Wie hoch ist die Gefahr, dass das Projekt aus dem Zeit- und Kostenrahmen läuft (was ja besonders bei Software mal ganz fix geht!) - Wieviel Kosten entstehen schätzungsweise, wenn der alte Code mit "höherem" Aufwand in der Zukunft gewartet werden muss? >Interessiert mich halt, ob es bei anderen besser läuft. Man will ja >nicht vom Regen in die Traufe kommen. Never change a running system. Besonders nicht bei Software! Schau dir mal SAP an, die Oberfläche ist auch alles andere als Up To Date, trotzdem wird es massenhaft verkauft und die Jungs machen ordentlich Kasse!
> 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: > Nur Leider passt >> und noch ein paar If Schleifen drum herum > da nicht so ganz... > http://www.if-schleife.de/ 10 INPUT "Gibt es IF-Schleifen", A$ 20 IF A$<>"NA, KLAR!" THEN GOTO 10 30 PRINT "Siehste?! :-)"
Klingt nach typischem Reengineering: 1. Tests bauen, die alles abdecken (Code coverage !) 2. Alten Code entfernen 3. Restlichen code aufraeumen ! Braucht natuerlich Zeit / Man-Power, und wird deshalb von Management gerne herausgeschoben. Normalerweise muss es schon echt brennen, damit so etwas gemacht wird. Was oft nicht funktioniert ist "wir schreiben alles neu, und zwar viel besser !" Vgl. Netscape...
@Hermann (Gast) >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. Naja, das ist schon heftig! >Keiner hat hier mehr den Durchblick, wann der Automat in welchen Zustand >springt, da Ballast von langer Zeit mitgeschleppt wird. Das liegt aber nicht an 25.000 Zeilen sondern schlechter Formatierung und Struktur! >Die Folgezustände hängen natürlich von diversen kundenspezifischen >Parametern ab. Haben Zustandsautomaten nun mal so an sich. > Jede Änderung kann hier bedeuten, dass andere Sachen > nicht mehr funktionieren. Und was willst du da machen? Den Automaten in mehrere Dateien zerlegen? Wird er dann besser, übersichtlicher? >Dieser Molloch ist tatsächlich gespickt mit Kommentaren von 1998, >geschrieben von Mitarbeitern die seit 10 Jahren nicht mehr im >Unternehmen arbeiten. Umso aufwändiger und gefährlicher ist es, den umzubauen/neuzubauen. Hast du eine VOLLSTÄNDIGE Testumgebung? >Ich glaube nicht, dass das was mit hipp oder cool zu tun hat... Klingt abert teilweise so. >Man will diesen Haufen am liebsten nicht anfassen. Dann tu das auch nicht. > Aber um Kundenwünsche >zu erfüllen, wird jeder Wunsch da irgendwie mit Biegen und Brechen >eingebaut. In der Hoffnung, dass keine Seiteneffekte auftauchen. Ist das nicht fast immer so?
klausi schrieb: > 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. Da wird noch die eine oder andere Firma irgendwann sehr grosse Augen machen. 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. In der Software-Abteilung hingegen unternimmt niemand etwas gegen Code-Moloche, die nur noch mit solchen Feuerwehr-Einsätzen unter Kontrolle gehalten werden können. Da wird man wohl erst noch lernen müssen, dass einem dies irgendwann genau so existenzbedrohend um die Ohren fliegt, wie ein Chaos in den Finanzen oder ein verlotterter Maschinenpark.
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. (o-o) >Da wird noch die eine oder andere Firma irgendwann sehr grosse Augen >machen. In der Wartung eines Maschinenparks oder in der Finanzabteilung ^^^^^^^^^^^^^^ >ist völlig klar, dass man sauber und nachhaltig arbeiten muss und das Jaja, das gilt bestimmt auch für Staaten wie USA und BRD . . . >"Feuerwehr-Prinzip" nichts verloren hat. In der Software-Abteilung Nichts ist so dauerhaft wie ein Provisorium.
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: > 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". Investition nur so viel und nur dort, wo der Kunde gerade bezahlt. Das hat doch nichts mehr mit Unternehmertum zu tun. Wie soll sich die Firma da weiterentwickeln können? Mich jedenfalls wundert dann nicht, warum diese Firmen permanent mit dem Messer am Hals herumlaufen.
@ P. M. (o-o) >Investition nur so viel und nur dort, wo der Kunde gerade bezahlt. Das >hat doch nichts mehr mit Unternehmertum zu tun. Wie soll sich die Firma >da weiterentwickeln können? Mich jedenfalls wundert dann nicht, warum >diese Firmen permanent mit dem Messer am Hals herumlaufen. In welcher Form können wir deinen unternehmerischen Weit- und Durchblick in der Praxis begutachten?
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.
Falk Brunner schrieb: > In welcher Form können wir deinen unternehmerischen Weit- und Durchblick > in der Praxis begutachten? Du fällst in letzter Zeit damit auf, dass du bei jedem dieser Threads nicht diskutieren, sondern bloss Leute mit anderer Meinung diskreditieren willst. Fakt ist, dass ernstgmeinte Technologiefirmen allesammt eine grosse Forschungsabteilung haben, wo an Dingen geforscht wird, lange bevor sie ein Kunde bezahlen will. Mag sein, dass dies für den 500sten Automobil-Zulieferer keine Option ist, aber dann darf man sich eben auch nicht wundern, wenn man sich wie eine Herde Schafe von Auftrag zu Auftrag gehetzt wird und total abhängig von Laune und Konjunktur sehr weniger Leute wird.
@ P. M. (o-o) >> In welcher Form können wir deinen unternehmerischen Weit- und Durchblick >> in der Praxis begutachten? >Du fällst in letzter Zeit damit auf, dass du bei jedem dieser Threads >nicht diskutieren, sondern bloss Leute mit anderer Meinung >diskreditieren willst. Das muss ich gar nicht, das tun die meisten selber. Frei nach Volker Pispers: Im Prinzip wie Eunuchen. "Sie wissen wie man's macht." >Fakt ist, dass ernstgmeinte Technologiefirmen allesammt eine grosse >Forschungsabteilung haben, wo an Dingen geforscht wird, lange bevor sie >ein Kunde bezahlen will. Das ist gar nicht das Thema. Die Bude hat 20 Leute. Ich wäre dir dennoch verbunden, wenn du sagen könntest, wo sich deine Ansichten zum Thema Softwarepflege in DEINER Praxis bewährt haben. Und wie dieser zum Wachsen und Gedeihen einer Firma beigetragen haben. Dann genau DAS hast du behauptet.
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
Christian H. schrieb: > Zum Thema OOP: > http://mollyrocket.com/casey/stream_0019.html > Sehr lesenswert! Die erste Hälfte des Textes rantet er darüber was OOP doch für eine Zeitverschwendung sei um dann in der zweiten Hälfte zu demonstrieren wie er ein konkretes Problem der Wiederverwendbarkeit löst indem er das Objekt Panel_Layout einführt (komplett mit Konstruktor, ein paar Methoden und einer Hand voll Feldern). Und das was er da glaubt erfunden zu haben nennt er dann auch noch irreführenderweise "shared stackframe". Dabei ist es einfach nur OOP in seiner reinsten Form.
:
Bearbeitet durch User
Hi, ich bin kein SW-Entwickler, arbeite aber in einer größeren IT-Firma Tür an Tür mit der SW-Entwicklung. Für mich liest sich das alles so, als ob das bei euch noch alles ziemlich "old school" abläuft. Nicht (nur) in Bezug auf die Programmiersprache, sondern in Bezug auf eure SW-Entwicklungsstrategien bzw. Abläufe. Das Problem ist, ohne Ressourcen (also Arbeitskraft) werdet ihr das mal "Nebenbei" nicht stemmen können, aber das hast Du ja auch schon erkannt. Ohne euer Produkt genau zu kennen, kann ich nur mal beschreiben wie es bei uns abgelaufen ist: Viele unserer Produkte sind auch an der Basis historisch gewachsen, d.h. C Code, teilweise nur durch den eigentlichen Entwickler noch wartbar, Technologien die nur noch mit Workarounds unter den aktuellen Laufzeitumgebungen laufen etc. Tja, da ist man dann hingegangen und hat die Sachen "from scratch" neu implementiert - unter Berücksichtigung der Erkenntnisse aus dem alten Produkt und aktuellen Softwareentwicklungsstandards (Programmiersprache, Code Style, Tests, etc. - wie gesagt, bin kein SW Spezi). Man muss dazu sagen, dass es quasi Teams gibt die nur den alten Kram noch warten und auch Teams die an neuen Sachen arbeiten. Solange euer Produkt natürlich "in sich" abgeschlossen ist, also nicht dem Druck der Erneuerung durch die Umgebung ausgesetzt ist und auch nicht sonstige große Vorteile durch eine Erneuerung der Basis zu erwarten sind, wird es schwer das zu rechtfertigen. Bei uns war die Neuarchitektur bzw. Re-Implementierung durch eine bessere Skalierung (Applikationsserver etc.) und auch aufgrund der Unwartbarkeit des vorhandenen Codes gegeben.
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.
Bernd K. schrieb: > Christian H. schrieb: >> Zum Thema OOP: >> http://mollyrocket.com/casey/stream_0019.html >> Sehr lesenswert! > > Die erste Hälfte des Textes rantet er darüber was OOP doch für eine > Zeitverschwendung sei um dann in der zweiten Hälfte zu demonstrieren wie > er ein konkretes Problem der Wiederverwendbarkeit löst indem er das > Objekt Panel_Layout einführt (komplett mit Konstruktor, ein paar > Methoden und einer Hand voll Feldern). > > Und das was er da glaubt erfunden zu haben nennt er dann auch noch > irreführenderweise "shared stackframe". Dabei ist es einfach nur OOP in > seiner reinsten Form. Er kritisiert nicht, dass die Sprache objektorientierte Konstrukte bietet, sondern nur das Paradigma, dass alles ein Objekt sein müsste. Sich zu Beginn krampfhaft zu überlegen, wie man alles in Objekte pressen kann führt zu viel schlechterem und komplexerem Code, als einfach simple Funktionen zu schreiben, die ihre Aufgabe ausführen und möglichst seiteneffektfrei zurückkehren. 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, musste ich an den Artikel denken.
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
Karl Käfer schrieb: > 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. 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.
:
Bearbeitet durch User
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
Nachdem mittendrin das getrolle losging hab ich in der Mitte aufgehört zu lesen, also wurde es vielleicht schon gesagt: Auch für kleine Firmen ist eine Stetige weiterentwicklung wichtig, um nicht den Anschluss zu verlieren. Wie es klingt ist eure Software gerade in der Blüte seines Produktlebenszyklus'. Damit wäre es an der Zeit ein neues Produkt anzugehen. Am Anfang mit nur 20 Leuten wäre es angebracht, wenn sich 2-3 Leute zu 50% mit einer neuen Software-lösung beschäftigen.Zunächst mal einen Anforderungskatalog erstellen und nach geeigneten Werkzeugen suchen (Codegeneratoren, Progammiersprachen...). Wenn es Konzept steht stellt man 2 weitere MA ab, die sich mindestens zu 80% mit dem neuen Produkt beschäftigen. Mit etwas Glück hat man ein verkaufsfähiges Produkt bevor das alte vom Markt verschwindet und man kann zügig alle MA auf das neue Produkt umstellen. 3-4 MA verbleiben als Support für das alte Produkt. Einer unserer Mitbewerber hat an seiner Weiterentwicklung gespart. Jetzt verliert er bei jeder Angebotsrunde gegen uns, weil seine veralteten Lösungen zu teuer/unflexibel sind. Die Forschung an der neuen Produktgeneration hat bei uns Millionen gekostet und Jahre gedauert, aber die Zuknunft der Firma gesichert. Die neue Generation unterstützt Anfangs nicht alles, was die alte konnte, aber für manchne Kunden waren die neuen Features wichtiger. Außerdem konnten sie als Early-adopters die Entwicklung bei uns in eine bestimmte richtung lenken.
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
Hi, MaWin schrieb im Beitrag #4106972: > Karl Käfer schrieb: >> Ich nehme zur Kenntnis, daß es eine ganze Reihe von Leuten gibt, die den >> Ansatz von OO nicht verstanden. > > Es reicht, das zu zitieren. Armer Karl. Wiso? Er hat ja (in diesem Punkt) völlig recht! Es gibt Leute die können hervorragend prozedural programmieren, aber bei OO Programmierung kommt im besten Fall etwas irgendwie funktionierendes raus - wenn überhaupt. Genauso gibt es Leute die brilliante OO Programmierer sind, aber bei prozeduraler Programmierung entweder versuchen Krampfhaft Obektorientierung nachzubauen oder gleich völligen Spaghetticode produzieren. Die meisten bewegen sich natürlich zwischen diesen Extremen, wenn auch mit deutlicher Spezialisierung in einem der beiden Paradigmen. Programmierer die beide Paradigmen aber gleich GUT (mit Betonung auf GUT! Gleich schlecht hingegen gibt es zu genüge...) beherrschen, die gibt es äusserst selten. Ich persöhnlich habe noch keinen getroffen. Und ganz sicher zähle ich mich auch nicht selbst dazu. (Ich wage zwar zu behaupten das ich einigermaßen brauchbar OO Schreiben kann, aber wirklich fit bin ich nur in prozeduraler Programmierung - einfach weil diese und nicht OO mein täglich Brot ist. Was natürlich nicht heisst das ich nicht willens & fähig wäre meine Fertigkeiten in OO zu vertiefen wenn es mal nötig werden sollte. Aber im Moment bin ich da von der OO Spitzenliga noch ein ganzes Stück entfernt...) 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. 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. Aber in der breiten Masse ist die Codebasis bei den Mikrocontrollern sicher um einiges älter. Es ist einfach so: OO hat ihre Stärken. Aber auch die prozedurale Programmierung hat Ihre Stärken. Und beide haben ihre Schwächen. In beiden Varianten kann man so schreiben das es Übersichtlich und auch lange wartbar ist. 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. 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... 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!
Hi, Karl Käfer schrieb: > 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 Also ehrlich gesagt, zwischen den Zeilen lese ich dasselbe! Hermann schrieb: >... Unter der Haube wird aber noch nicht einmal > objektorientiert gearbeitet. 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 - Obwohl dem TE durchaus bekannt ist: 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. Hermann schrieb: > 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. 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. Neben dem Kritikpunkt zur Unübersichtlichkeit kommen aber dann nur die Kritikpunkte -Keine OO und altes Design-. Also eine Funktionierende Lösung die aus drei Gründen verändert werden soll. Aber zwei der drei Gründe, gerade die Gründe welche eine völlige Neuentwicklung mit allen Risiken erfordern, lesen sich für mich -wie sicher für viele andere auch- als reiner Selbstzweck. Den Kritikpunkt "Unübersichtlichkeit" lasse ich natürlich uneingeschränkt gelten. Wobei natürlich bei Komplexen Projekten mit OO durchaus einfacher Übersicht geschaffen werden kann. Aber halt nicht ausschließlich. Das sich was tun muss ist also klar. Das vorhaben etwas zu ändern kritisiert der Christian ja auch gar nicht. Nur würde ich halt genau wie vorher von anderen mehrmals schon richtig geschrieben, gerade bei dieser Ausgangslage und dieser Personalsituation, es nicht Knall auf Fall mit einer kompletten Neuentwicklung machen sondern einfach Anfangen und ab sofort stärker Modularisieren und vor allem jede Codestelle die man anfasst sauber nach den aktuellen Regeln neu aufbauen. Zum Ändern muss man diese Codestelle ja eh komplett versthen, dann kann man einen evtl. entstandenen Wuschelcode an dieser Stelle auch gleich sauber neu fassen ohen das es größere Mehrarbeit wird. Wenn tatsächlich auch mal Leerlauf sein sollte dann die Codestellen die man nicht zwingend anpacken muss vornehmen. Ja nach Konzept und Fähigkeiten bei der Modularisierung könnte man sogar nach und nach Objektorientierung einbringen wenn man diese unbedingt haben muss. So entsteht mit der Zeit aus diesem Codemonster ein Code der nicht nur so gut läuft wie jetzt schon, sondern der zudem auch noch übersichtlich und gut zu warten ist... Und das mit nur geringem Mehraufwand gegenüber dem sowieso zwingend notwendigen täglichen Arbeiten. Aber die Hinweise in diese Richtung zu denken wurden bisher ja Konsequent übersehen. Hermann schrieb: > Dieser Molloch ist tatsächlich gespickt mit Kommentaren von 1998, > geschrieben von Mitarbeitern die seit 10 Jahren nicht mehr im > Unternehmen arbeiten. Ja , und wo ist das Problem? Zumindest wenn die Codestelle wegen derer dieser Kommentar geschrieben wurde auch noch enthalten ist, DANN SOLLTE es sogar so sein. Etwas anderes wäre es natürlich wenn der Kommentar sich auf dinge bezieht die so schon gar nicht mehr vorhanden sind. Gruß Carsten
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: > 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. Genau das habe ich ja hier auch gemacht und auf das Geantwortet was da stand. Interpretiert hast du dann - beispielsweise: > 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! Das ist z.B. reine Interpretation deinerseits das dies ganz verschiedene Dinge sind. Du interpretierst in beide Begriffe eine unterschiedlichkeit herein die es so gar nicht zwingend gibt. Beide Begriffe bezeichnen einen längeren Zeitraum in dem die Software immer wieder angepackt wird. (Wobei sich das immer wieder anpacken bei mir erst durch den Kontext verbindlich ergibt). Nicht mehr - aber auch nicht weniger. Alles andere ist reine Interpratation von DIR! > > 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. JA, solchen Umgang mit Firmware etwas gibt es... Aber es gibt genauso eine Menge Firmware wo jeden Tag daran gearbeitet wird, wo im Wochentakt neue Iterationen für die die Kunden erzeugt werden werden (Z.B. Kundespezifische Anpassungen)- Nicht zuletzt aber ist es doch so das es oft nicht mehr einen einzelnen Firmwarequellcode für ein GErät gibt. Zumindest wenn man eine breitere Palette an GEräten hat, so betreibt man schon eine gewisse Modularisierung. Da hat man sich seine Module für bestimmte Aufgaben geschrieben, Sagen wir mal beispielsweise TCP-IP Kommunikation, und bindet diese Module dann in seine Firmware ein wo diese Funktionalität gefordert ist. Um mal bei deiner Weißen Ware zu bleiben (Einen ZWeig für den ich nie gearbeitet habe, also nur als Beispiel verstehen), da läuft dann im Internet-fähigen Kühlschrank der selbe TCP-IP Stack der auch in der Waschmaschine arbeitet. Wobei sich die Waschmaschine zusätzlich auch noch die Display Ansteuerung und das Bedienmenue mit der Mikrowelle und das eigendliche KErnprogramm nur mit anderer Parametrierung mit der Spülmaschine teilt. Das ganze dann für Zig Hardwarevarianten - sowohl über unterschiedliche Bauserien wie auch innerhalb derselben BAuserie wenn wieder mal ein Zulieferer nicht liefern kann oder der Einkauf eine Quelle die noch 1/2 Cent/Stück günstiger ist entdeckt hat.... > Und > auch aus Gründen von Updatemechanismen und Zertifizierungen kann man es > sich nicht leisten, ständig an solcher Software herumzuentwickeln. Noch einmal: Es geht gerade bei Firmwarewartung oft nicht um Änderung am bestehenden Produkt. Das macht man in den meisten Fällen nur wenn es wirklich nötig ist. (Bug oder man muss bei wesentlichen Features nachlegen um im MArkt weiterhin zu bestehen) Ganz oft geht es auch schlicht um NEUE Produkte deren Firmware aus einer bestehenden abgeleitet wird. Und da muss sowieso neu getestet und wenn (Überhaupt) eine Zertifizierung nötig ist auch neu zertifiziert werden. Das man in bestimmten Bereichen natürlich anders arbeitet - bzw. Arbeiten muss- wenn bestimmte hochkomplexe/teure Zertifizierungen im Raum stehen versteht sich von selbst. Aber in Zeiten wo µC selbst in (werbe) Wegwerfartikel für den einmaligen Gebrauch verbaut sind sich nur auf solche Systeme zu beziehen ist wohl etwas arg kurz gegriffen. > 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. Bei einer Waschmaschinensteuerung vielleicht, aber bei wesentlichen Teilen der Firmware die UNTER ANDEREM in dieser Wachmaschinensteuerung läuft gilt das danns schon nicht mehr. Von Industriezweigen die von Kundenspezifischen Lösungen leben ganz zu schweigen! > > 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. Für das Ändern bin ich wie gesagt anderer Meinung! Bei der Komplexität die du meinst kannst du vielleicht recht haben. Wobei auch große Teile der Probleme in der Firmwarewelt hochkomplex sind. Nur in anderer Hinsicht als wie du diese Komplexität verstehst. > 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. Mit der verwendeten Einschränkung "die meisten" kann ich zumindest dieses guten Gewissens unterschreiben... > Das ist eher das Serverumfeld, aber... Also gerade aus dem Serverumfeld kenne ich das gar nicht! Meisnt du vielleicht Mainframe statt Server? Denn ja - da ist ein großer TEil dieser Software zuhause... > Jedenfalls betreiben die diesen > Aufwand doch gerade deswegen, weil die vorhandene Software eben nicht > modular und darum nicht schrittweise austauschbar ist, - JA Das ist ein sehr häufiger Grund. > also, anders gesagt: weil die vorhandene Software eben keine OO-Software > ist.., UND DAS IST FALSCH! Du Stellst hier die Behauptung auf das "Modular == Übersichtlich == OO". Und zwar Exklusiv. Und das ist schlichtweg ABSOLUT FALSCH. Natürlich ist es leichter in OO Modularer zu schreiben weil das ganze Konzept dahinter in diese Richtung geht. Auch ist es einfacher eine Modulare Software wartungsfreundlicher zu halten als ein riesen Einheitsgebilde. Aber beides sind gerade KEINE Alleinstellungsmerkmale von OO. Auch in der Prozeduralen Programmierung kann man hervorragend Modularisieren. Man muss es nur wollen! Und auch die Übersichtlichkeit ist bei ernsthafter Absicht eine solche zu wollen in C & Co. in nahezu jeder Projektgröße absolut machbar. Ja, sogar in ASM kann man das noch brauchbar hinbekommen so lange eine gewisse Größe icht überschritten wird. Genauso bedeutet OO nicht zwangsläufig Modular und Übersichtlich. Auch hier muss man sich vorher Gedanken machen und wissen was man macht. Zudem würde ich behaupten in ein schlecht geschriebenes OO Programm findet man sich viel schwieriger zurecht als in einem OO Programm! > Auch bei überschaubarer Komplexität hat die OO ihre Vorteile, aber erst > bei höherer Komplexität kommen diese so richtig zum Tragen. Sehe ich anders, aber gut Meinungen können differieren. > >> 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. Aber dennoch richtig und wichtig! Aber ich denke du hast wieder etwas falsch interpretiert. Was ich ausdrücken wollte: Wenn ich Probelm habe dessen Lösung theoretisch in OO etwas eleganter möglich ist, aber einen Programmierer der sehr gut Prozedural programmieren aber nur schlecht OO schreiben kann habe, dann ist es trotz des Theoretischen Vorteils für das OO Paradigma doch viel schneller und sinnvoller das prozedural lösen zu lassen. Umgekehrt gilt natürlich dasselbe. Aber ehrlich gesagt -Ohne dir zu nahe treten zu wollen- kommt es mir so vor als wenn du von der kommerziellen Embedded Programmierung redest Karl Käfer schrieb: > wie ein Blinder von den Farben Um es mal mit deinen Eigenen Worten zu sagen. Sicher - im Bezug auf die PC Programmierung ist es bei mir nicht SOOO viel anders. Ich schreibe auf dem PC normalerweise nur einfache Testprogramme für unsere HArdware oder vielleicht mal ein einfaches Parametrierungsprogramm. Aber ich behaupte auch nicht das ich davon wirklich etwas verstünde! Ausserdem, ich weiß zwar nicht ob du dies tatsächlich so beabsichtigst, aber ich habe die ganze Zeit das Gefühl als wolltest du die Objektorientierte Programmierung als die alleinige Lösung aller Programmierprobleme darstellen und vor allem auch diejenigen die diese Beherschen als hohe Kunstschaffende die über die besondere Gabe verfügen dieses hochschwierige Thema verstanden zu haben, während alle anderen sich in den Niederungen der Prozeduralen Programmierung herumlungern. Dann will ich da mal klarstellen das dies definitiv nicht so ist! JA- Objektorientierte Programmierung macht in vielen Fällen sicher Sinn. Und wer Objektorientiert gute Programme schreiben kann hat meinen Respekt. Aber letztendlich ist es eine höhere Fähigkeit GUT Objektorientiert schreiben zu können als GUT Prozedural. Es ist nur anders! Denn wenn es so währe das OO Programmierer insgesamt die BESSEREN Programmierer sind die Ihre Kollegen aus der Prozeduralen Fraktion überflügeln, dann müssten die ja allesamt auch in der Lage sein gute Prozedurale Programme zu schreiben. SIND SIE ABER NICHT! OO ist nur ein anderes Paradigma das teilweise im Gegensatz zum Prozeduralen steht. Es erfordert eine andere Herangehensweise und je nach Übung und Neigung geht einem das eine oder das andere in FLeich und Blut über. Wie gesagt: Ich habe noch niemanden getroffen der BEIDES GUT konnte. Alle die ich erlebt habe und die das behauptet haben waren hingegen in beiden lediglich GLEICH SCHLECHT! Aber ich betone nochmals: ICh weiß nicht ob du das überhaupt ausdrücken wolltest. So kommt es bei mir halt nur rüber... Gruß Carsten
Karl Käfer schrieb: > Hallo Carsten, > > Carsten Sch. schrieb: > [...] >> 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... Und hier noch einmal der Hinweis. Ich habe geschrieben WAS ICH aus diesen Zeilen lese. Und mit meiner Interpretation bin ich offensichtlich nicht so ganz alleine. 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: Karl Käfer schrieb: > ...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. Wie gesagt - ICH verstehe das anders. 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. >> 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? Microsoft oder Apple bedienen ja nun einmal auch eine GANZ ANDERE Zielgruppe mit einer GANZ ANDEREN Art von Software. 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 das in vielen Bereichen eine Umstellung nahezu undenkbar ist, dann hätten die sich schon sehr viel blauere Augen geholt... 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 > >> 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. Oder er meint das zu sehen. 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. 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. > 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. Hier wieder volle Zustimmung... Gruß Carsten
Als Korrektur zum Obigen Beitrag: Carsten Sch. schrieb: > Zudem würde ich behaupten in ein schlecht geschriebenes OO Programm > findet man sich viel schwieriger zurecht als in einem OO Programm! Das ist so natürlich Schwachsinn, richtig soll es heissen: > Zudem würde ich behaupten in ein schlecht geschriebenes OO Programm > findet man sich viel schwieriger zurecht als in einem schlecht > geschriebenen prozeduralen Programm! MaWin schrieb: > 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. WENN es ein Code wäre der nicht angepackt werden muss, DANN WÜRDE ich dir sogar Recht geben. Aber so wie ich das Lese sind die da TÄGLICH im Code am Flickschustern ohne sicher zu sein was da überhaupt alles passiert. Es wird nur gehofft das keine Seiteneffekte auftreten... Dann doch lieber den Teil den man sowieso Ändern muss auch gleich sauber machen. Und wenn Luft ist den Rest auch mal trockene Tücher bringen damit man irgendwie vom Status "Vermuten und Hoffen" zu "Wir wissen zu 100% was wir machen" zurückkehren kann. > 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. In Angriff nehmen muss er den Code auf alle Fälle. ISt schließlich sein Job. Und wenn dann Fehler wegen der Überarbeitung einer Codestelle auftreten ist es doch am besten GERADE DANN wenn es NICHT drängelt. Denn wenn der Fehler erst auftritt wenn man an genau diese Stelle zwingend heranmuss und der Auslieferungstermin schon verstrichen ist, dann ist es definitiv der falsche Zeitpunkt. Das natürlich vor jeder vermeidbaren oder auch nur aufschiebbaren Codeänderung ein vernünftiges Testszenario ausgearbeitet und später auch umgesetzt werden muss, das versteht sich natürlich von selbst. (Eigentlich ja VOR JEDER Codeänderung, aber wir kennen wohl alle die Realität wenn die Termine all zu sehr drücken und der Vertrieb fast Amok läuft weil das Perpetuum Mobile nicht in einem Tag einsatzbereit ist...) > 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. Das ist im Grunde nicht einmal einen Kommentar wert. Aber was will man von jemanden der irgendwie auf dem Wissensniveau der frühen Neunziger Jahre steckengeblieben ist schon erwarten... (Nicht nur im Bereich der Programmierung übrigens) > 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. DAs wiederrum ist tatsächlich oft so. Aber auch nicht immer. Ich kenne einiges an gewachsener Software. Manches ist hervorragend, vieles ist OK. Aber nicht so selten wei man hoffen würde ist es im Laufe der Zeit nur noch Kraut und Rüben... Gruß Carsten
:
Bearbeitet durch User
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.
@ Hermann (Gast) >Schrittweises umstellen vs. komplette Neueentwicklung. >Soziale Komponente mit den älteren Kollegen >usw. Gute Frage. >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. AHA! >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. AHA!!!! >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. AHAAAAAA!!!! Aber DAS ist vor allem ein Problem der mangelnden Qualifikation der Jungen, nicht des alten Codes, wie schon mehrfach hier geschrieben!!!! >Da es sowieso extrem schwer ist hier im Ballungsraum >Entwickler-Nachwuchs für kleine Unternehmen zu finden, Warum? Ballungsraum = viele Leute auf kleinem Raum. Und die kommen nicht alle im Großunternehmen unter, auch wenn sie das vielleicht wollen. > 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?
> 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.
MaWin schrieb: > ist entschieden kürzer als deins, schneller überblickbar und genau so > änderungsfreundlich, läuft schneller und kostet weniger Speicher. Nein ist es nicht und weniger Speicher kostet es auch nicht, es kostet genau 8 Byte RAM. Aber es ist chaotischer und schwieriger zu verwenden, schwieriger an andere Funktionen zu übergeben, schwieriger wiederzuverwenden sollte man jemals mehr als eine Instanz davon brauchen, etc. > Es interessiert hingegen nicht, daß deines "erweiterungsbarer" und > "gekapselter" ist, wenn es nicht erweitert wird, Oh doch das interessiert! Wenn es nicht erweitert oder wiederverwendet wird dann ist das fast immer deshalb der Fall weil man es nicht erweitern oder wiederverwenden KANN ohne das halbe Programm umzukrempeln! Deshalb wird das nicht getan, nicht etwa deshalb weil man es nicht tun wollte. Stattdessen wird dann auf die Schnelle ersatzweise noch zusätzlicher unwartbarer Mist außenrumprogrammiert und hinzugefügt der das ganze nur noch chaotischer und noch unwartbarer macht!
:
Bearbeitet durch User
MaWin schrieb: > 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. Stimmt MaWin schrieb: > #include <stdio.h> > > int eins=1,zwei=2; > > int main(void) > { > printf("eins = %d, zwei = %d\n", eins, zwei); > printf("sum = %d\n", eins+zwei); > return 0; > } > > ist entschieden kürzer als deins, schneller überblickbar und genau so > änderungsfreundlich, läuft schneller und kostet weniger Speicher. Sehe ich genauso Das OO Beispiel oben ist ein tolles Beispiel von Programmierer der "reinen Lehre", die aus jedem kleinen Pups gleich eine Darm-OP machen wollen. Man kann mit OO wunderbar Probleme eleganter angehen als prozedural, aber das lohnt nur bei einer bestimmten Komplexität. Und man muss nicht aus allem gleich eine Klasse machen, ein Interface bauen etc. pp. Raus kommen dann oft genug Dinge, die man in 20 Zeilen hätte erledigen können, die dann aber in 8 Klassen gepackt wurden und man sich den Wolf sucht, bis man versteht was der Autor eigentlich gewollt hat.
Bernd K. schrieb: > Oh doch das interessiert! Hast du jemals ein großes Programm in der hand gehabt, das nicht von dir stammt. Mit groß meine ich mehrere 100 Dateien mit insgesamt mindestens 100000 Lines of Code. Darin findest du bei OO Programmen oft genug 3/4 toller erweiterbar gedachter Konstrukte, die entweder nie gebraucht wurden oder so "erweiterbar" angedacht waren, dass die tatsächlich notwendige Art der Erweiterung dann doch nicht ging. In der Realität gilt dann meist: "Erstens kommt es anders und zweitens als man denkt" :-)
Udo Schmitt schrieb: > Darin findest du bei OO Programmen oft genug 3/4 toller erweiterbar > gedachter Konstrukte, die entweder nie gebraucht wurden oder so > "erweiterbar" angedacht waren, dass die tatsächlich notwendige Art der > Erweiterung dann doch nicht ging. In der Software-Entwicklung herrscht oft eine Vorstellung, die, übertragen auf die Luftfahrt, dazu führen würde, dass irgendwelche Segelflieger in einem Wochenendkurs auf einen A380 umgeschult und diesen dann im Liniendienst fliegen würden. Richtig gut programmieren kann man noch relativ schnell, um aber wirklich grosse Projekte zu realisieren, braucht es eine umfangreiche Ausbildung im Software-Engineering. Informatik I und II im ET-Studium reichen da nicht. Das führt dann auch zu katastrophalem Missbrauch der OOP, weil die Leute das Werkzeug einfach nicht beherrschen.
"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
Holger74 schrieb: > 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! Sehe ich genauso. @Herrmann: Dein Problem ist eigentlich ziemlich weit verbreitet und meist nicht mit drei Schlagwörtern zu beseitigen. Allerdings habe ich schon öfter dabei den Eindruck gehabt, dass die Firmenleitungen kein wirkliches Interesse (oder die Mittel) hatten etwas zu ändern. Es kostet halt Zeit & Geld ohne kurzfristige Vorteile. Bevor da kein echter Wille ist, kannst Du wenig machen. Grüße Andreas
Andreas H. schrieb: > Allerdings habe ich schon öfter dabei den Eindruck gehabt, dass die > Firmenleitungen kein wirkliches Interesse (oder die Mittel) hatten etwas > zu ändern. Es kostet halt Zeit & Geld ohne kurzfristige Vorteile. Und genau darin unterscheidet sich eine gute Firma von einer schlechten. Eine gute Firma wird darin investieren, langfristig besser zu werden. Eine schlechte Firma lebt von der Hand in den Mund. Klar gibt es Kleinunternehmen, die finanziell so knapp leben, dass es gar nicht anders geht. Allerdings ist das langfristig eine gefährliche Strategie, da man dem wirtschaftlichen Wind und Wetter total ausgesetzt ist.
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.
P. M. schrieb: > Und genau darin unterscheidet sich eine gute Firma von einer schlechten. > Eine gute Firma wird darin investieren, langfristig besser zu werden. > Eine schlechte Firma lebt von der Hand in den Mund. Klar gibt es > Kleinunternehmen, die finanziell so knapp leben, dass es gar nicht > anders geht. Allerdings ist das langfristig eine gefährliche Strategie, > da man dem wirtschaftlichen Wind und Wetter total ausgesetzt ist. Jeder BWLer im zweiten Semester wird Dir zustimmen. Insbesondere weil Deine Aussage reflexiv ist (Eine gute Firma macht XXX und deswegen ist sie gut) Leider ist die Realität etwas komplizierter. Grüße Andreas
MaWin schrieb: > Das quartalsbilanzoptimierte Verhalten der BWL Schlipse ist also > volkwirtschaftlich kontraproduktiv und fortschrittsverhindernd. Leider wahr. Die Idioten können oft genug nur bis zur nächsten Quartals oder Halbjahresbilanz sehen.
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.
Schade Karl Käfer, du hast hier eine wunderbare Erklärung verschwendet. Perlen vor die Säue. Muss dich echt für deine Ausdauer bewundern. Aber mittlerweile weis doch eh jeder dass hier immer die gleichen 4-5 Hanseln aufschlagen und grundsätzlich dagegen sein müssen. Wär mir nicht wert soviel Text für diese zu vergeuden, zumal der TE wohl eh nicht mehr reinschaut.
Andreas H. schrieb: > Jeder BWLer im zweiten Semester wird Dir zustimmen. Insbesondere weil > Deine Aussage reflexiv ist (Eine gute Firma macht XXX und deswegen ist > sie gut) > > Leider ist die Realität etwas komplizierter. Nein, die Realität ist genau so. Die Realität mag sein, dass nicht jede Firma Geld für langfristige Verbesserungen hat. Das ändert aber nichts daran, dass sich eine Firma auf sehr dünnem Eis bewegt, wenn sie nicht in langfristige Verbesserungen ihrer Produkte und Produktivät investiert oder investieren kann.
Hermann schrieb: > Mich würde interessieren, wie das bei euch in den Unternehmen gehandhabt > wird? > Wo liegt der Fokus dort? Gibt es genug Resourcen für „Produktpflege“? Je nach Firma gibt es sogar ein festes Zeitkontinent pro Sprint fuer Refactoring, zB. 10%. Das reicht natuerlich nur fuer kleinere Aenderungen, aber wenn diese staendig durchgefuehrt werden kann es erst gar nicht so dick kommen ;) Es gibt IME natuerlich so etwas wie den "Point of no return", d.h. SW die zu lange "verrottet" ist (immer wieder nur Code draufwerfen anstatt die Altlasten zu bereinigen), danach wird es sehr teuer das wieder einigermassen hinzubekommen, so teuer, das sich das so gut wie nie lohnt.. ISO 9001? Toller Witz, hab schon bei Ruestungsunternehmen erlebt wie diese Zertifikate sozusagen "gekauft" wurden.. "Individuals and interactions over processes and tools" Na wer kann das zuordnen? :) Starre, Buerokratische und verkrustete Prozesse ohne Ruecksicht auf die echten Beduerfnisse und Anforderungen fuehren zu sinkender Qualitaet, alles schon erlebt. Veraltete und ueberfluessige Prozesse aendern bzw. anpassen? Ne, wer will denn schon sein ISO Zertifikat neu machen... Die Frage des OP war ja nach SW Unternehmen, da will ich mal sehen welches SW Unternehmen noch nicht in OO unterwegs ist, seit Jahren geht ein Trend zurueck zu den funktionalen Sprachen, Prozedural wie C, Pascal/Delphi etc. ist IMHO bei reinen SW Unternehmen viel weniger anzutreffen, zumdest wenn diese etwas mit "Web Technologien" zu tun haben. Sobald es aber um Mikrokontroller bzw. HW geht, ist C sicherlich sehr verbreitet. Zum Thema OOP: Man glaubt ja nicht wieviele Menschen OO immer noch nicht kapiert haben, selbst wenn sie Jahrelang in einer OO Sprache programmieren.. da werden munter Vererbungshierarchien aufgebaut um Code wieder verwenden zu koennen :( Vom Liskovschen Substitutionsprinzip hat kaum einer gehoert, Composition over Inheritance hat man schon mal gehoert aber ignoriert es, aber Hauptsache erstmal erben wenn man Code wiederverwenden will :D
:
Bearbeitet durch User
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.
Paul Emil schrieb: > M. E. reden hier die 2 Fraktionen aneinander vorbei. Für den klassischen > Mikrocontroller ist OOP der falsche Ansatz. 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.
Paul Emil schrieb: > Warum wohl gibt es für den klassischen Mikrocontroller kaum OO-Compiler, > sprich C++ Für alle nennenswerten µC gibts das, sogar für AVR.
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.
Hermann schrieb: > 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. Keine Lust? 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? Wirf sie raus. Achtkantig.
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.
@ Hermann (Gast) >> 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. Klingt ziemlich schlecht. Klingt aber auch nach einem klassischen Managementfehler. Denn DIE müssen eigentlich wissen, dass man LANGFRISTIG so nicht durchkommt. Ihr lebt im Moment von der Substanz. Irgendwann wird sich das rächen. Aber wer denkt heute noch langfristig. Und wenn es eine GANZE Woche so hektisch ist, dass man nicht mal ne halbe Stunde zusammenhängend Ruhe hat, ist sowieso VERDAMMT viel im Argen!
Hermann schrieb: > Da wir nebenher noch supporten, gibt es Wochen wo man keine 20min am > Stück konzentriert arbeiten kann. Naja, von selbst wird sich der Code nicht wieder aufräumen. Wenn ihr zu wenig Leute habt müsst ihr welche einstellen. Mindestens einer (besser zwei) müssen sich so tief und so lange einarbeiten wie sie eben dazu benötigen (es dauert nunmal so lange wie es dauert) und ohne ständig von der Arbeit abgehalten zu werden, so lange bis sie den Code in und auswendig kennen und sich dann auch mal trauen können ein größeres Refactoring anzupacken, wohl wissend daß sie es ungestört zu Ende führen können. Diese beiden werden dann auch bei jeder geplanten Erweiterung Auskunft geben können ob diese so implementiert werden kann oder wie man es am besten implementieren soll oder ob man es jetzt nicht implementieren kann sondern erst wenn die Punkte 23 bis 46 auf der Todo-Liste abgehakt sind und vorher nicht und wenn die sagen "geht so nicht" dann ist Gesetz. Punkt. Wenn die Geschäftsleitung womöglich aufgrund eures selbst angezettelten Schnellprogrammierwettbewerbs ("geht nicht gibts nicht, 4 Wochen? Wir schaffen es in 2 Stunden, wir sind die Helden") nun mittlerweile in einer vollkommen realitätsfernen Phantasiewolke lebt dann ist es höchste Zeit sie wieder auf den Boden der Tatsachen zurückzuholen. Beim nächsten Sonderwunsch also lautet die Antwort: "Geht leider nicht, nicht bevor [lange Liste] erledigt ist". Du sagst der Laden brummt und die Kunden rennen euch die Türen ein, also 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.
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
Bernd K. schrieb: > Du sagst der Laden brummt und die Kunden rennen euch die Türen ein, also > 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. Ja Bernd, das wäre vernünftig. Aber wie ich schon oben sagte: Andreas H. schrieb: > Allerdings habe ich schon öfter dabei den Eindruck gehabt, dass die > Firmenleitungen kein wirkliches Interesse (oder die Mittel) hatten etwas > zu ändern. Es kostet halt Zeit & Geld ohne kurzfristige Vorteile. > > Bevor da kein echter Wille ist, kannst Du wenig machen. Man bräuchte halt etwas mehr Hintergrundinformationen um die Situation richtig beurteilen zu können. Grüße Andreas
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"
Karl Käfer schrieb: > 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. Was du beschreibst, nenne ich schlicht und einfach Modularisierung. Nur weil man sich dabei auch so etwas wie "Objekte" bastelt, ist das noch keine OOP. Das Herz und die Seele jeder OOP-Sprache ist die Idee, dass für ein Objekt ein Interface definiert wird, hinter das man über Vererbung und Polymorphismus eine beliebige Implementation packen kann.
P. M. schrieb: > Karl Käfer schrieb: >> 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. > > Was du beschreibst, nenne ich schlicht und einfach Modularisierung. Nur > weil man sich dabei auch so etwas wie "Objekte" bastelt, ist das noch > keine OOP. Das Herz und die Seele jeder OOP-Sprache ist die Idee, dass > für ein Objekt ein Interface definiert wird, hinter das man über > Vererbung und Polymorphismus eine beliebige Implementation packen kann. Er schreibt deswegen ja auch: "Genau damit hat die OO angefangen." Dass in der reinen Lehre noch mehr dazugehört, streitet Karl sicher nicht ab. Ich programmiere auch objektorientiert, wenn ich nur einen Teil dieser Philosophie einsetze. Wenn keine Vererbung benötigt wird, muss ich auch nichts vererben. Wenn ich keinen Polymorphismus benötige, werde ich ihn nicht verwenden. Aber wenn ich für meine Daten eine Kapselung vorsehe, die den Zugriff nur über spezielle Schnittstellen erlaubt, dann ist das objektorientierte Denkweise. Ob man das Binden von Funktionen an ihre Daten dann Kapselung oder wie in der (vermeintlich) prozeduralen Welt Modularisierung nennt, ist letztendlich egal. Objektorientierte Programmierung ist nicht von der Existenz einer OOP-Sprache bzw. nicht vom Einsatz aller zur Verfügung stehenden Paradigmen abhängig. Damals, als in meiner Info-Studentenzeit OOP aufkam, stand das in einem Buch schön, wenn auch etwas flapsig beschrieben, worin sich (unter anderem) OOP von prozeduraler Programmierung unterscheidet: "Nicht mehr quasi allmächtige Funktionen werden auf wehrlose Daten losgelassen sondern Objekte bitten sich höflich um die Erledigung bestimmter Aufgaben." :-) Das Problem, das einen wirklich sauberen OOP-Ansatz schwierig macht, ist, dass man bei Erstellung des Modells bereits die Flexibilität und Erweiterbarkeit einbauen muss, die dann üblicherweise noch gar nicht gefordert wurde (kennt ja jeder aus der Softwareentwicklung: Software steht und nach ein bis zwei Jahren kommt: "Könnten Sie nicht noch eben ..."). Gleichzeitig darf das Modell aber auch nicht zu allgemein werden. Sonst vererbt man sich tot ;-)
:
Bearbeitet durch Moderator
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. 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. 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. Hier wird mal wieder notendige mit hinreichender Bedingung verwechselt.
:
Bearbeitet durch User
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. Klassisch sind Vererbung, Polymorphie und Kapselung die Grundelemente von OO. Weder definiert ein Element alleine OO, noch lassen sich diese Konzepte ausschließlich mit OO erreichen.
Chris D. schrieb: > Ob man das Binden von Funktionen an ihre > Daten dann Kapselung oder wie in der (vermeintlich) prozeduralen Welt > Modularisierung nennt, ist letztendlich egal. Das ist ja genau der Unterschied zwischen Modularisierung im allgemeinen und OOP im speziellen: In der OOP definiere ich das Interface und kann dann jede Implementierung verwenden, die es erfüllt. Das kannst du mit deinem struct+Funktion-Ansatz definitiv nicht. Deshalb ist auch nicht jedes Programm, das Klassen verwendet, wirklich objektorientiert.
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.
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. Natürlich - die OOP entstand ja nicht aus dem Nichts :-) > OO ist schon mehr als nur ein Struct statt Einzelvariablen zu benutzen. Das sicherlich. Aber man kann das schon als einen ersten Schritt hin zu OO sehen. > dann kann ich nur noch den Kopf schütteln. Das hat nun wahrlich noch > nichts mit OO zu tun. 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. > Hier wird mal wieder notendige mit hinreichender Bedingung verwechselt. Mir scheint es so zu sein, dass man hier die reine objektorientierte Programmierung und "objektorientiertes Denken" unterscheiden muss. Ich muss aber gestehen, ich habe mittlerweile habe ich hier in dem Thread den Überblick verloren, wer jetzt mit wem unter welchen Voraussetzungen welches "Teilproblem" ausdiskutiert :-)
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
Kann es sein, daß Ihr hier gerne theoretisiert? Mit dem unterschiedlichen Verständnis von Begrifflichkeiten spielt? Fragen persönlicher Präferenzen und Befindlichkeiten diskutiert? 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!
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
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.
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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.