Thoughts on agile software development
Jens 
Bei der Verwendung von REST Schnittstellen beginnt die Evolution eigener APIs mit der Erstellung einiger HTTP Endpunkte die Informationen im JSON Format austauschen. Die nächste Stufe ist die Abkehr von der Denkweise in Aktionen hin zum Verständnis, dass über REST Resourcen addressiert und manipuliert werden.
Wer als Java Entwickler mit Datenbank Experten zusammenarbeiten darf, kennt deren Hinwendung zu großgeschrieben Bezeichnern. Da heißen die Tabellen dann ANCESTOR_TREE und die Attribute NAME, DESCRIPTION, CREATED_BY. Diese Namenskonvention gilt in Java aber nur für die Namen von Konstanten, weder für die Namen von Klassen noch ihrer Instanz-Attribute.
Wenn mehr als ein Beteiligter beim Speichern von Daten involviert ist, kann es zu ungewollten Überschreibungen kommen. Um solche Probleme zu umgehen, existieren drei Vorgehensweisen. Pessimistic Locking, Optimistic Locking und Ignore It!
Wird eine neue Software Technologie eingesetzt, dann taumeln die beteiligten Entwickler von anfänglicher Euphorie schnell in tiefste Depression. Die Entwickler sind keinem Borderline Syndrom erlegen, aber häufig lässt man sich, in der Hoffnung auf Neues, von einigen Buzz-Words täuschen. Vor einigen Jahren bekam unser Team eine REST API vorgelegt, die unser Kunde gerne angeschlossen haben … Read more
In der Software Entwicklung ist es immer wieder schön, wenn zwei Frameworks gut zusammenarbeiten. Ärgerlich ist es dann aber, wenn man dies nicht adäquat testen kann. Eines dieser unglückseligen Paare sind Keycloak und Spring Security.
Das Testen der Software ist fast genauso wichtig, wie deren Implementierung. Bei der Implementierung von komplexen Systemen müssen Entwickler und Kunden prüfen können, ob das erstellte Werk auch allen Anforderungen entspricht und korrekt arbeitet. Aus diesem Grund werden beide Tätigkeiten beim Test-Driven-Development auch miteinander verbunden. Schwierigkeiten bereitet es häufig, welche Art von Test wann und wie verwendet werden sollte.
In manchen Diskussionen versteigt sich der Software Entwickler ins Japanische und spricht von Kaizen, Mura und Muri, Seiri und Seiton. Diese Begriffe stammen alle aus dem Bereich des Lean-Managements, mit dem die japanischen Hersteller die Produktionsverfahren revolutioniert haben.
Der Product Owner hat die Aufgabe, dem Development Team zu erzählen, was der Kunde benötigt. Das klingt erst einmal sehr einfach, ist aber eines der größten Probleme der Software Entwicklung.
Wer kennt diese Situation als Software Entwickler nicht. Man hat eine nette kleine Idee und statt sie direkt zu implementieren, bespricht man sie mit einem Projektverantwortlichen. Plötzlich wächst die Idee zu irgendetwas heran, das ohne wirklich weiteren Wert zu bieten, mehrere Tage bis Wochen Vorbereitung und Implementierung benötigt. Als junger Entwickler hörte ich, im Zuge einer eigenen kleinen Idee, zum aller ersten Mal von den U-Booten.
Im vorherigen Beitrag zu JavaMail API wurde die Bibliothek GreenMail vorgestellt. Mit dieser Bibliothek ist es möglich, verschiedene E-Mail Server zu simulieren. Da keine überzeugende JUnit 5 Unterstützung existiert, lag die Idee nahe, eine eigene JUnit Extension zu schreiben. Während der Implementierung zeigten sich erste Ideen als unnütz, das Verständnis der GreenMail API verbesserte sich und die eigene Art zu Testen wirkte sich natürlich auf die Gestaltung der Erweiterung aus.