Bei der INTENSE veranstalten die Clean Code Advocates regelmäßige Coding Dojos. Dort wird in entspannter Atmosphäre ein programmiertechnisches Problem gelöst. Wir nutzen das Format, um Themen wie Clean Code, Test First Development, grafische Konzeption usw. zu schulen. Eingeladen sind alle Mitarbeitenden, die Interesse haben sich technisch zu verbessern. Unabhängig von ihrer bevorzugten Programmiersprache und ihrem Kenntnisstand.
Diesmal haben wir das Format umgekehrt und ein Experiment gestartet: Statt wie oben beschrieben zu entwickeln, durften die Teams diesmal keine automatisierten Tests nutzen, um das Coding Kata so zu lösen. Das Kata, welches wir verwendet haben, ist Wordle:
Kata - Wordle
Implementieren Sie eine Funktion check_guess(), die zwei Parameter akzeptiert. Das Erste ist das erratene Wort ud das Zweite ist das Wort, das der Benutzer finden muss. check_guess() gibt einen String zurück, der die folgenden Zeichen enthält:
- ‚X‘ für jedes Zeichen in der Vermutung, das im Wort enthalten ist, aber sich nicht auf der richtigen Position befindet.
- ‚O‘ für jedes Zeichen in der Vermutung, dass es im Wort enthalten ist aber nicht an der richtigen Position.
- ‚_‘ für jedes Zeichen in der Vermutung, das nicht Teil des Wortes ist.
- Kommt ein Buchstabe im erratenen Wort doppelt vor und im gesuchten Wort nur einmal vor, so wird nur ein Buchstabe im Rückgabestring markiert. Falls einer der beiden Buchstaben richtig positioniert ist, wird dieser Buchstabe im Rückgabestring mit einem X gekennzeichnet.
So starteten die 13 Entwickler*innen und programmierten rund ein Stunde an dem Kata, bis sie zurückmeldeten, dass sie fertig seien. Im Entwicklungsprozess wurde immer offensichtlicher, dass es doch nicht so einfach ist, wie man dachte und es wurde fleißig diskutiert, debugged und die Klasse mit F8 zum Test manuell ausgeführt.
Am Ende des vorgegebenen Zeitfensters wurden dann die Lösungen getestet: Das Moderatorenteam hatte Unit Tests vorbereitet und lies diese über die Lösungen der Gruppen laufen, um zu sehen, ob sie funktionieren.
Hatte eine Gruppe alle Tests grün? Nein.
Komplexe Anforderungen: Darauf sollte man diesmal beim Programmieren achten
In der Reflektionsrunde wurde nach Ursachen gesucht: Die Anforderung war komplex und verwendete für die selben Begriffe teilweise Synonyme. Das machte das Sprechen über das Problem schwierig und kostete Zeit. Ein weiterer Grund ist, das „Testen“ per „Ausführen“ oder Debugger sehr aufwendig und fehleranfällig ist. Außerdem gab es im Laufe der Entwicklung neue Erkenntnisse, was denn doch an Testfällen getestet werden müsse, woraufhin Coding angepasst oder verworfen werden musste. Und dann wieder manuell getestet werden. Zuletzt waren manche Probleme den Teams nicht bekannt, da sie keinen manuellen Testfall dafür gemacht hatten. Alle diese Umstände führten dazu, dass keine der Gruppenlösungen im Erstversuch fehlerfrei funktionierten. Doch aus Fehlern lernt man bekanntlich am meisten.
Daher empfehlen wir, diese Themen wie folgt anzugehen:
- Gute Abstimmung mit dem fachlichen Anforderer vor und während der Entwicklung
- Verwendung einer ubiquitären Sprache, um Begriffe eindeutig zu verwenden in Konzepten, Tests, Code und gesprochener Sprache
- Konzeption einer Entwicklung mit einer leichtgewichtigen Methode – wie baue ich meinen Code auf, welche Methoden gibt es, welche Datenstrukturen
- Erarbeitung von Akzeptanztests mit den fachlichen Anforderern als Abnahmekriterium
- Entwicklung auf Basis eines Test First-Vorgehens
Ist dies immer vollständig möglich? Leider nein. Projektumfelder und Systeme sind komplex. Aber oft ist es möglich Teile davon umzusetzen oder im kleinen zu starten. Somit entsteht schrittweise ein immer saubereres System.
Dominik Panzer
Dominik verantwortet als Entwicklungsleiter die technische Produktentwicklung der INTENSE und unterstützt Teams als Technical Agile Coach in den Bereichen Prozesse, Testautomatisierung, Methodiken und Clean Code. Er ist Initiator der Clean Code Advocate Initiative.
Cacamber als BDD-Framework für ABAP: Ein OSS-Hobbyprojekt unseres Entwicklungsleiters
Kennen Sie folgendes Problem? Neue Funktionen sollen entwickelt werden, aber die Kommunikation mit dem Kunden ist schwierig. Leute reden aneinander vorbei, Anforderungen sind unklar. Und
INTENSE integriert SmartCity-App endios one in Service-Plattform TENTAC
Die Service-Plattform TENTAC der INTENSE AG wird mit neuer Integration erweitert: endios one ist die führende SmartEnergy und SmartCity-App mit Fokus auf Customer Self-Services. Von
DSAG veröffentlicht Leitfaden zu „ABAP Development Tools in Eclipse“
Vor über 10 Jahren wurden die ABAP Development Tools (ADT) für Eclipse als die neue Standard IDE für Softwareentwicklung mit ABAP vorgestellt und bis heute
