Refactoring eines 2 Personen Java Schachs in ein 3 Personen Clean Code Schachs
Was als Herausforderung einer Lehrveranstaltung entstand, wurde schnell zum Herzensprojekt eines kleinen Teams.
3 Personen Schach, neu entwickelte Behavior und Component Architektur, ein frischer Look mittels JavaFX, neue Figuren und Spielzüge — all das schien für uns unerreichbar, als wir auf Basis eines simplen, unüberschaubaren 2-Personen Schachs ein halbes Jahr zuvor beginnen sollten.
Was wir hatten war lediglich ein Team, das sich und seine Fähigkeiten nicht kannte, keine große Ahnung von der Anwendung verschiedener Clean Code Prinzipien, die uns noch bevorstanden, hatte und auf Basis eines Java basierten Chaos von Schachspiel etwas zaubern musste. Wer sich in einer ähnlichen Lage wiederfinden konnte, der weiß, dass es gar nicht so einfach ist, in kürzester Zeit damit etwas anzufangen.
Nun. Unser erster Ansatz bestand zu nächst darin als Team persönlich als auch mit unseren Fähigkeiten zusammen zu finden. Während die ersten ein Git Repository aufsetzten oder am Teamnamen feilten, kümmerte ich mich in dieser Zeit besonders um die Handhabung von Kommunikation und Zusammenarbeit: Ein geeigneter Kommunikationskanal, sowie ein ScrumBan Ansatz über Jira für das Team. Was bei so einem frischen Team dann noch auf keinen Fall fehlen dürfte, war ein geeignetes Teamevent, um überhaupt das Gegenüber kennen zu lernen und als Team zu wachsen.
Diese erste Phase war dabei noch eine sehr Kreative und Verspielte. Da Konzeption für Architektur und Redesign im Raum standen, konnten wir uns durch simples Prototypen behelfen und im Einklang zum Lehrstoff passend unsere neue Applikation ausrichten. Schnell wurde klar, wie wir Verantwortung und Aufgaben ideal im Team verteilen und uns gemeinsam auf ein Ziel commiten konnten. Daraus entstanden dann auch unsere Fachbereiche Architektur, FrontEnd, Test, sowie Clean Code.
Um Releases und Features richtig in unserer Repository zu integrieren, handelten wir unsere Branches nach folgender Struktur:
Features->Development->(Hotfix)->Releases->master
Der originale Code des zwei Personen Schachs hingegen war noch ein großes Chaos. Es gab zahlreiche Clean Code Prinzipien, die uns durch unser Wissen und vor allem durch die Vorlesung zur Verfügung standen. Um das Spiel auf einen geeigneten und nachhaltigen Stand zu bringen, verwendeten wir Folgende davon:
- Composition over Inheritance
- Single Responsibility Principle
- Test automation and test-driven development (TDD)
- Law of Dementer
- KISS principle
- Liskov Substitution Principle
- Dependeny Inversion
In der Ausgangslage des Spiels waren alle diese Prinzipien noch verletzt oder gar nicht existent. Durch die nun eingeführten Prinzipien verschafften wir dem Projekt nicht nur mehr Verständlichkeit, sondern konnten auch größere Schwierigkeiten schnell erkennen und unseren Code besonders nachhaltig entwickeln. Besonders die Entwicklung der Figuren und wählbaren Behaviors der Figuren hat durch unseren Test Driven Development Ansatz äußerst profitiert. Das führte letztlich auch zu einer über 93% Code und über 85% Branch Test Abdeckung im gesamten Projekt. Die 400 (darunter auch zahlreich generierte) Testfälle untermauern dieses Ergebnis. Über gewöhnliches Integrationstesting waren wir dabei längst hinaus. Auch dank End-To-End Testing konnten wir dabei viele Use Cases abdecken.
Auch wenn wir die zahlreichen Klassen des originalen 2-Personen Schachs komplett refactoren,die Struktur noch einmal neu erfinden und die Clean Code Prinzipien anzuwenden müssten, gab es darunter hinaus noch weitere Hürden, die ein Redesign eines solches Projektes mit sich zogen. Auf dem Spielbrett mit drei anstatt zwei Personen galt es nun auch eine geeignete Translation für die Figuren zu finden. Sprich, wie agieren und funktionieren die Figuren über die eigene Spielfeldhälfte hinaus, wenn es nun zwei (anstatt eine) Interaktions- und Feindzone gab.
Zumal gehörte aus unserer Sicht auch eine Aufarbeitung der Grafiken und des User Interfaces für wirkliches Redesign mit dazu. Dies ist durch die nun erhöhte Spieleranzahl von drei Spielern letztlich sowieso nötig geworden. Hierfür entschieden wir uns für eine JavaFX Umsetzung mit Reponsive Design, Menüführung, austauschbaren Themes der Figuren und vielen Anpassungsmöglichkeiten. Das neue 3 Personen Schachfeld wird dafür je nach Anforderung aus einem eigenen Algorithmus hinaus durch einzelne Polygone generiert.
Um das Spiel auch spielerisch zu erweitern, wurde eine neue Figur und ein neues Item erstellt: Das wilde Pferd und die Karotten. Hierbei tauchen zufällig Karotten auf dem Spielfeld auf, die es mit Bauern einzusammeln gilt. Wird eine Karotte eingesammelt, kommt das wilde Pferd langsam immer näher auf den nächsten Spieler mit einer Karotte zu. Erreicht das Pferd den Spieler oder umgekehrt, so ist das wilde Pferd “gezähmt” und der Bauer wird sofort zum Springer.
Durch unsere Architektur von Compositions und Behaviors sind jedoch auch zahlreiche andere Figuren und Items mühelos in das Spiel integrierbar. Lediglich neue Mechaniken benötigen ein neues Behavior.
Fassen wir zusammen. Trotzdem es initiale, größere Hürden gab, entstand aus einer ehemaligen Prüfungsleistung für das Team der Studierenden, ein Projekt mit Herz und Charakter. Letztlich ist ein Spiel entstanden, dass sich zurecht sehen lassen kann und vor allem ein Teamerfolg mit dem sich bis heute jeder identifiziert.
Anmerkung: Mit Rücksicht auf die folgenden Vorlesungen können wir das Projekt leider nicht publizieren.
Mehr interessante Themen und Projekte findet ihr auf meiner Seite: timo-schwan.de
