Code Generatoren

Vor ein paar Tagen las ich einen Artikel über Code Generatoren, der mir nicht so recht gefallen wollte. Ich dachte darüber nach, was es genau mich an dem Artikel störte. Er war gut geschrieben, die Beispiele waren aussagekräftig und der Einsatz von Code Generatoren schien auch viel Arbeit zu sparen.

Der Artikel erwähnte auch, dass die Erstellung von Templates zwar aufwendig ist, sich aber bereits nach 3-4 Projekten amortisiert. Nach zehn Projekten soll man auf die Weise bis zu 50% der Arbeit einsparen können. Vor allem lässt sich die wiederholende Tipparbeit enorm einsparen.

Moment mal! Jetzt war mir klar, was mich störte. Es wird Code mehrfach generiert der sich stark ähnelt und sich eventuell nur in einzelnen Benennungen unterscheidet. (So war zum Beispiel ein Codeschnipsel gezeigt, der für mehrere Tabellen benötigt wird. Man musste nur den Tabellennamen in dem Code ersetzten und hatte funktionierenden Code.)

Spätestens jetzt sollen bei jedem Entwickler die Alarmglocken läuten. Code zu kopieren ist ein sehr starkes Signal dafür, dass man den Code an dieser Stelle abstrahieren sollte. Häufige Wiederholungen sind zu vermeiden und durch Konstrukte zu ersetzen, die sich parametrisieren lassen. (So ließe der Code aus dem vorigen Beispiel in eine Datenbank Zugriffsklasse verschieben und mit dem Tabellennamen als Parameter aufrufen.)

Gute und schlechte Generatoren

Code automatisch tippen zu lassen, statt ihn selbst zu tippen ist natürlich nicht falsch. Tools helfen Text schneller zu tippen (auch wenn dies nur pure Bequemlichkeit ist und keinen echten Zeitvorteil bringt). Vor allem lassen sich aber Flüchtigkeitsfehler vermeiden, was viel Zeit bei der Fehlersuche ersparen kann. Die Autovervollständigung in den meisten IDEs war zwar nicht als „Code Generator“ gesehen, aber im Grunde erfüllt sie eine ähnliche Aufgabe. Auch die sogenannten „Snippets“, mit denen ganze „if ... else …“ oder „foreach“-Blöcke oder Klassenrümpfe erstellt werden können, sind eine kleine Hilfe.

Ebenso sinnvoll und hilfreich sind Generatoren, die schematische Diagramme in entsprechenden Code umwandeln. Diese wiederholen nicht den eigentlichen Inhalt der Objekte, sondern übersetzen im Grunde nur die Verknüpfungen in Code. (Zum Beispiel können Prozessabläufe so visuell arrangiert werden, dass die erlaubten Übergänge zwischen den einzelnen Zuständen gezeichnet werden können.) Dies sind dann keine Wiederholungen, weil sie stets einzigartig sind.

Dies gilt nicht unbedingt für Datenbank-Objekt Zuordnungen. Hier werden oft und gerne Code-Generatoren eingesetzt. Der Programmcode entspricht im wesentlichen einer Konfiguration. Was mir hier missfällt sind eins-zu-eins-Zuordnungen. (Wenn z.B. die Spalte „Betrag“ mit der Klassenvariable „Betrag“ verknüpft wird, „Datum“ mit „Datum“, etc.) Solche Zuordnungen lassen sich dann besser per Konvention statt mit viel Konfiguration lösen.

Bibliotheken statt Generatoren

Statt also Code per Template in diversen Projekten zu verteilen, sollte man diesen in dedizierte Bibliotheken aufnehmen und geeignete Parameter vorsehen. Sind diese auch noch mit sinnvollen und/oder häufig verwendeten Werten vorbelegt, hat man schon viel erreicht.

Was bei Generatoren unterschätzt wird, ist der Pflegeaufwand bei Korrekturen. So wird bei Generatoren empfohlen bei Korrekturen das Template anzupassen. Das erfordert jedoch entweder ein manuelles Nachziehen des Code in allen Projekten oder eine erneute Generierung mit dem Verlust der lokalen Anpassungen. Beides ist unangenehm und unter Umständen viel Arbeit.

Pflegt man jedoch solche gemeinsamen Funktionen in einer Bibliothek, die man bei Bedarf in die Projekte einbindet, so lässt sich eine Korrektur problemlos in alle Projekte übernehmen. Einzige Voraussetzung ist, dass sich die Schnittstelle und das Verhalten nicht ändert. (Sollte bei Korrekturen eigentlich nicht der Fall sein.)

Aber Vorsicht bei allzu monolithischen Bibliotheken oder Frameworks, die zahllose innere Abhängigkeiten besitzen. Gerade Frameworks neigen gerne dazu einem Projekt das „ganze Paket“ aufzudrücken, obwohl man erst einmal nur an einer speziellen Funktion interessiert ist.

Fazit

Der Einsatz von Generatoren sollte nach Möglichkeit einem objektorientiertem Ansatz gegenübergestellt werden, bevor viel Zeit in Templates gesteckt wird.

Achten sie beim Entwickeln von Bibliotheken auf atomare Funktionen und Objekte, die ohne viele Abhängigkeiten auskommen.