[bissel OT] Grundsatzdisskussion pro/contra Objektorientierung

[Kryptaesthesie]

Guten Tag,

des Öfteren kommt hier im Büro (3 Java-Entwickler - einige andere für Altsysteme Cobol-Entwickler --> Chef auch) die Disskussion auf, warum eigentlich Objektorientierung?!
Leider hat sich ein bisschen eingebürgert alles auf ein Problem hin zu programmieren und nicht allgemeingültig zu denken und zu entwickeln.
Und uns wird nicht die Zeit eingeräumt uns über eine Struktur Gedanken zu machen und für unseren Geschmack ordentlich objektorientiert zu programmieren.
Bei Datenbanken das selbe: "es geht doch auch mit einer Benutzertabelle" --> Normalisierung? Was ist das?

Ich kann mich nicht mit dem Gedanken anfreunden Codewulst zu schreiben ...

Nur, wie soll man argumentieren, dass sich im Endeffekt der Mehraufwand am Anfang (Planung, Engeneering mit UML, usw.) auszahlt?
Müssen wir wirklich erst einmal auf die Nase fliegen und können auf einen der vielen Änderungswünsche nicht reagieren, weil der Code nicht flexibel genug ist

Was würdet ihr für Argumente anbringen, um nicht immer aus Zeitnot unschönen, ungeplanten Code zu schreiben (der schon zu oft nicht mal ne Woche überlebt hat)?

So, fertig mit Heulen


Hoffe, ich bin doch im richtigen Forum! Wusste nicht so richtig, wo ich das Thema hätte eröffnen sollen?!

Gruß
Gerrit

 

[Oliver Gierke]

Nur, wie soll man argumentieren, dass sich im Endeffekt der Mehraufwand am Anfang (Planung, Engeneering mit UML, usw.) auszahlt?
Müssen wir wirklich erst einmal auf die Nase fliegen und können auf einen der vielen Änderungswünsche nicht reagieren, weil der Code nicht flexibel genug ist

Kurze Antwort: JA! Nicht der Entwickler entscheidet, ob die finanziellen Mittel bereit gestellt werden um saubereren Code zu schreiben, sondern die BWL Abteilung. Und die reagieren leider zu oft erst, wenn der Leidensdruck (Kosten für eine Änderung) immens hoch wird. Im Endeffekt ist das natürlich absurd, da umso mehr man die Software verpfuscht, die Neuentwicklung auch teurer wird. D.h. neues verkrüppeltes Feature kostent 10K, komplett Neuschreiben 15K. Mit dem neuen Feature kostet ein weiteres Feature 15K (weil das Ding halt noch komplexer geworden ist), die komplette Anwendung aber 17K (weil das "neue" Feature ja auch mit in die neue Anwendung geschrieben werden muss.

Das ist ein Teufelskreis, der aber in der Wirtschaft alles andere als eine Ausnahme ist. Leider. Wenn es allerdings so exorbitant längert dauert sauberen Code zu schreiben, anstatt ihn hinzurotzen scheinen die Kollegen aber auch nicht sonderlich fähig zu sein. Desweiteren kann man eigentlich nur der Meinung sein ohne OO ginge alles einfacher, wenn man noch nie nicht-triviale Probleme vor sich hatte, die es einfach verlangen, dass man Belange gruppiert, Probleme zerlegt usw.

Es kann mir niemand erzählen, dass er den Benefit eines sauber strukturierten Programms gegenüber einem zusammengeschusterten nicht erkennt. Das 80% der Kosten einer Software in die Wartung gehen, sollte hinreichend bekannt werden. D.h. ihr habt scheinbar Projekte bisher angefangen und sie aber auch recht schnell wieder abgegeben ohne sie lang weiterzupflegen. "Lang" meint in diesem Fall Jahre... ich habe hier mit Systemen zu tun die etwa 1 Mannjahr Initialentwicklung benötigen und dann ca. 10-12 Mannjahre weiter gepflegt werden. Da kommt sicher keiner auf die Idee mal eben Geschäftslogik in die View zu packen, nur weil es "eben" schneller ginge. Allerdings ist das in Software die wir zur Pflege übernehmen oft nicht so (wahrscheinlich bekommen wir sie genau deswegen zur Pflege ).

Für dich persönlich musst du halt entscheiden, inwieweit dir Qualität und (noch wichtiger) das Bewusstsein dafür wichtig ist. Sicher findest du in jeder Firma Prozesse, Tools und Methodiken, die man (auch recht offensichtlich) verbessern kann. Solang man sich firmenintern aber dessen bewusst ist und daran arbeitet ist das kein Problem. gefährlich wirds, wenn man nicht merkt, dass man es schleifen lässt und das für "normal" hält. Survival of the fittest... gut so IMHO.

Bzgl. der Diskussion OO VS. (? ja was eigentlich): Schätzt doch einfach mal die KOnsequenzen ab, gerade in Bezug auf: Ich bekomme den Code in 1 Jahr wieder zu Gesicht. In der Zwischenzeit haben 3
andere Entwickler daran gearbeitet. Ich soll jetzt ein weiteres Feature einbauen.

Andererseits - und da bin ich wieder am Anfang - lernt man das nur, wenn man mal mit sowas auf die Fresse gefallen ist .

REINHAUN!

 

[CSANecromancer]

Müssen wir wirklich erst einmal auf die Nase fliegen und können auf einen der vielen Änderungswünsche nicht reagieren, weil der Code nicht flexibel genug ist

Ich muß Oliver leider Recht geben: Ja. "Ihr" (nicht unbedingt die Entwickler, aber die Entscheidungsträger) müsst erstmal eine Bauchlandung machen, bevor sich was bessern kann. War bei mir hier exakt das gleiche.

Eine Uraltsoftware, noch mit Visual Studio 6 geschrieben. Aussage dazu immer (und zwar von denjenigen, die die Budgetzuteilung vorgenommen haben, also nicht von technisch versierten Leuten): "Dat hebt schon noch, dat kannste noch erweitern, das kriegste schon." Diese Software arbeitet u.a. mit Digitalkameras zusammen. Und da kommen eben pro Jahr mehrere neue Modelle raus.

Jetzt war wieder so ein Modellwechsel angesagt. Und die Kamerasteuerungen sind bei der alten Software fest in den Code verdrahtet gewesen. Von Plugins oder sauber getrennten Interfaces hatten diese Entwickler wohl noch nichts gehört. Ich sagte: "Es kommt billiger, wenn ich das ganze Programm in die Tonne trete und neu entwickel, als wenn ich jetzt auf Biegen, Brechen und Kotzen die neue Kamerasteuerung noch mit reinpfriemel." Nein, ich sollte die Uraltsoftware erweitern. Und dafür habe ich einen Kostenvoranschlag eingereicht.
Und zwar einen realistischen.

2 Tage später waren Prokurist, Betriebsleister, Abteilungsleiter etc. bei mir im Büro und verlangten eine Rechtfertigung für diese exorbitante Summe. Da konnte ich die dann ein bißchen durch den alten Source Gassi führen, was dann endlich zur Diskussion führte, ob sich nicht doch eine saubere Neuentwicklung unter Beibehaltung der OOP lohnen würde.

Das kam aber eben (um den Bogen zu schlagen) erst, nachdem die Wartung der alten, hingefrickelten Software so aufwändig und teuer wurde, daß sich dies in - für das Management spürbaren - harten Zahlen niederschlug und Kundenanfragen nicht mehr zeitnah und mit vertretbarem Aufwand umsetzen ließen. Vorher wurden alle Einreichungen meinerseits, daß die Software dringend überarbeitet, besser noch neu entwickelt werden müsse, ignoriert.

 

[Kryptaesthesie]

Danke für die Kommentare, ihr beiden
Dann werde ich wohl einfach mal abwarten, auf den Knall warten und dann hoffen, dass es dann schöner wird.

Aber es hilft mir schon mal zu sehen, dass es wo anders durchaus ähnliche Zustände gibt!

Gruß
Gerrit