Gedanken zur agilen Softwareentwicklung
Im dritten Beitrag über Double Array Tries wird der Code aus Teil 2 weiter bearbeitet und einige Ergänzungen und Verbesserungen vorgestellt. Um uns am obigen Zitat von Kent Beck zu orientieren, sind nun “make it right” und “make it fast” an der Reihe.
In einem früheren Beitrag wurde die Datenstruktur Double Array Trie (DAT) vorgestellt. Zur schnellen Suche von Wörtern werden diese in einer linearisierten Baumstruktur gespeichert. Die einzelnen Knoten des Baumes werden dabei überlappend in die Liste eingefügt. Enthält ein Knoten Lücken, dann können diese durch Werte anderer Knoten aufgefüllt werden. In diesem Beitrag werden Einfügen und Auslesen der DAT Struktur erläutert.
In der Hitze politischer Diskussionen bekommt man hin und wieder Antworten entgegen geworfen, die ganz neue und interessante Gedanken hervorbringen. Kürzlich durfte ich mir anhören, es wäre die autistische Ansicht eines Nerds, so wäre nicht das Leben. Ich fragte mich also, was befähigt z.B. einen Journalisten besser dazu, über die Verfassung zu diskutieren, als einen … Weiterlesen
Eines der interessantesten Features von Spring Boot bemerkt man immer erst dann, wenn es mal nicht da ist. Im Beitrag Frontend Validierung mit Spring Boot (Teil 2) habe ich ein kleinen Framework vorgestellt, das man in eigene Applikationen einbinden kann. Mein Erstaunen war groß, als es gleich beim ersten Mal nicht funktionierte.
Tunnelbauten sind klassische Wasserfall Projekte, in denen ausgiebig geplant und dann ohne große Änderungen der Bau ausgeführt werden kann. Hin und wieder gibt es zwar geologische Überraschungen, aber ein Tunnelplan ist, im wahrsten Sinne des Wortes, in Stein gemeißelt.
In vielen Sourcecode Dateien finden sich Abschnitte wieder, die von Softwareentwicklern liebevoll Toter Code genannt werden
Das Validieren in Java hat viele interessante aber selten benutze Möglichkeiten. In diesem Beitrag geht es um das Kombinieren der Validierungs-Annotationen. Ein zu prüfenden Datum mit verschiedenen Validierungen zu annotieren ist sicherlich bekannt.
In diesem Beitrag wollen wir uns aber eine weniger bekannte Variante anschauen.
Wenn die Wertebereiche der Eingaben im Frontend geprüft werden ist es gut, wenn die Wertebereiche von Frontend und Backend übereinstimmen ist es schön. Elegant wird es, wenn Frontend und Backend ihre Wertebereiche aus der gleichen Quelle erhalten.
Leider zeigt sich hier ein kleines Manko dieses Ansatzes. Die Entitäten für Spring Data müssen annotiert werden, die DTO müssen annotiert werden und das Javascript Framework muss auch die Wertebereiche der Eingabe kennen. Drei verschiedene Konfigurationen konsistent zu halten ist arbeitsintensiv und fehleranfällig.
Streit entbrennt in der Regel darüber, was der Entwickler der Software an weiterer Dokumentation in seinem Code benötigt.
Das Zitat von Cory House “Code is like humor. When you have to explain it, it’s bad.” bringt auf humorvolle Weise ein grundlegendes These auf den Punkt. Schlechter Code wird durch Dokumentation nicht besser.