Dieser Artikel entstand aus einer Diskussion im Team zum Thema Null-Safety in der Programmierung. Dabei haben wir uns über die Bedeutung von defensiver Programmierung und die Vermeidung von Nullpointer-Exceptions ausgetauscht. Im Speziellen ging es um die Verwendung von String.isEmpty: import org.apache.commons.lang3.StringUtils; ... String string = null; string.isEmpty() || StringUtils.isEmpty(string) Die Verwendung von StringUtils in diesem Beispiel würde verhindern, dass eine Nullpointer-Exception auftreten kann. Diese Vorgehensweise fällt meiner Meinung nach in die Kategorie “Defensives Programmieren”. ...

Für das Evang. Waldheim Esslingen, in dem ich lange Jahre ehrenamtlich aktiv war, betreibe ich die Website und dahinterliegende Webanwendung (siehe Projekte - Waldheim). Bisher sorgte der apache2 als Webserver und Reverse-Proxy für die Auslieferung der Seiten. Um etwas mehr Performance zu erreichen habe ich in diesem Fall die meisten statischen Inhalte aus der Webanwendung in ein separates Verzeichnis verlagert und Apache2 so konfiguriert, dass diese Inhalte nicht über die Webanwendung (bei mir jetty) an den Reverse-Proxy ausgeliefert werden, sondern apache2 diese direkt ohne Umwege ausliefern kann. ...

Um bessere Qualität in der Entwicklung zu erreichen, gibt es ein Konzept, das sich “Definition of Done” (DoD) nennt. Die Idee, dass das Team sich selbst Gedanken darüber macht, was alles nötig ist, damit eine Aufgabe (Story, …) wirklich erledigt ist, finde ich einen schönen Ansatz. Die Herausforderung sehe ich aber in der tatsächlichen Umsetzung. Ich habe bisher verschiedene Ausprägungen davon erlebt: Die Umsetzung wird mit dem “Holzhammer” durchgesetzt. Durch Zwang von oben oder Gruppendruck entsteht dann eine (evt. unbewusste) Ablehnung und es werden kreative Wege gesucht, die “ungeliebten” Aufgaben zu umgehen. ...

Vor längerer Zeit habe ich als Product Owner mit einem Entwickler-Team zusammengearbeitet. Das Team entwickelte mit Java + Vaadin eine Webanwendung. Als sich die Probleme und Bugs häuften und auch teilweise wiederholten, erkundigte ich mich, ob zu den aufgetretenen Bugs auch dazugehörige Unit-Tests beim Beheben erstellt worden seien. Für jeden Bug ein Unit-Test Das Prinzip, für jeden Bug einen Unittest zu schreiben, hat den Zweck, sogenannte Regressions zu verhindern. Damit ist gemeint, dass ein Bug in der Zukunft wieder auftaucht und erneut behoben werden muss. ...

Gestern ergab es sich, dass ein Kollege und ich in eine Refactoring-Session gestolpert sind. Verschiedene Vorschläge ergänzten sich, aber eines hat mir besonders Spaß gemacht… Als erstes schlug mir IntelliJ folgendes vor: Danach ging es direkt mit dem nächsten Hinweis weiter … Meiner Meinung nach ist es extrem wichtig, die richtigen bzw. gute Werkzeuge zu nutzen, um gute Ergebnisse zu erzielen. Dann macht die Arbeit Spaß und das ist jeden € wert, den die Werkzeuge letztendlich kosten.