Random Refactoring

Heute möchte ich über eine Methode sprechen, die ich „Random Refactoring“ nenne, und darüber, wie wir als Führungskräfte die richtigen Rahmenbedingungen dafür schaffen können.

Die Methode

Der Ansatz ist denkbar einfach:

1. Öffne eine zufällige Datei im Projekt.
2. Analysiere kritisch, was sich verbessern lässt.
3. Führe ein klassisches Refactoring dieser Stelle durch (ggf. Tests schreiben, verbessern, …).

Was auf den ersten Blick nach Chaos klingt, hat sich für mich als effektiver Weg erwiesen, die Code-Qualität kontinuierlich zu verbessern. Nebenbei bemerkt kann man sich auch beim zufälligen Auswählen helfen lassen, z. B. mit der „Inspect Code“-Funktion im IntelliJ-Menü „Code“.

Im heutigen Slack-Training haben wir Random Refactoring im Team gemeinsam ausprobiert und innerhalb kurzer Zeit etwa 200 Zeilen redundanten Code (Autowired JpaRepositories) entfernen können.

Verschiedene Wege zur Code-Verbesserung

Wenn wir über Refactoring sprechen, gibt es verschiedene etablierte Ansätze:

Klassische Ansätze

• Boy Scout Rule: „Leave the code better than you found it“ – Bei jeder Änderung wird der Code ein bisschen verbessert.
• Geplante Refactoring-Sprints: Dedizierte Zeiträume, in denen nur refactored wird.
• Systematische Code Reviews: Code-Verbesserungen werden im Review-Prozess identifiziert.
• Opportunistic Refactoring: Code wird verbessert, wenn man „zufällig“ darüber stolpert und gerade Zeit hat.

Random Refactoring im Vergleich

Im Gegensatz zu diesen Ansätzen bietet Random Refactoring einige interessante Vorteile:

• Keine Betriebsblindheit: Wir schauen uns Code an, den wir sonst vielleicht nie anfassen würden. Anders als beim opportunistischen Refactoring warten wir nicht darauf, „zufällig“ über problematischen Code zu stolpern, sondern suchen aktiv danach.
• Lerneffekt für das Team: Die gemeinsame Analyse fördert den Wissensaustausch. Während klassische Code Reviews oft unter Zeitdruck stattfinden, nehmen wir uns hier bewusst Zeit zum Lernen.
• Niedrige Einstiegshürde: Im Gegensatz zu ganzen Refactoring-Sprints muss man nicht erst den „perfekten Moment“ abwarten.
• Breite Abdeckung: Über die Zeit werden auch vernachlässigte Bereiche verbessert, die bei der Boy Scout Rule oder opportunistischem Refactoring möglicherweise nie angefasst würden.
• Systematischer Zufall: Anders als beim opportunistischen Ansatz überlassen wir die Auswahl nicht dem Zufall des Tagesgeschäfts, sondern schaffen aktiv Gelegenheiten zur Verbesserung.

Besonders spannend finde ich den Vergleich zum opportunistischen Refactoring: Während dort die Gelegenheit zur Verbesserung eher passiv abgewartet wird, gehen wir beim Random Refactoring aktiv auf die Suche. Wir schaffen sozusagen „geplante Zufälle“ – ein scheinbarer Widerspruch, der sich in der Praxis als sehr effektiv erweist.

Die wahre Herausforderung: Enablement

Als Führungskräfte in der Software-Entwicklung haben wir die Aufgabe, die richtigen Rahmenbedingungen zu schaffen.

Psychologische Sicherheit schaffen

Ein oft übersehener, aber kritischer Aspekt ist die Angst vor Bloßstellung. Wenn wir „zufällig“ Code analysieren, stoßen wir zwangsläufig auf Stellen, die verbesserungswürdig sind. Hier ist es wichtig zu verstehen: Code-Qualität ist keine persönliche Eigenschaft.

Folgende Punkte haben sich in meiner Erfahrung als hilfreich erwiesen:

• Eigene „Fehler“ zugeben: Als Führungskraft gehe ich voran und zeige auch meinen „schlechten“ Code.
• Kontext berücksichtigen: Code entsteht nicht im luftleeren Raum. Zeitdruck, fehlendes Wissen oder alte Framework-Versionen können zu suboptimalen Lösungen führen.
• Positive Formulierung: Statt „dieser Code ist schlecht“ sagen wir „hier sehe ich Potenzial für Verbesserungen“.
• Gemeinsames Lernen: Random Refactoring als Team-Event etablieren, bei dem alle voneinander lernen.

Zeit einräumen

Die größte Hürde ist oft nicht technischer Natur, sondern der gefühlte Zeitdruck.

„Dafür haben wir keine Zeit“

ist ein Totschlagargument, das wir aktiv bekämpfen müssen. Mein Ansatz:

• Explizite Zeit für Refactoring ermöglichen
• Das Mindset schaffen, dass Refactorings gut und wichtig sind
• In unregelßigen Abständen selbst mit dem Team Refactorings durchführen (dabei aber darauf achten, dass nicht ich selbst an der Tastatur sitze)

Wissen teilen

Random Refactoring funktioniert nur, wenn das Team die nötigen Fähigkeiten hat:

• Pair-Programming-Sessions für Refactoring
• Code-Review-Kultur etablieren
• Regelmäßige Workshops zu Clean Code und Refactoring-Patterns

Fazit

Random Refactoring kann nur in einer Atmosphäre des Vertrauens und der psychologischen Sicherheit funktionieren. Als Führungskräfte müssen wir aktiv daran arbeiten, diese Sicherheit aufzubauen und zu erhalten.

Wenn ein Teammitglied Angst hat, dass sein Code als Zeichen mangelnder Fähigkeiten gewertet wird, werden wir keine ehrliche Diskussion über Verbesserungspotenziale führen können. Stattdessen müssen wir eine Kultur etablieren, in der Code-Qualität als gemeinsame Verantwortung und kontinuierlicher Lernprozess verstanden wird.

Random Refactoring ist mehr als nur eine Technik – es ist eine Kultur der kontinuierlichen Verbesserung. Unsere Aufgabe als Führungskräfte ist es, diese Kultur zu ermöglichen und zu fördern.

Das bedeutet auch, manchmal gegen den Strom zu schwimmen und dem Team den Rücken zu stärken, wenn der Druck von außen zunimmt. Denn langfristig zahlt sich die Investition in Code-Qualität immer aus.

Meine Erfahrung zeigt: Wenn wir unseren Teams den richtigen Rahmen und das nötige Vertrauen geben, entstehen oft erstaunliche Verbesserungen – auch und gerade durch scheinbar „zufällige“ Initiativen.