mardi 3 mars 2015
Warum wird OOP scheinbar von vielen Entwicklern abgelehnt?
Posted on 03:28 by verona
Hallo !
Habt ihr auch die Erfahrungen gemacht, dass viele Entwickler die OOP samt ihrer Konzepte in ihren Projekten teilweise vernichtend ablehnen?
Ich war zuletzt als externer Consultant und Programmierer in zwei verschiedenen Javaprojekten in unterschiedlichen Unternehmen eingesetzt, wo das exakt so zutraf. Konzepte wie Schnittstellen, allgemeine Abstrahierungen, Klassen und Methoden nach einer oder maximal zwei Zuständigkeiten (also hohe Kohäsion) zu designen und zu implementieren wurden vernichtend abgelehnt. Auch die Verwendung von Junit Tests oder der Einsatz von Stubs oder Mocks wurde eher als Nice to have angesehen und sämtliche Konzepte der OOP seien angeblich übertrieben, unnötig und "unverständlicher Müll".
Wenn man sich allerdings den Aufbau der bisherigen Systeme anschaute, fiel schnell auf, dass der Quelltext schwer lesbar, wenig bis gar keine Ausfallsicherheiten aufwies und was Zuständigkeiten anging, viele dortigen Aufgaben in Methoden und Klassen implementiert waren, die aufgrund ihrer Benamung und Paketzugehörigkeit eigentlich andere Dinge tun sollten. Somit wies der Code viele Seiteneffekte auf, die das Gesamtverhalten der System schwierig gestaltete. Auch beinhalteten viele Methoden teilweise bis zu 18 (!) Übergabeparameter.
Die Argumentation, dass die Konzepte der OOP hier für mehr Flexibilität sorgen könnte, wurde als Quatsch und "Overhead" abgestempelt. Auch war es wohl wenig von Interesse, dass das OOP Paradigma dafür sorgen kann, dass die Systeme bei neu zu implementierenden Anforderungen schnell, sicher und nachhaltig wachsen können. Die verbesserte Wartbarkeit im selben Atemzug zu nennen, machte keinen Sinn. Es wurde immer wieder durch die dort beschäftigten Mitarbeiter argumentiert, dass die Systeme schnell wachsen und angepasst werden müssen und der Code intuitiv verständlich sein soll (was wohl durch die OOP in den Augen der dortigen Entwickler nicht der Fall ist). Eine Argumentation, die ich häufig hörte: "Es macht keinen Sinn, wenn wir einen ganzen Tag brauchen, um ein Programm zu verstehen! Dann machen wir es lieber gleich neu!". Aus meiner Sicht war diese Argumentation wenig nachvollziehbar, wenn man in den bisherigen Systemen auf Klassen stößt, die bis zu 7000 Codezeilen beinhalten und einzelne Methoden While oder Forschleifen oder auch If else Blöcke haben, die vereinzelnt über 1000 oder mehr Codezeilen reichen.
Habt ihr solche Erfahrungen auch schon gemacht? Ich möchte nicht arogant und überheblich klingen, aber kann es vielleicht sein, dass viele Entwickler die OOP so heftig ablehnen, weil sie sie nicht vollständig verstehen? Ich weiß, dass diese Frage durchaus einen provokanten Beigeschmack hat, trotzdem hoffe ich auch interessante Meinungsäußerungen von euch.
Gruß
Maik
Habt ihr auch die Erfahrungen gemacht, dass viele Entwickler die OOP samt ihrer Konzepte in ihren Projekten teilweise vernichtend ablehnen?
Ich war zuletzt als externer Consultant und Programmierer in zwei verschiedenen Javaprojekten in unterschiedlichen Unternehmen eingesetzt, wo das exakt so zutraf. Konzepte wie Schnittstellen, allgemeine Abstrahierungen, Klassen und Methoden nach einer oder maximal zwei Zuständigkeiten (also hohe Kohäsion) zu designen und zu implementieren wurden vernichtend abgelehnt. Auch die Verwendung von Junit Tests oder der Einsatz von Stubs oder Mocks wurde eher als Nice to have angesehen und sämtliche Konzepte der OOP seien angeblich übertrieben, unnötig und "unverständlicher Müll".
Wenn man sich allerdings den Aufbau der bisherigen Systeme anschaute, fiel schnell auf, dass der Quelltext schwer lesbar, wenig bis gar keine Ausfallsicherheiten aufwies und was Zuständigkeiten anging, viele dortigen Aufgaben in Methoden und Klassen implementiert waren, die aufgrund ihrer Benamung und Paketzugehörigkeit eigentlich andere Dinge tun sollten. Somit wies der Code viele Seiteneffekte auf, die das Gesamtverhalten der System schwierig gestaltete. Auch beinhalteten viele Methoden teilweise bis zu 18 (!) Übergabeparameter.
Die Argumentation, dass die Konzepte der OOP hier für mehr Flexibilität sorgen könnte, wurde als Quatsch und "Overhead" abgestempelt. Auch war es wohl wenig von Interesse, dass das OOP Paradigma dafür sorgen kann, dass die Systeme bei neu zu implementierenden Anforderungen schnell, sicher und nachhaltig wachsen können. Die verbesserte Wartbarkeit im selben Atemzug zu nennen, machte keinen Sinn. Es wurde immer wieder durch die dort beschäftigten Mitarbeiter argumentiert, dass die Systeme schnell wachsen und angepasst werden müssen und der Code intuitiv verständlich sein soll (was wohl durch die OOP in den Augen der dortigen Entwickler nicht der Fall ist). Eine Argumentation, die ich häufig hörte: "Es macht keinen Sinn, wenn wir einen ganzen Tag brauchen, um ein Programm zu verstehen! Dann machen wir es lieber gleich neu!". Aus meiner Sicht war diese Argumentation wenig nachvollziehbar, wenn man in den bisherigen Systemen auf Klassen stößt, die bis zu 7000 Codezeilen beinhalten und einzelne Methoden While oder Forschleifen oder auch If else Blöcke haben, die vereinzelnt über 1000 oder mehr Codezeilen reichen.
Habt ihr solche Erfahrungen auch schon gemacht? Ich möchte nicht arogant und überheblich klingen, aber kann es vielleicht sein, dass viele Entwickler die OOP so heftig ablehnen, weil sie sie nicht vollständig verstehen? Ich weiß, dass diese Frage durchaus einen provokanten Beigeschmack hat, trotzdem hoffe ich auch interessante Meinungsäußerungen von euch.
Gruß
Maik
Warum wird OOP scheinbar von vielen Entwicklern abgelehnt?
Inscription à :
Publier les commentaires (Atom)
0 commentaires:
Enregistrer un commentaire