Best Practice durch Einsatz von Generatoren

Wir setzen bei uns in der Entwicklung nun seit mehreren Jahren Software-Generatoren auf der Virtual Developer Plattform erfolgreich ein. Die Generatoren haben wir teilweise selbst entwickelt und teilweise auch extern entwickeln lassen, je nach verfügbaren internen Ressourcen.

Anfangs wurde die Generierung nur in einzelnen Projekten und auch nur von einzelnen Entwicklern eingesetzt, um sich mit der Technologie und der geänderten Arbeitsweise vertraut zu machen. Nach kurzer Einarbeitungszeit der Entwickler zeigten sich schnell die Vorteile der Generierung: Viel Routinearbeit wird automatisiert, es entstehen weniger Fehler, man kommt schneller zu lauffähigen Ergebnissen und der Entwickler kann sich auf das Wesentliche, nämlich die Business-Logik der Anwendung, konzentrieren.

Somit war es nur logisch die Generierung in weiteren Projekten einzusetzen, auch bei solchen, die seit vielen Jahren „klassisch“ entwickelt wurden, insbesondere dann, wenn Erweiterungen dazu entwickelt werden. Von einer Komplett-Migration von langjährig manuell entwickeltem Code in generierten Code habe wir abgesehen, da sich die Generierung auch erfolgreich in bestehende Projekte integrieren lässt, indem man z.B. die „alten“ Teile weiterhin manuell wartet, die neuen aber unter Einsatz der Softwaregenerierung entwickelt. Somit ist ein stetiger Übergang möglich und kein harter Technologiewechsel erforderlich.

Mit dem zunehmendem Einsatz der Generierung im Unternehmen zeigte sich dann, wie doch einige Konzepte z.B. für Datenbankklassen in den verschiedenen Projekten über die Jahre „auseinander gelaufen“ sind. Ursprünglich abgestimmte Basisklassen, die allgemein einsetzbar sind, wurden im Laufe der Zeit Projekt-spezifisch angepasst und optimiert. Es erfolgte aber selten ein „Rückfluss“ dieser Ergebnisse in die anderen Projekte. So blieb manche gute Idee oder Verbesserung nur in einem Projektteam ohne Nutzen für die anderen Projekte.

Durch die zunehmende Generierung der Klassen mit dem Ziel, in allen Projekten die selben Generatoren zu nutzen, sind solche „forks“ aufgefallen. Die erste Reaktion der Entwickler war eine Parametrisierung der Generatoren, sodass der generierte Code die projektspezifischen Anpassungen für das jeweilige Projekt mit generiert. Dieser Ansatz führt zwar zu schnellen Ergebnissen bei der Einführung der Generierung für das jeweilige Projekt, erschien aber mittelfristig aus wirtschaftlichen Gründen nicht sinnvoll: Allgemeingültige Generatoren müssten so immer wieder an Projektspezifika angepasst werden und insbesondere müssten diese Anpassungen an den Generatoren auch projektspezifisch getestet werden, was zusätzlichen Testaufwand bedeutet.

Es stellt sich dabei auch generell die Frage, warum eine Optimierung oder Verbesserung eines Vorgehens in einem Projekt, nicht auch gut für die anderen Projekte ist. Bleibt hier ein Potential an Wirtschaftlichkeit und Effizienz ungenutzt, wenn gute Ideen nur in einem Projekt realisiert werden?

Um dieses Thema zu bearbeiten wurden aus den verschiedenen Entwicklungs-Teams, die Generatoren nutzen, jeweils „Key-Entwickler“ ausgewählt und zu Best Practice Abstimmungsterminen eingeladen. Schnell zeigte sich dass diese Abstimmungstermine einen entscheidenden Vorteil bringen: Die verschiedenen (auseinander gelaufenen) Ansätze wurden besprochen und die Gründe und die Vorteile der im Projekt erfolgten Anpassungen oder Erweiterungen erläutert. Hieraus ergab sich überraschend schnell eine Einigung der Entwickler, welche Variante die bessere ist. Oft stellte sich heraus, dass diese Erweiterungen meist abwärtskompatibel entwickelt wurden, sodass deren Nutzung gar kein Refactoring bestehenden Codes erforderlich machte.

Somit bestand auch schnell Einigkeit, welche Code-Variante künftig generell (projekt-unabhängig) generiert werden soll. So konnten viele projektspezifische Varianten aus den Generatoren wieder herausgenommen werden, was auch die Pflege und den Test der Generatoren deutlich vereinfacht.

Diese Abstimmungstermine finden inzwischen regelmäßig in größeren Abständen statt, insbesondere wenn Anpassungen oder Erweiterungen an Generatoren vorgeschlagen werden. Dadurch hat sich parallel zur Einführung der Generierung quasi automatisch ein Team-übergreifendes Best Practice Vorgehen etabliert.

Durch das Einführen der Optimierungen über den generierten Code, stehen diese auch den Entwicklern der anderen Teams (die davon bisher sonst nichts mitbekommen haben) zur Verfügung. Sobald diese in ihren Projekten Code generieren sehen auch sie die Verbesserungen im neu generierten Code. Durch das Versionsmanagement der Generatoren kann auch jeder Entwicklungsverantwortliche selbst festlegen, wann er mit seinem Team auf eine neuere Generatorversion wechselt, sodass die Generatoren stetig weiterentwickelt werden können ohne die anderen Projekte zu „stören“.

Es hat sich gezeigt dass auf diesem Wege, nämlich über die Generatoren, Best Practice-Ansätze viel leichter in andere Teams zu transportieren sind. Auch neue Mitarbeiter lernen gleich, unabhängig davon in welchem Team sie starten, die abgestimmten Best Practice Vorgehen kennen. Ebenso sind die Best Practice Ansätze festgehalten und dokumentiert, da Sie quasi durch die Generatoren „in Code gegossen“ werden und das immer wieder und immer gleich bei jedem neuen Projekt oder Modul. Da auch die Generatoren der Versionierung unterliegen findet damit parallel eine Versionierung der Best Practice Vorgaben statt, sodass sogar deren zeitliche Entwicklung nachzuvollziehen ist.

Bei bereits generiertem Code zeigt sich auch hier ein großer Vorteil: Um Best Practice Vorgehen in bestehendem Code anzupassen muss dieser nicht mehr manuell „angefasst“ werden sondern einfach nur mit der neuen Generatorversion erneut generiert werden.

Man sollte also die Chance nutzen, bei der Einführung der Softwaregenerierung dieses Best Practice Vorgehen mit zu etablieren, da dies bei der Entwicklung der Generatoren viel Zeit spart und einen zusätzlich Effizienzgewinn in der Entwicklung bringt.

Christian Disch
Geschäftsführer
highQ Computerlösungen GmbH