Agile Coding mit Java, Kotlin, Spring und Microservices

Mit Clean Code ist man nie fertig... Als ich mir den Code zu meinem vorherigen Clean Code Artikel ein zweites und drittes Mal angeschaut habe, habe ich immer wieder neue Punkte gefunden, die nicht so richtig sauber waren. Deshalb möchte ich in diesem Artikel weitere Beispiele für Clean Code anhand meiner Minesweeper Demo zeigen . Im Code zum Artikel wird das Spiel Minesweeper implementiert, die Regeln findet ihr  hier .  Den kompletten Code von mir findet ihr in GitHub: https://github.com/elmar-brauch/minesweeper.git Und ein passendes Online-Training bei Udemy . Verzicht auf (unnötige) Setter Häufig generieren wir für alle Attribute unserer Klassen Getter und Setter Methoden. Das hat zum Beispiel den Nachteil, dass wir ungenutzte und damit unnötige Attribute in unserer Klasse nicht erkennen, da sie vom Getter und Setter genutzt werden.  In der Klasse Cell des Minesweeper Spiel ist mir aber noch ein 2. Nachteil aufgefallen. Aus Clean Code wissen wir, dass die optimale Methode keine Para

In diesem Artikel stelle ich euch einige von mir ausgewählte Clean Code Richtlinien und Regeln vor. Sie sollen euch dabei helfen künftig leichter verständlichen und besser wartbaren Code zu schreiben, damit ihr euren KollegInnen das Entwickler-Leben angenehmer macht. Im Code zum Artikel wird das Spiel  Minesweeper  implementiert - ihr findet den Code in GitHub: https://github.com/elmar-brauch/minesweeper.git Und ein passendes Online Training bei Udemy . Namen mit Bedeutung Regel: Verwende Namen, welche die Absicht der Variable, Methode oder Klasse verraten. Im folgenden Code-Ausschnitt habe ich Kommentare ergänzt, um auf schlechte oder zumindest suboptimale Variablennamen hinzuweisen: public class MineField {      // Not optimal names: cells, field, listOfListOfCells, ...      private List<List<Cell>> fieldRows = new ArrayList<>();      ...      // Bad names: x, y, r, c      public MineField(int rows, int columns) {      ...      public void placeMineRandomly(int min

Automatisiertes Testen von Spring Beans kann anfangs schwierig sein. Daher zeige ich euch in diesem Artikel, wie ihr die typischen Herausforderungen beim Testen von void-Methoden, Datenbank- und Backend-Interaktionen mit Spring Boot und Mockito in den Griff bekommt. Unit-Tests mit dem Mockito Mock-Framework Wenn wir in einer Klasse oder Spring Bean Methoden haben, die eine Datenbank oder die Verfügbarkeit eines Backends benötigen, ist das für Unit-Tests ein Problem. Unit-Tests konzentrieren sich immer auf die kleinste Einheit und die schließt Datenbanken und Backends aus. Um solche Methoden trotzdem Testen zu können, gibt es Mocks. Ein Mock ersetzt die Datenbank oder das Backend und liefert von uns vorbereitete Testdaten zurück. Weitere Infos zu Mocks findet ihr hier: https://de.wikipedia.org/wiki/Mock-Objekt Mockito ist eines der beliebtesten Mock-Frameworks für Java oder Kotlin und bietet eine einfache API zum Erstellen, Konfigurieren und Interagieren mit Mocks an. Daher wird Mockito

Testgetriebene Entwicklung besteht aus 3 Schritten: Rot: Schreib ausreichend viele fehlschlagende Unit Tests. Grün: Schreib nur so viel Code (nicht mehr), dass alle Unit Tests grün sind. Blau: Falls nötig, refaktorisiere den Code und Deine Unit Tests. In diesem Blog-Artikel werde ich das anhand des Clean Code Bowling Game Katas in der Programmiersprache Kotlin mit JUnit Tests demonstrieren. Testgetriebene Entwicklung Ich kenne testgetrieben Entwicklung aus Extreme Programming (von Kent Beck) und Clean Code (von Robert C. Martin). Dort wird der TDD-Zyklus als Entwicklungsprozess in 3 sich wiederholenden Schritten beschrieben. Im folgenden Bild zeige ich den Zyklus mit den entsprechenden Farben, die aus dem Status der Testergebnisse abgeleitet sind. Rot - Test schlägt fehl In der ersten Phase ROT wird mindestens ein neuer Testfall geschrieben oder ein bestehender erweitert. Wichtig ist dabei, dass dieser Testfall dann fehlschlägt, daher die Status Farbe Rot. Es ist auch erlaubt mehrere T