Es gibt eine Menge Ressourcen im Netz über best practises in der Programmierung, Design Patterns, sowie Erfahrungsberichte. Eigentlich sollten wir, als logisch handelnde Informatiker, doch durchweg auf höchstem Niveau programmieren. Meiner Meinung nach, ist das jedoch absolut nicht der Fall. Es scheitert an der individuellen Eitelkeit des Software-Nerds.
Ist es nicht das Schöne am Programmieren, dass man versucht das Handwerk zur Kunst zu machen? Dass man seinen Beruf vom stumpfen Umsetzer abgrenzt und Ansporn in täglichem Denksport findet? Dazu gehört, dass man sich ständig weiter entwickelt und ständig die eigene Reife in Frage stellt.
In der Realität trifft man jedoch viel zu häufig auf Entwickler, die diese Euphorie nicht teilen, die ihre Aufgabe im zügigen Abliefern verstehen und kreatives Software-Design eher als übertriebenen Perfektionismus sehen.
"Over-Engeneering!"
"Wir designen uns zu Tode!"
Der code ist unser Werkstück. Jeder würde dem Schreiner glauben, dass er respektvoll mit seinem Rohstoff Holz umgehen will. Dass er am Ende etwas Geschmackvolles abliefern will. Bei Software-Entwicklern gilt das oft als pedantisch. Eine schnelle Lösung, die nicht mehr tut als zu funktionieren, macht den Manager und Kunden glücklich- für den Moment.
"Nicht schön, aber funktioniert!"
"Schnell, simpel, läuft!"
Den Mehrwert einer Lösung von höherer Qualität erkennen die wenigsten Programmier-Laien, ein hochwertiges Schreinerstück hingegen ist landläufig einfacher zu verkaufen.
Hansen:
Eckstein, ich glaube du siehst das vielleicht ein wenig verbissen. Die meisten Entwickler wissen wann Code nicht optimal ist. Sie setzen den Fokus nur nicht gemäß deiner Ideale. Viele Anwendungen oder Bibliotheken haben eine absehbare Lebenszeit- vier, fünf Jahre vielleicht. Lohnt sich da immer der, sorry, Perfektionismus?
Eckstein:
Ja, ich gebe zu da hast du nicht ganz unrecht. Code wird sowieso nie perfekt sein. Jedoch glaube ich, dass sich aus sorgsam entworfenem Code viel mehr weiterer Nutzen ziehen lässt. Und, dass schlechter Code schwer wartbar und erweiterbar ist, ist doch allgemein bekannt. Ich glaube wirklich, dass viele Entwickler sich gar nicht bewusst sind, dass sie schlechten Code schreiben. Und der Grund ist, dass sie desinteressiert sind am Stand der Diskussion um beste Verfahrensweisen.
Hansen:
Ja, schon mal gesehen. Kann es aber sein, dass das auch zum großen Teil die Nachwuchs-Entwickler sind? Die musst du heraus rechnen! Ich denke am Anfang war deine "Weisheit" auch noch um einiges geringer! Letztens sah ich, dieses treffende Diagramm auf Twitter:
The path from beginner to expert pic.twitter.com/YmMH66vG5K
— Vala Afshar (@ValaAfshar) 4. November 2014
Eckstein:Du hast Recht, den Junior-Developers würde ich fehlende Erfahrung nicht vorwerfen wollen. Vielleicht ist das Problem ja nicht so groß, wie es sich subjektiv anfühlt. Aber jeder Senior, der noch schlechten Code produziert, hat meiner Meinung nach seine Berufsehre verletzt.
Ich glaube, viele sehen es falsch, und setzen "Erfahrung" mit dem Umfang der Kenntnis aktueller Technologien gleich. Die einzelne Code-Zeilen, die Interface und Methoden werden zum lediglichen Zusammenkleben von Frameworks herunter gehackt. Dabei sind die Basis-patterns und Prinzipien doch die wertvollsten, elementaren "Wahrheiten". Sie bieten doch auch viel mehr Raum für Kreativität und intellektuellen Impuls als das Nachjagen nach fertigen Ideen Anderer!
Hansen:
Okay, siehst du eine Lösung des Desasters?
Eckstein:
Leider nicht in absehbarer Zeit. Die Informatik ist im Bereich der Code-Qualität noch sehr am Anfang. Automatisiert ist es derzeit nur vage möglich Code als gut oder schlecht zu identifizieren. Klar, sollten Qualitäts-Tools, wie Checkstyle, Findbugs und Co, in jedem Projekt die Regel sein. Diese leisten bereits gute Arbeit bei der Verringerung grundlegender Programmierfehler.
Mein Anliegen gilt jedoch der Qualität auf der höheren Schicht, dem Design! Die "weichen" Strukturmerkmale, wie Unveränderlichkeit, Kapselung, die SOLID Prinzipien vor allem, sind noch viel zu unterbewertet! Bei der Automatisierung ist die Wissenschaft hier noch ganz am Anfang. Es kommt immer noch auf die individuellen Fähigkeiten an. Programmiersprachen sind noch nicht weit genug um diese Metaebene zu unterstützen und werden es vielleicht niemals sein.
Liegt es vielleicht in der Natur der Sache? Ist Programmierung ein Handwerk und wird es immer sein, gebunden an den Ausführenden? Dann wäre es eine Kunst? -- Auch keine schlechte Sichtweise!
Hansen:
Lass uns das im Auge behalten! Ich denke das Qualitätsprodukt wird sich immer behaupten!
Kaffee?
Eckstein:
Ja
Keine Kommentare:
Kommentar veröffentlichen