Brutal Refactoring Game – ein Überlebender berichtet

2 Minuten zum lesen

Ich war diese Woche auf einem Treffen der Java User Group Erlangen Nürnberg. David Tanzer informierte uns kurz über das Brutal Refactoring Game und leitete uns dann durch ein Spiel mit 3 Iterationen.

Angry Girl Frown May 13
Figure 1. Angry Girl Frown May 13, stefendepolo - CC BY

Was ist das Brutal Refactoring Game?

Im Grund ist das Brutal Refactoring Game ein Code Retreat. Man arbeitet zu zweit an einem Rechner. Mittels Test Driven Development (TDD) realisiert man eine vorgegebene Aufgabe. Es gibt einige Standardaufgaben für ein derartiges Coding Kata. Zu einem der bekanntesten gehört wohl Tik-Tac-Toe.

Im Vergleich zu einem “normalen” Kata konzentriert man sich beim Brutal Refactoring Game aber weniger auf die Tests oder den realisierten Code. Als künstliche Einschränkungen wurden in unserem Fall 17 Regeln zum “Code Smell” festgelegt. Ist nur eine dieser Regeln verletzt, muss der Code sofort refakturiert werden. Bevor nicht alle Regeln erfüllt sind, darf kein neuer Test geschrieben werden. Die Regeln beziehen sich dabei nicht nur auf den eigentlichen Code sondern auch auf den Test-Code.

Die komplette Liste der Regeln kann man sich direkt bei David Tanzer herunterladen.

Die Regeln zwingen einen dazu sauberen Code zu schreiben. Über das Für und Wieder der einzelnen Regeln kann man diskutieren – was wir in der abschließenden Retrospektive auch getan haben. In der Praxis wird man sicherlich die eine oder andere Regel ignorieren oder niedriger priorisieren. Wie bei jeden Kata bringen aber gerade die Extreme einen völligen neuen Einblick in die tägliche Arbeit.

Wie brutal ist das Spiel?

Nach der Theorie ging es dann in die Praxis. Wir haben anhand des bekannten Tik-Tac-Toe ein Code Retreat mit drei Durchläufen durchgeführt.

Die zwei Teams sind – nicht unüblich bei Code Retreats – mit völlig unterschiedlichen Ansätzen an die Aufgabe gegangen. Schon ganz am Anfang wurde man durch die Smells aber an der Weiterentwicklung des Codes “gehindert”. Durch das Refactoring wurde der Code aber nicht nur lesbarer. Gerade die Regeln “Primitive obsession” oder “Name not from domain” haben unser Team zu einem wirklich besseren Code getrieben.

Die weiteren Iterationen haben meinen positiven Eindruck vom Brutal Refactoring Game gestützt. Durch im ersten Moment sinnlose Regeln wird der Code immer besser. So werde ich mir auch in der Praxis intensivere Gedanken über die Verwendung von Enums machen. Die Erfahrung im Code Retreat hat gezeigt, dass man durch die „Beschränkung“ der Wertemenge Prüfungen auf Über- oder Unterschreitungen nicht mehr benötigt.

Mir bleibt Danke an David zu sagen für die Einführung in diese interessante Variante eines Code Retreat. Schade war nur, dass nicht mehr als 5 Personen den Weg zu JUG gefunden haben.