Mit dem Codestart Bundle zur Individualsoftware  

Ein häufiges Problem in der IT-Arbeitswelt ist Routinearbeit, also Aufgaben, die wiederkehrend sind und sich durch Wiederverwendbarkeit oder Automatisierung vermeiden lassen. Problematisch ist insbesondere, dass sie Raum für Fehler bietet, während die dafür benötigten Aufwände gleichzeitig durch den Einsatz von technischen Lösungen eingespart werden könnten. Um dieses Problem zu lösen, bietet die moderne IT-Welt eine ganze Reihe an Möglichkeiten. Speziell in der Softwareentwicklung kann durch den Einsatz von Codestart Bundles auf Wiederverwendbarkeit gesetzt und somit Routinearbeit vermieden werden.  

Einmal ausführlich – das Problem 

Vergleicht man unterschiedliche Software, so begegnen einem immer wieder ähnliche Muster, wenn es um grundlegende Funktionalitäten geht. Einige dieser grundlegenden Funktionen, wie beispielsweise das Aussehen eines Buttons, sind in unzähligen Open-Source-Bibliotheken definiert, die sich größtenteils ohne Lizenzkonflikte nutzen lassen. Allerdings haben Bibliotheken auch den Anspruch, abstrakt und generisch zu sein, damit sie für möglichst viele Anwendergruppen interessant sind. Die Kunst liegt darin, einerseits die richtigen Bibliotheken zu finden und andererseits diese korrekt zu integrieren. Durch diese Integrationstätigkeit entsteht erneuter Boiler Plate Code und somit eine Arbeitsweise, die für Entwickler in neuen Projekten zu Beginn wiederkehrend ist. 

Diese Tätigkeit ist also notwendig, um das Projekt zu initialisieren und um ein technisches Fundament zu erstellen, auf dem später die individuellen Kundenanforderungen umgesetzt werden können. 

Beispielsweise sind für die Umsetzung einer neuen Web-Anwendung in der Regel die folgenden Schritte notwendig: 

• Auswahl eines Frameworks 
• Initialisierung des Frameworks 
• Auswahl und Integration von UI-Bibliotheken 
• Auswahl und Integration von Testbibliotheken 
• Erstellen von Pipelines zum Bauen, Testen, etc. 
• Integration eines Linters zur statischen Codeanalyse 
• Implementierung eines Logins und Logouts 
• Verwaltung von Benutzern 
• Erstellung eines Dashboards mit Header, Menü, Logo, etc. 
• usw. 

Von der Einmaltätigkeit zur Routine 

Für einige Entwickler mag diese Tätigkeit eher selten stattfinden, beispielsweise, wenn sie an einem Monolithen arbeiten. Sobald ein Softwareentwickler aber regelmäßig neue Projekte initialisiert, wird die hier beschriebene Tätigkeit zur Routine, da sich die dafür notwendigen Schritte wiederholen. Dies ist häufig bei IT-Dienstleistern der Fall: Sie betreuen häufig viele verschiedene Kunden bzw. setzen mehrere Projekte um. Aber auch für Inhouse-Entwickler kann das Initialisieren von Projekten eine Routinearbeit darstellen, beispielsweise wenn ihre Organisation auf eine Microservice-Architektur setzt. 

Na und, dann halt Routine? 

Warum nicht einfach die Routinearbeit bei der Entwicklung neuer Software an dieser Stelle akzeptieren? Die Zeitersparnis ist zwar da, fällt aber verglichen mit der insgesamt eingeplanten Zeit bei größeren “grüne Wiese”-Projekten häufig nicht besonders stark ins Gewicht. Hier geht es meistens eher um wenige Tage. 

In einigen Projekten werden die fundamentalen Grundlagen nach dem Motto „Quick & Dirty“ in Code realisiert, da die eigentliche Motivation und der Fokus auf den fachlichen Anforderungen liegen und Routinearbeit als lästiges Übel empfunden wird. Ein Projektteam möchte schnell an den Punkt kommen, an dem es zum eigentlichen Projektthema Mehrwerte generieren kann. In einem agilen Umfeld ist das zunächst in Ordnung, schließlich wird hier iterativ in Inkrementen gearbeitet und das Produkt stetig verbessert. Allerdings führt genau das dazu, dass solche Grundlagen häufig nur noch selten überarbeitet werden. Mit anderen Worten, das Fundament des Projektes ist möglicherweise dauerhaft „Quick“, aber eben auch „Dirty“. Dies sollte insbesondere beim Umsetzen sicherheitskritischer Grundlagen, wie beispielsweise der korrekten Integration eines Authentifizierungsproviders, keinesfalls außer Acht gelassen werden. 

In Summe führt Routine also zu einem zeitlichen Mehraufwand sowie zur Vernachlässigung von Qualitätsanforderungen. 

Ein Codestart Bundle verwenden 

Um die zuvor beschriebene Problematik mit Routinearbeit zu lösen, können Codestart Bundles von SVA verwendet werden. Ein Codestart Bundle ist ähnlich wie ein Template, also ein vorkonfiguriertes Projekt, das nützliche Grundlagen enthält, die üblicherweise bei völlig neuen Projekten notwendig sind. Welche Inhalte das genau sind, hängt von dem jeweiligen Codestart Bundle ab. Hierbei gibt es Unterschiede zwischen Frontend- und Backend-Bundles, aber auch zwischen den einzelnen Frameworks. 

Codestart Bundles sind somit eine Sammlung von Best Practices, die alle aufeinander abgestimmt sind und miteinander harmonieren. Die wichtigen Funktionen sind (selbstverständlich durch Code) getestet, wodurch eine sehr gute automatisierte Qualitätssicherung möglich ist. 

Deep Dive 

Ein Entwickler möchte ein neues Projekt beginnen. Es soll eine Web-Anwendung werden, die es den Kunden seines Unternehmens erlaubt, ihre Stammdaten eigenständig zu verwalten. Langfristig soll diese Anwendung zu einem Kundenportal heranwachsen, über das ganz individuelle Services gebucht werden können. Selbstverständlich ist ein sicherer Login der Benutzer erforderlich. Dazu soll ein bereits vorhandener Identity Provider angebunden werden. 

Da diese Anforderungen als Web-Anwendung realisiert werden sollen und der Entwickler gute Erfahrungen mit Angular gesammelt hat, entscheidet er sich dazu, auch hier auf dieses Framework zu setzen. 

Möglichkeit I: Entwicklung ohne Codestart Bundle 

In diesem Fall würde der Entwickler zunächst ein neues Angular Projekt initialisieren, eine UI Library einbinden, eine Pipeline bauen und eslint zur statischen Codeanalyse konfigurieren. Als nächstes wird ein Dashboard mit Header, Menü und einer Authentifizierungslogik sowie einer Anzeige des eingeloggten Benutzers erstellt. Der Entwickler achtet darauf, dass alle UI-Komponenten responsiv sind, um die Kompatibilität zu Smartphone-Displays sicherzustellen. Um dazu den vorhandenen Identity Provider anzubinden, muss sich der Entwickler noch einmal neu in das dafür notwendige Protokoll OIDC einlesen. Die Entwicklung dieser Grundfunktion gestaltet sich meist zeitintensiv, da Fehler, die hier gemacht werden, potenziell sicherheitskritisch sind. Um die Authentifizierung final testen zu können, muss die Anwendung entweder in eine Entwicklungsumgebung deployt oder lokal ein Identity Provider (wie z.B. Keycloak) aufgesetzt werden. Damit sich die Anwendung deployen lässt, ist eine nginx-Konfiguration und ein Dockerfile zu schreiben. Zur Versionierung integriert der Entwickler Semantic Release. Nach diesen ganzen Schritten kann der Entwickler nun mit der eigentlichen Arbeit beginnen und sich um die fachlichen Anforderungen (das Stammdatenformular) kümmern. 

Möglichkeit II: Entwicklung mit Codestart Bundle 

Der Entwickler lädt sich ein Angular Codestart Bundle herunter, tauscht das darin enthaltene Beispiellogo gegen das seiner Firma aus und pusht es in sein Git Repository.  Die Pipeline läuft automatisch los und validiert dadurch, dass alle Bestandteile der gewünschten Qualität entsprechen und funktionieren. 

Damit der Entwickler lokal eine gute Arbeitsumgebung hat, lädt er sich zusätzlich ein Codestart Bundle herunter, das ein vorkonfiguriertes Keycloak enthält. Er startet es mit dem Befehl docker-compose up -d und kann sich nun direkt in die Angular App einloggen. Nun beginnt er damit, die fachlichen Anforderungen, sprich das Stammdatenformular, umzusetzen. Nach kurzer Zeit präsentiert er einen ersten Prototypen seiner Anwendung. 

Noch einmal zusammengefasst

Ein Codestart Bundle kann beim Beginn von neuen Projekten helfen, indem Zeit für anfängliche Routinearbeit gespart wird. Dadurch können sich Entwickler von Anfang an auf die fachlichen Anforderungen konzentrieren und schneller einen Prototypen oder ein erstes Inkrement erzeugen. 

Da ein Codestart Bundle Best Practices implementiert, ist ein hoher Qualitätsstandard vorgegeben. Somit wird aus „Quick & Dirty“ eher „Quick & Quality“. Dies ist insbesondere bei sicherheitskritischen Grundlagen, wie der Integration eines Authentifizierungsmechanismus, sehr vorteilhaft.