Zu viel Abstraktion birgt die Gefahr, dass Code sich verselbstständigt

Klein ist fein, dachte sich einmal ein namentlich nicht genannter Entwickler einer Linux-Distribution und postulierte, dass eine Webseite in ein TCP-Paket passen müsse. Außerdem wäre nur handgeschriebener Assemblercode wirklich performant. In grauer Vorzeit galt dieser Grundsatz vielleicht (einmal von den TCP-Paketen abgesehen), aber heute erzeugen Compiler meist besseren Maschinencode als solcher, den Entwickler selbst austüfteln - zu kompliziert sind die internen Abläufe in modernen CPUs, zu komplex das Timimg von Pipelines und zu unabsehbar die Auswirkungen mehrstufiger Cache-Hierarchien.

Hierarchie-Ebenen

Deshalb verwenden Entwickler mittlerweile Compiler. Aber das Prinzip lässt sich auch noch weiterdenken: Niemandkommt heute noch ohne Bibliotheken aus, zu vielfältig sind die Aufgaben, die ein Programm erledigen soll. Da ergibt es nur Sinn, immer wiederkehrende Aufgaben in eine Schachteln zu verpacken und diese zu benutzen. Klassenbibliotheken abstrahieren Funktionssammlungen, Frameworks abstrahieren Klassen und Entwurfsmuster transzendieren ganze Anwendungsarchitekturen.

Hierarchische Strukturen sind den meisten Entwicklern vertraut, machen sie doch das Leben einfach. Doch wie auch im richtigen Leben lohnt es manchmal, die Gegebenheiten zu hinterfragen und einen Schritt zurückzutreten, um das Ganze aus einem holistischen Blickwinkel zu betrachten.

Da gibt es Entwickler, die freudestrahlend davon berichten, wie sie mit wenigen Mausklicks ein Datenmodell aus einer Datenbank extrahieren und mittels Codegeneratoren persistente Java-Klassen erzeugen, die für einen Adressdatensatz später im Hauptspeicher ein knappes Megabyte dauerhaft belegen.

Hardware kostet nichts

Auf den Ressourcenhunger angesprochen kontern die Anhänger der neuen Sorglosigkeit mit dem Totschlagargument, dass man einfach einen neuen Server hinstelle, wenn der alte nicht mehr ausreiche. Hardware koste ja nichts mehr. Die Argumentation erinnert ein wenig an die Ernsthaftigkeit derer, die mit dem Hinweis auf die Steckdose die Energiekrise wegreden wollen.

Einfache Aufgaben sollten in einer einfachen Lösung resultieren. Wer einen Textstring von einer Standardeingabe lesen möchte, für den reicht in C ein »fgets(s);« oder in Perl ein »s = <>;«. Abstraktion hin oder her, aber wer kann noch plausibel vermitteln, wieso Java wie in Abbildung 1 dazu fünf Klasseninstanzen und einen Integer benötigt?

Abbildung 1: Java benötigt fünf Klassen und einen Integer um einen String aus einer Datei auszulesen. In Perl reichen dazu vier Zeichen und ein Semikolon.

Das ist übrigens kein Problem der Programmiersprache, sondern vielmehr der Attitüde, der sich mancher Entwickler hingibt. Wer Kartenhäuser aus Abstraktionsebenen baut, übersieht, dass die Ergebnisse nicht mehr handhabbar sind, sobald nur noch die Maschine, ein Build-Skript oder der Precompiler um die wirklichen Zusammenhänge im Code weiß. Übergeneralisierung ist ebenso gedankenlos wie das eingangs diskutierte Beharren, alles zu Fuß erledigen zu wollen. Bewunderswert sind daher alle Entwickler, die noch wissen, was sie tun.

Umso spektakulärer sind dann die Ergebnisse der Verbesserungen im Kleinen. Im Beitrag "Deko mit Nutzen" ab Seite 96 stellt Rainer Grimm eine Erweiterung von Python vor, die bei einigen Programmen eine dramatische Steigerung der Performance bewirkt. Die Dekoratoren sind ein ganz einfaches Sprachmittel, um übersichtlich Code in universeller Weise in Methoden einzubringen. Ein Beispiel ist ein Cache für rekursiv aufgerufe Funktionen.

Noch pragmatischer ist der Artikel "Wer liefert wann?" von Perlmeister Mike Schilli ab Seite 102. Darin zieht der bekennende Internet-Shopping-Süchtige dieSourcecodeverwaltung Git des Linux-Kernels heran, um nicht den Überblick über seine Bestellungen zu verlieren.