Agile Coding mit Java, Kotlin, Spring und Microservices

How to run IT applications stable in production? Instead of providing one more operations readiness checklist, I created an IT Stability health radar. This helps in agile projects to choose the next stability improvement depending on current situation. All non-functional requirements in this health radar are prioritized by levels, so that you and your Product Owner can plan them properly. IT Stability Health Radar Companies have often operations readiness checklists, which describe what to do before customers can use an IT system in production. These long lists with non-functional requirements are not easy to use and fulfill in agile working environments. Product owners and business stakeholders have a hard time to accept these requirements, if they come all at the same time and might block a big part of the team for several weeks.  In this article I focus on non-functional requirements related to IT stability. I group and order them, so that you learn where to start and which stabilit

Hebt KI die Software-Entwicklung auf ein neues Level? Sind EntwicklerInnen mit KI Support schneller als ohne? Diesen Fragen stellen wir uns bei der Deutschen Telekom IT GmbH. Dazu führten mein Team und ich eine Evaluierung von GitHub Copilot durch. Ich stelle euch hier die Ergebnisse und Meinungen des Teams vor. Warum Copilot? Copilot integriert sich in die Entwicklungsumgebung der Programmierenden. Es analysiert den vorhandenen Sourcecode und macht mittels KI unterstützter Text-Completion Vorschläge für weiteren Code. Diesen können die ProgrammiererInnen per Tastendruck übernehmen. Das beschleunigt insbesondere das Schreiben von sich wiederholendem Code. Copilot in der Praxis ChatGPT hilft EntwicklerInnen bei technischen Fragestellungen. Dazu unterbrechen wir das Schreiben von Code in der IDE, öffnen im Browser die Chat-KI und stellen unsere Frage oder Anforderung. Mit der Antwort von ChatGPT wechseln wir in die IDE und probieren sie aus. Im Unterschied zu ChatGPT unterstützt Copilot

Performanz-Problemen sind meist schwierig zu lösen. Hier zeige ich euch, wie wir unser letzten Problem analysiert, gemessen und gelöst haben. Unter dem Zeitdruck des bevorstehenden Go-Lives wählten wir Strategien, um Risiken durch Seiteneffekte zu vermeiden. Analyse von Performanz-Problemen Aus Kundensicht ist unser System eine Browser-Anwendung. Wenn die Seiten im Browser langsam laden, haben wir ein Performanz-Problem. Die Diskussion, was langsam bedeutet und ob langsame Ladezeiten in manchen UseCases akzeptabel sind, ignoriere ich hier. Unsere Situation war eindeutig, statt Ladezeiten von 1-2 Sekunden dauerte es in einigen Fällen mehr als 10 Sekunden. Logs sind ein guter Startpunkt für die Analyse. Eventuell habt Ihr einen Log-Eintrag am Anfang und Ende der Anfrage. Mit den Zeitstempeln dieser beiden Log-Einträge könnt Ihr die Bearbeitungsdauer der Anfrage überprüfen. Das bestätigt objektiv euer Preformanz-Problem. Wo treten Performanz-Probleme auf? In unserem Fall betraf das Perfor

Wie schaffen wir es komplexe monolithische Systeme so zu zerlegen, dass die einzelnen Sub-Systeme leicht und unabhängig voneinander entwickelt werden können? In diesem Erfahrungsbericht zeige ich, wie wir ein Shopping-Portal in Microservices und Self-Contained-Systems (SCS) zerlegt haben. Der Artikel ist ein Erfahrungsbericht und beschreibt nur unseren Weg. Es gibt hier sicherlich viele alternative Lösungen. Mit Sicherheit gibt es auch rein Microservice-basierte Architekturen, welche die hier gezeigten Probleme lösen könnten. Video-Präsentation zum Artikel Ausgangssituation: der Monolith Monolithen werden in der IT häufig als einzelnes System beschrieben, das alle Funktion beinhaltet, siehe  https://www.itwissen.info/Monolithische-Software-Architektur.html . Nach dieser Definition hätten wir eigentlich kein Problem, da ich hier ein Content-basiertes Shopping-System betrachte, welches diverse Backend-Systeme über REST-APIs aufruft, die Teile der Funktionalität bereitstellen, z.B. einen

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

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

Texas Holdem, Omaha Hi-Low - echte Coder spielen Planning Poker 😎 In diesem Artikel stelle ich vor, wie wir im Rahmen unserer Scrum Zeremonien pokern und gebe euch so einen Einblick in unsere SAFe Refinement Runden. Einführung Ich arbeite in einem Scrum-Team, das Teil eines größeren Bereiches ist, in dem es noch viele weitere Scrum-Teams gibt. Mein Bereich Magenta Business organisiert sich nach dem Scaled Agile Framework (SAFe). Scrum und SAFe Scrum ist ein Vorgehensmodell zur agilen Softwareentwicklung. Die zu entwickelnde Software wird dabei in Form von User Stories beschrieben. Weitere Infos zu Scrum findet ihr z.B. hier: https://de.wikipedia.org/wiki/Scrum SAFe ist ein Framework, das die Zusammenarbeit mehrerer Scrum-Teams organisiert. Dabei macht es Vorgaben, die in Teilen die Freiheitsgrade eines einzelnen Scrum-Teams einschränken. Weitere Infos zu SAFe gibt es hier: https://www.scaledagileframework.com Planning Poker Eine beliebte und gängige Methode zum Schätzen der Umsetzungs