Agile Coding mit Java, Kotlin, Spring und Microservices

In Corona-Zeiten sind Team-Events rar geworden und trotz Video-Konferenz eher mäßig beliebt. Sicherlich gibt es hier auch schon einige gute Konzepte - ein weiteres Event-Konzept speziell für Software-EntwicklerInnen habe ich im Urlaub entdeckt: das virtuelle Clean Code Dojo. Das Clean Code Dojo Im Buch "The Clean Coder" erklärt Onkel Bob, wie wichtig Training für Software-EntwicklerInnen ist. Teil des Trainings sind natürlich auch alle möglichen Lernkonzepte, wie z.B. Schulungen, Fachbücher, Blogs, Podcasts usw. Er stellt aber auch eine weitere Trainings-Form vor, welche aus dem Kampfsport abgeleitet ist: das "Coding Dojo". In Onkel Bobs altem Blog gibt es dazu ebenfalls einen Eintrag:  http://www.butunclebob.com/ Hier auch noch der Link zum aktuellen Clean Coder Blog:  https://blog.cleancoder.com/ Im Coding Dojo führen die trainierenden SchülerInnen Katas aus, so wie ihr es aus Karate kennt:  Wikipedia Kata . Nur sind diese Katas keine Tritt- und Schlag-Choreografi

Clean Code ist auch im Unit-Test Pflicht. Hier schreibe ich eine saubere JUnit 5 Testklasse und übersetze sie anschließend in einen Spring Boot Test. Außerdem zeige ich ein paar JUnit 5 Features zum Parametrisieren von Tests und zum Testen von Exceptions. (JUnit 5 Logo 😮) Clean Code im JUnit Test Das Schreiben von möglichst einfachem und gut wartbaren Code (Clean Code) ist für viele Entwickler selbstverständlich. Die Unit-Tests zu diesem Code haben leider häufig eine schlechtere Code-Qualität. Dabei sollte es eigentlich bekannt sein, dass auch Unit-Tests leicht verständlichen und gut wartbaren Code benötigen, insbesondere wenn sie regelmäßig und automatisiert ausgeführt werden. In einem der bekanntesten Bücher zum Thema Clean Code von Robert Martin , gibt es deshalb ein eigenes Kapitel zu JUnit. Ich zeige euch nun einen JUnit Test und erkläre dann, welche Clean Code Prinzipien ich dabei angewendet habe. Getestet wird der InMemoryItemStore , den ich in einem früheren Blog-Post kernkonz

Clean Code ist ein wichtiges Thema, das manchmal aufwändig und langweilig sein kann. So musste ich vor kurzem in circa 100 Klassen überflüssige Annotationen löschen 😒 Statt Eclipse nutzte ich die Linux-Shell und sed, um alle Dateien mit einem Befehl aufzuräumen. Wie das genau geht, zeige ich euch hier. Das Problem bzw. der dreckige Code Die Modell-Klassen unserer Anwendung wurden früher zum Parsen von JSON in Java-Objekte und zum Schreiben per JPA in eine relationale Datenbank verwendet. Nach einem Redesign werden die Modell-Klassen nur noch zum Parsen von JSON Texten verwendet, so wie ich es z.B. hier zeige  rest-json-apis-in-java-leicht-gemacht.html . Im Zuge des Redesigns wurde leider vergessen die nun ungenutzten JPA Annotationen in den Modell-Klassen zu entfernen. Konkret sehen alle Klassen ungefähr so aus: import javax.persistence.CascadeType; import javax.persistence.Column; import javax.persistence.Entity; import javax.persistence.EnumType; import javax.persistence.Enumerated;

Security ist mittlerweile ein allgegenwärtiges Thema. SQL-Injection oder Cross-Site Scripting Angriffe sind klassische Bedrohungen, die mittels Validierung aller Eingabedaten abgewehrt werden können. Macht man das ungeschickt, ist es aufwändig und unsicher. In diesem Artikel zeige ich euch, wie man auf einfache Weise per Annotation den eigenen Spring Web-Service absichert. Der harte Weg: Validierung im Java Code Die beste Methode SQL- oder Code-Injection Angriffe zu verhindern, ist Eingaben dieser Art nicht zu erlauben. Auf die Details wie diese Art von Angriffen funktionieren, möchte ich hier nicht eingehen - ihr könnt es aber z.B. hier nachlesen: https://de.wikipedia.org/wiki/SQL-Injection https://en.wikipedia.org/wiki/Code_injection Wichtig ist, dass die Überprüfung der Eingabedaten Server-seitig stattfinden, da Hacker Client-seitige Eingabevalidierung (z.B. mit JavaScript im Browser) umgehen können. Mit Java könnte man die Überprüfung der Eingabedaten mittels regulärer Ausdrücke du