Suche
Auf den Einsatz kommt es an

Vier gute Absichten beim Coden – die direkt in die Programmierhölle führen

Michael Thomas
shutterstock_174454463-2

© Shutterstock/Kletr

Codeoptimierungen, Softwareabstraktionen, Programmierwerkzeuge, plattformübergreifende Anwendungen: alles Dinge, die stellvertretend für das Gute im Programmiereralltag stehen. Oder doch nicht? Anna Sopova, Medienvertreterin des API-Anbieters Apico hat kürzlich einige Szenarien nachgezeichnet, in deren Rahmen die genannten Techniken und Technologien alles andere als heilsbringend sind. Dabei schnappen die Fallen genau dann zu, wenn man im Grunde das richtige tut – ganz dem Motto „Der Weg zur Hölle ist mit guten Vorsätzen gepflastert“ folgend.

Gute Absicht Nummer 1: Codeoptimierungen

Optimierter Code ist an sich eine wunderbare Sache, ist er doch potentiell aussagekräftiger, effektiver und ressourceneffizienter als nicht optimierter Code. Allerdings lauern in diesem Zusammenhang gleich zwei Gefahren, glaubt man Sopova.

So besteht ihrer Ansicht nach eine Falle, in die mitunter selbst die erfahrensten Programmierer tappen, darin, dass verfrüht optimiert wird, also beispielsweise Abkürzungen eingeschlagen werden, die sich später als unnötig oder gar schädlich entpuppen. Die andere Seite der selben Medaille ist Sopova zufolge zu spät optimierter Code: Werden Optimierungen erst gegen Ende des Entwicklungsprozesses vorgenommen, muss im Zweifelsfall ein großer Prozentsatz des Codes umgeschrieben, ja manchmal sogar gut funktionierender, sauberer Code entfernt werden.

Gute Absicht Nummer 2: Abstraktionen

Abstraktionen unterstützen Programmierer bekanntlich dabei, die Komplexität eines Problems zu reduzieren; gute Abstraktionen spielen beispielsweise bei der Wartbarkeit von Code oder bei der Wiederverwendbarkeit von Layern eine Rolle. Sie sind Sopova zufolge jedoch nicht immer nützlich.

Zum Beispiel dann, wenn ein Programmierer nichts von spezialisierten Funktionen hält und statt dessen ausschließlich auf extrem generalisierte Funktionen zurückgreift und ein universelles Framework schafft, dessen Funktionalität im realen Einsatz nicht einmal ansatzweise ausgeschöpft wird.

Vor allem bei unerfahrenen Programmierern, die erstmals mit einer neuen Sprache arbeiten, kommt laut Sopova noch eine andere Vorgehensweise zum Tragen: Der komplette Verzicht auf Abstraktionen. Denn: Die Beschäftigung mit Abstraktionen kostet subjektiv viel Zeit; sie zu ignorieren hat – im direkten Vergleich zum Verzicht auf Iteratoren oder Monaden – auf den ersten Blick weniger Nachteile, weshalb sie auf der Prioritätenliste weit nach unten rutschen.

Gute Absicht Nummer 3: Programmierwerkzeuge

Die Fülle an Werkzeugen und Bibliotheken, die Entwicklern heutzutage zur Verfügung steht, ist beinahe unüberschaubar geworden – und täglich kommen neue hinzu. Wenig verwunderlich also, dass auch hier Gefahren lauern.

Das erste von Sopova skizzierte Bedrohungsszenario: Entwickler, die davon ausgehen, dass alle Werkzeuge, die sie brauchen könnten, bereits existieren und deshalb ausschließlich auf schlüsselfertige Tools von Drittanbietern zurückgreifen. Als ein Symptom dieser Denkungsart bezeichnet Sopova die Unfähigkeit, ohne IDE (samt Autokorrektur) arbeiten zu können. Demgegenüber sollten Programmierer Sopova zufolge immer, zumindest potentiell, in der Lage sein, das Rad neu zu erfinden, sprich (bei Tools) selbst Hand anlegen zu können (eine Haltung, die Robert C. Martin gefallen dürfte).

Am anderen Ende dieser Skala finden sich laut Sopova diejenigen Programmierer, die das Rad ständig neu erfinden, sprich beispielsweise ununterbrochen Funktionen von Grund auf neu schreiben (und dabei die in existierenden Bibliotheken bereitstehenden Äquivalente gekonnt ignorieren) und für die Begriffe wie IDE, Debugger oder Profiler Fremdwörter sind. Eine solche Haltung kostet Sopovas Erfahrung nach schlicht zu viel Zeit und führt in der Regel zu Lösungen, die den Standardvarianten in keinerlei Hinsicht überlegen sind.

Gute Absicht Nummer 4: Plattformübergreifende Anwendungen

Die plattformübergreifende Entwicklung ist schon allein aus technischer Perspektive ein Traum: Eine Anwendung nur einmal konzipieren, die Benutzeroberfläche nur einmal entwerfen und das fertige Produkt für alle gängigen Betriebssysteme und alle Gerätekategorien zur Verfügung stellen.

Doch auch hier lauern Fallstricke, die den Traum zum Alptraum werden lassen können. Der erste ist Sopova zufolge die Entwicklung „übertrieben plattformübergreifender“ Anwendungen. Soll heißen: Die Anwendung ist derart auf den plattformübergreifenden Einsatz ausgerichtet, dass sie auf keiner Plattform wirklich überzeugen kann. Sopova führt derartige Anwendungen vor allem auf entweder unerfahrene oder übermäßig selbstbewusste Entwickler, die davon ausgehen, dass ihr Code ohne jedwede Anpassung auf jedem Gerät gleich gut läuft, zurück. Auch die Scheu vor Portierungen oder schlichte Faulheit führt sie als häufige Ursachen an.

Derartigen Anwendungen stehen Applikationen gegenüber, die nur auf einem ganz bestimmten Betriebssystem laufen und eventuell sogar ganz besondere Hardware erfordern. Auch Projekte, in denen der Code für jede Zielplattform fast von Grund auf neu geschrieben wird, sowie Code, der besonders schwer zu portieren ist, fallen für Sopova in diese Kategorie.

Sind Ihnen noch weitere gute Absichten bekannt, die in die „Programmiererhölle“ führen können? Teilen Sie sie uns in den Kommentaren mit!

Aufmacherbild: Two gates to heaven and hell von Shutterstock / Urheberrecht: Kletr

Geschrieben von
Michael Thomas
Michael Thomas
Michael Thomas studierte Erziehungswissenschaft an der Johannes Gutenberg-Universität Mainz und arbeitet seit 2013 als Freelance-Autor bei JAXenter.de. Kontakt: mthomas[at]sandsmedia.com
Kommentare

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *