Zitat von
Delphi_Fanatic:
Beispielsweise kannte ich schon mal ein Team, bei dem man erstmal eine etliche hundert Seiten dicke Dokumentation durchlesen musste, in der alle Standards, Richtlinien und Nomenklaturen dokumentiert sind, ehe man dort überhaupt nur eine einzige Zeile Code programmieren kann.
Teams, die das tun, sind dann oftmals schon mehr damit beschäftigt, sich selbst zu verwalten als was Brauchbares zu programmieren. Und der Kunde bekommt dann für selbst noch so kleine Änderungen / Erweiterungen wahnwitzige Aufwandsschätzungen von zig Mann-Tagen präsentiert. Solange, bis der Kunde sich eine andere Software-Firma sucht, und das erste Team mit samt seinen Nomenklaturen, Standards und sonstigem Wichtigtuer-Spielkram beim Arbeitsamt landet. Dumm gelaufen.
Oder bis andere Firmen, die dieses System nicht einsetzen genaus aus diesem Grunde z.B. Regierungsaufträge nicht erhalten, weil Sie bei der Ausschreibung erst gar nicht berücksichtigt werden.
Ich habe - bevor ich mir gedacht habe ein Diplom würde sich recht gut machen - bei einer Firma gearbeitet die Software für Krankenhäuser entwickelt. Fakt ist: Man bekommt keine Aufträge wenn man nicht garantieren kann das die Software strukturiert und gemäß eindeutig festgelegter Richtlinien entwickelt wird. - Es könnten hier nämlich unter Umständen Menschenleben davon abhängen ob ein Bug in der Software ist oder nicht.
Es gibt also durchaus Bereiche, in denen eben diese von Dir 'angeprangerte' Verhalten die wirtschaftlich einzige Sinnvolle Lösung ist, weil die Kunden eben abspringen würden würde man dieses organisierte Verhalten ändern.
Genauso ist es mit dem
OOP-Konzept. Robert hat das richtig erkannt:
OOP wurde vielleicht erfunden, weil es jemandem ungeheuer cool vorkam. Es hat sich aber offensichtlich nur deshalb durchgesetzt, weil es den Entwicklern die
OOP einsetzen einen (wirtschaftlichen) Vorteil gegenüber denen eingeräumt hat, die es nicht tun. Andernfalls wäre
OOP schon eine Totgeburt gewesen, denn einen Nachteil verzeiht die Wirtschaft nicht.
Andersrum: Ein Konzept zu verwenden, das sich in den letzten Jahren bereits als Nachteilig gegenüber einemn anderen Konzept herausgestellt hat kann sich letzten Endes nur Nachteilig auf die Wirtschaftlichkeit des Projektes auswirken.
Irgendwann wird der Zeitpunkt kommen, an dem die erwähnten 10 Jahre alten Programme abgelöst werden müssen. (Beispiel: .NET setzt sich durch, alles was nicht .NET ist wird nicht mehr lauffähig sein). Es wird dann aber mit grossem Aufwand verbunden sein, alten prozeduralen Code weiterzuverwenden bzw. zu portieren. Wahrscheinlich wäre man schneller, wenn man alles neu schreibt. Verwendet aber bereits heute für neue Module bereits reines
OOP kann man zumindest diesen Code (bzw. diese Klassen) grösstenteils auch später noch weiter verwenden. Und wieder die Frage: Was ist hier wohl wirtschaftlicher?
Auch den
UML-Hype kann ich aus diesem Grunde nicht verstehen. Es zeigt sich immer mehr, das
UML einfach nicht das Leistet was sich viele davon versprochen haben. Wer heute bei einem neuen Projekt noch auf
UML setzt wird einen Nachteil gegenüber denen haben, die sich den Stress sparen und auf Methoden setzen, die durchgängiger und flexibler sind.
UML wird in Zukunft immer unwichtiger werden, bis es irgendwann einmal in den Schulbüchern steht wie jetzt SA: Es war einmal...