Thoughts on agile software development
Jens It is a mistake to look too far ahead. Only one link of the chain of destiny can be handled at a time. Winston Churchill Obwohl das Law Of Demeter den folgenden Aufruf zu Recht verteufelt, hat man es, in der holprigen Projektwelt, immer wieder mal mit solchen Verkettungen zu tun. In diesem Beispiel kennt … Read more
Spricht man mit manchen Kollegen über den Spring Boot Framework, dann erscheint ihnen vieles daran suspekt. Aus einigen wenigen Klassen werden durch ein Dutzend Annotationen an der richtigen Stelle vollwertige REST Schnittstellen.
Vermutlich erinnern die Annotationen an verfluchte Hexenzeichen, die dem markierten Objekt magische Eigenschaften verleihen. Annotationen sind aber nur Konfigurationshinweise für den Framework, damit der eigentliche Anwendungscode nicht zwischen den, ansonsten notwendigen Boilerplate Code, verloren geht.
Lange Zeit habe ich mir das JUnit 5 Feature Test Interfaces nicht angeschaut, vermutlich weil mir default Methoden in Interfaces noch immer ein wenig suspekt sind. Langsam freunde ich mir mit diesen eigenartigen Schimären an und freue mich, endlich ein schönes Beispiel für Test Interfaces gefunden zu haben.
Kürzlich las ich bei Martin Fowler einen interessanten Artikel zu einem Design-Pattern von Pete Hodgson. Dazu schossen mir sogleich zwei Ideen durch den Kopf. Zuerst die Frage, warum erst jetzt diese Pattern formuliert wird und gleich darauf der Gedanke, eine meiner Klassen schleunigst umzuschreiben.
Kennen Sie die Türen auf der Herz aus Gold? Diese Dinger mit einem akustischen Hinweis auf ihr eigentlich lautloses Öffnen und Schließen, das nicht nur den Roboter Marvin störte.
Es ist noch nicht so lange her, da lebte die Computer Industrie in einem Sprachwirrwar biblischen Ausmaßes. Als wäre der Turm zu Babel direkt über den Computerterminals zusammengebrochen, ersannen alle Organisationen und Hersteller ihre eigenen Zeichensatzkodierungen.
Die Verwendung von boolschen Ausdrücken ist ein Faktor, der die Lesbarkeit und das fehlerfreie Verständis eines Algorithmus maßgeblich beeinflusst. Schon im Beitrag Zauberei mit Wahrheiten wurden einige Probleme von komplizierter Logik angesprochen. Hier nun ein paar neue Beispiele für Code Smells, die sich um Wahrheitswerte ranken.
Die Aufgabenstellung klingt dieses mal trivial. Eine Methode wird benötigt, um ein großes Set in viele kleine zu zerlegen. Die Legacy Variante verwendet, eine Methode, die nur auf Listen arbeitet. Daher wird aus dem Set eine List, daraus eine List von List und daraus am Ende eine Collection von Set. Da das ursprüngliche Set, als Endprodukt eines Stream Ausdrucks das Licht der Welt erblickt, wäre eine dazu passende Lösung vorteilhaft.
Vor einigen Tagen las ich von einer interessanten Anekdote aus dem zweitem Weltkrieg. Da ich diese Geschichte unbedingt teilen möchte, verfasse ich diesen Beitrag ohne die übliche Moral oder den offensichtlichen Parallelen in der Software Entwicklung. Ich denke aber, dass am Ende dieses Beitrags, jeder seine eigenen Lehren aus der Geschichte zieht.
Auf der Suche nach einem schönen Bild für meinen Beitrag über das Stockholm Syndrom, stolperte ich über das Bild der Vasa. Die Vasa war ein Schlachtschiff und sie wäre sicherlich die Perle der schwedischen Kriegsmarine geworden, wenn das Projekt nicht so verdammt schief gelaufen wäre.