Gedanken zu "Lean Software Development" mit Zeitsprung.

Lean Software Development ist eine Disziplin der agilen Softwareentwicklung. Für die Softwareentwicklung bedeutet lean (schlank), nur das wesentliche ohne überflüssigen Balast zu implementieren. Lean Softwareentwicklung wird von klaren Anforderungen und einem hohen Verständnis für eine Technologieplattform getragen.

Anforderungen müssen klar formuliert sein, mit einem gemeinsamen Verständnis der Anforderungen auf Kundenseite und beim Entwickler. Entwickler die nur klar definierte Anforderungen implementieren sind verantwortungsbewusst und schützen den Quellcode vor unnötigem Balast. Hierzu zählen auch Workarounds, die allzu gerne aufgrund des Termindrucks einer tiefgründigen Analyse mit anschließender Problemlösung vorgezogen werden. Workarounds können auch entstehen, falls die eingesetzte Technologie nicht den gewünschten Funktionsumfang bietet, um eine Anforderung implementieren zu können. Workaround klingt negativ, ist aber nicht in allen Fällen negativ zu deuten. Workarounds können durch "Best Practices" manifestiert werden, sodass der negative Eindruck verschwindet.

Gedanken aus dem Jahr 2012:

Java EE 5 und Java EE 6 hat aus der Entwicklerperspektive sehr viel Balast verloren. Java EE ist leichtgewichtig geworden, Deployment Deskriptoren sind optional und werden meistens durch Annotationen ersetzt. EJB 3 Komponenten implementieren schlanke Java Schnittstellen ohne zusätzliche EJB-Artefakte (Home- und Komponentenschnittstellen) implementieren zu müssen.

Java EE ist vor-konfiguriert ("convention over configuration" bzw. "configuration by exception"), sodass häufig mit wenig Quellcode ein vollfunktionsfähiger Service implementiert werden kann. Java EE ist durchgängig, sodass mit JSF 2, CDI, EJB 3 und der JPA mit wenig Quellcode Daten von einer Webseite in die Datenbank geschrieben werden können. Java EE ist klar spezifiziert und durch eine Referenzimplementierung gesichert. Java EE ist ein Framework, der dem Entwickler keine unnötige Last mehr auflädt. Java EE ist herstellerunabhängig und kann auf unterschiedlichen Applikationsservern betrieben werden. Die Liste des Lobes könnte noch sehr viel länger werden, im Kern aber nicht mehr Aussagen als: Java EE ist ein Standard mit hohem Reifegrad.

Eine Klasse mit @WebService zu annotieren, sodass alle öffentlichen Methoden zu Webservice Methoden werden ist "lean". EJBs, Managed Beans, XHTML-Seiten in einem WAR zu deployen ist "lean". Keine lokalen Schnittstellen für lokale EJBs implementieren zu müssen ist "lean". Message Driven Beans und Timerservices zu annotieren ohne aufwendige Deployment-Deskriptoren zu programmieren ist "lean". Den Persistenzkontext, externe Ressourcen und EJBs per Dependency Injection (DI) zu nutzen ist "lean". Lifecycle und Business Interceptoren sind "lean". Der I-Stack, JAXP, JAXB, JAX-WS und JAX-RS  sind "lean". Java EE ist definitiv schlanker geworden!

Gedanken aus dem Jahr 2025:

Die Entwicklerwelt hat sich verändert. Standards verschieben sich oder werden überholt. Heute bewegen wir uns häufig in Microservice Architekturen. Die Services sind deutlich schlanker geworden und erfüllen oft nur einen einzigen Use Case. Mit Spring Boot 3 wurde die Autokonfiguration nochmal deutlich erweitert. Microservices lassen sich mit Spring Boot sehr schnell in hoher Qualität programmieren. Eine REST Schnittstelle anzubieten, die Business Logik zu programmieren und die Daten zu persistieren ist durchgängig mit dem Spring Boot Framework möglich. Die Zutaten sind Spring Boot Dependencies und Annotationen sowie Frameworks wie beispielsweise Lombok.

Die Programmiersprache Java hat sich deutlich weiterentwickelt. Seit dem JDK 8 wird die funktionale Programmierung unterstützt. Lambda Ausdrücke und Methodenreferenzen sowie "Functional Interfaces" erlauben es Funktionen wie Datenstrukturen zu verwenden, um schlankeren ausdrucksstarken Quellcode programmieren zu können.

Hand in Hand mit der Stream API lassen sich Bulk Operationen auf Collections ausführen, die nahtlos mit Lambda Ausdrücken und Methoden-Referenzen kombiniert werden können. Streams sind Pipelines die auf Daten wirken. 

Quelle 🚩Stream (Create) 🔅🔆🔆(Intermediate - Operationen) 💡 (Terminal - Ergebnis)

Filter - Map - Reduce Streams profitieren von Lambdas und ermöglichen schlanken gut lesbaren Quellcode zu programmieren.

Die Erweiterung der Date Time API und die neue Funktionen im Collection- und NIO-Framework vereinfachen die Programmierung von Java Anwendungen. Der syntaktische Zucker höherer Java Versionen wie beispielsweise die Schlüsselwörter "var" und "record", das "Pattern Matching" für "switch" und "instanceof" und vieles mehr, erleichtern es schlankere Software zu schreiben. Java ist längst nicht mehr so geschwätzig wie in der Vergangenheit, aber auch noch nicht so prägnant wie Kotlin. 💪

Zumindest die Technologien im Java-Umfeld sind schlanker und leichtgewichtiger geworden. Betrifft das aber auch die Umsetzung der Anforderungen?! 😎 Wer holt die Glaskugel raus?! 🌐

CCD Praktiken

Die Werkzeuge eines Softwareentwicklers sind heutzutage ausgereift und unterstützen die Programmierung und Wartung der Softwaresysteme.

IntelliJ IDEA (TM) integriert unterschiedliche Projekttypen, Programmiersprachen und Systeme in eine Entwicklungsumgebung und unterstützt mit Code Completion und Refaktorisierungswerkzeugen den Entwicklungsprozess. Vielfältige Plugins für alle möglichen Einsatzgebiete stehen ebenfalls zur Verfügung. Source Code Conventions können in der Entwicklungsumgebung konfiguriert und im Team geteilt werden.

Versionskontrollsysteme wie GIT sind in die Entwicklungsumgebung integriert und unterstützen die Verwaltung der Software Quellen optimal. GIT und andere Versionskontrollsysteme erlauben die Verwaltung der Software Quellen ohne die Angst haben zu müssen, dass etwas verloren oder kaputt geht. Die Historie in der Versionskontrolle ist eine wichtige Quelle für die Weiterentwicklung und Fehlerbehebungen im Quellcode. Nur mit einer Versionskontrolle gelingt die Zusammenarbeit in einem Team von Softwareentwicklern.

Im Gitlab sind die Pipelines konfiguriert, die bei einem Commit anlaufen, um Prüfungen vor dem Push in die Versionskontrolle vorzunehmen. Prüfungen können sein, dass alle Unit- und Integrationstests fehlerfrei ausgeführt werden konnten. Scanner prüfen auf CVEs, Pipeline Jobs deployen in Cluster Umgebungen und Taggen die Software, noch bevor die gebauten Artefakte für das Deployment in die entsprechenden Umgebungen verschoben werden.

Das Tracking von Issues mit JIRA (TM) oder anderen Tracking-Systemen unterstützt die Arbeit und Kommunikation in einem cross-funktionalen Scrum Team optimal. Die Stati des Tracking Systems zeigen den Team-Mitgliedern die Verarbeitungsschritte und Übergabepunkte an. Prioritäten und der Bedarf an der Softwareentwicklung beteiligter Personen wird bestmöglich unterstützt, sodass die Kommunikation im Team auch außerhalb der Entwicklungsumgebung und der Welt des Quellcodes unterstützt und transparent wird.

Warum das alles?!

Ganz einfach, die Werkzeuge geben uns Stabilität, Sicherheit sowie Vertrauen in die Software und verbessern den Entwicklungsprozess und die Qualität des Quellcodes erheblich. Die Produktqualität wird enorm gesteigert. Aus Sicht von CCD sind die Werkzeuge, die wir in der Softwareentwicklung heute einsetzen, unter Praktiken angesiedelt.

Roter Grad - Versionskontrolle: Voraussetzung für jeden professionellen Softwareentwickler, steigert die Produktivität und fördert die Verbesserung des Quellcodes. Die Versionskontrolle ist auch eine Wissensquelle und Medium zum Austausch von Wissen.

Oranger Grad - Issue Tracking: Notwendig, um in einem agilen Team zusammenarbeiten zu können. Schnittstelle zwischen den Anforderungen und der Implementierung der Software. Kommunikationsdrehscheibe für alle Teammitglieder, vom Product Owner bis zur Qualitätssicherung.

Oranger Grad - Automatisierte Integrationstests 

und Gelber Grad - Automatisierte Unit-Tests: Unabdingbar als Sicherheitsnetzwerk gedacht um Fehler und Seiteneffekte möglichst frühzeitig erkennen zu können. Garantiert das Deployment stabiler Softwarestände in die Laufzeit- und Cluster-Umgebungen.

Oranger Grad - Reviews: Wesentlich, um Fehler im Quellcode oder Verbesserungspotential frühzeitig im Quellcode zu erkennen. Neben dem Pair Programming eine gute Möglichkeit um Wissen weiterzugeben und Implementierungen zu diskutieren sowie freizugeben.

Grüner Grad - Continous Integration (CI): Unabdingbar, Software darf nur automatisiert getestet und gebaut werden. Die Automatisierung in den Build-Pipelines kann flexibel an die Bedürfnisse eines Softwaresystems und Erfordernisse der Produktionsqualität angepasst werden. In der Summe unterstützen automatisierte Prozesse die Entwicklung, um angstfrei hochwertige Software-Artefakte in gleichbleibender Qualität zur Verfügung zu stellen.

Blauer Grad - Continous Delivery (CD): Erforderlich, das automatisierte Deployment in eine Laufzeit- oder Cluster-Umgebung ist genauso wichtig, wie die Automatisierung der Testdurchläufe. Erfolgreiche Deployments zeigen auf, dass die Software Services richtig für eine Umgebung konfiguriert sind und dass die Software funktioniert. Optimalerweise werden nach dem Deployment noch einmal Tests automatisiert ausgeführt, die integrative Use Cases und das Zusammenspiel mehrerer Services testen.