Eine Learning Hour für die sechs core Refactorings

Einleitung

Refactoring ist eines dieser Themen, von dem wir wissen, dass es sinnvoll ist – und trotzdem bleibt es im Alltag schwierig, dafür Zeit und Sicherheit zu finden. Besonders dann, wenn keine Unit Tests vorhanden sind, schwingt immer dieses kleine Risiko mit: „Was, wenn ich etwas kaputtmache?“  

In dieser Learning Hour setzen wir genau hier an. Wir probieren gezielt sechs Core Refactorings aus, die du auch ohne vorhandene Tests sicher anwenden kannst. Diese kleinen, überschaubaren Schritte machen den Code leichter nachvollziehbar und helfen im besten Fall den Weg zu mehr Testbarkeit zu öffnen.  

Das Format ist bewusst kompakt und interaktiv gehalten – ideal, um gemeinsam im Team zu lernen. Wenn du also schon immer Refactoring stärker in deinen Entwickler-Alltag bringen wolltest, aber dich gefragt hast, wie du anfangen kannst: Das hier ist eine einfache, praxiserprobte Methode mit überschaubarem Aufwand. Der zeitliche Aufwand für das Team liegt bei etwa 60 Minuten und basiert auf der bewährten 4C-Struktur:

  1. Connect (Einstieg und Aufwärmen)
  2. Concept (Konzeptvermittlung)
  3. Concrete (praktische Übungen) und
  4. Conclude (Abschluss und Reflexion)

Das Team lernt neue Fähigkeiten - wie in diesem Beitrag einfache Refactorings - schnell und eigenständig. Die Seite sammamcoaching bietet viele englischsprachige Quellen zum Thema und ist ein toller Einstieg.

Übersicht und allgemeine Hinweise zur Durchführung

Unten die Zeitplanung und mögliche Methoden für die Umsetzung. Der Fokus einer Learning Hour sollte immer auf Interaktivität und Praxis liegen.

Phase Inhalt Methode Dauer
Connect

Eine Einsteigsfrage zum Reinkommen: 

  • Was für eine Einstellung benötigt erfolgreiche Refactoring Tätigkeit?
  • Wie wichtig ist es, den Code fachlich zu verstehen?
 1-2-All 8 Minuten
Concept Teile alle Teilnehmer in kleine Gruppen ein. Jede Gruppe erklärt ein Refactoring aus einer Liste anhand von farigen Post-Its. Expert Table 20 Minunten
Concrete Alle sechs core refactorings werden an einer code Kata geübt. Team Programming mit Typist und Federated Navigator 30 Minuten
Conclude Schreibe eine Email an einen Teilnehmer: Was nimmst du mit und was kannst du direkt umsetzen? Email schreiben wenn man wieder am Platz sitzt. 2 Minuten

 

Entscheidend für eine gute Learning Hour ist  wie schon erwähnt die aktive Zusammenarbeit. Damit der eng getaktete Rahmen gut funktioniert, braucht es eine solide Planung und ein bewusst gewähltes Setting.

Meine persönliche Meinung: Vor Ort funktioniert es am besten – remote ist aber gut machbar.

Vor-Ort-Setup

Für eine Learning Hour im Team benötigt ihr ein kollaboratives Umfeld, einen Raum mit:

  • einem großen Monitor, auf dem alle denselben Code sehen,
  • einer Entwicklungsumgebung auf einem gemeinsam genutzten Rechner.

Zusätzlich helfen einfache analoge Materialien:

  • Post-its für eure Sessiondokumentation
  • ein Brownpaper, Flipchartpapier oder freie Wandflächen zum Bekleben.

Für mich hat es sich bewehrt den Post-it Farben eine Gruppenübergreifende Bedeutung zu geben. Hier mein Vorschlag für diese Learning Hour

  • 🟥 Rot für Gefahren oder Grenzen
  • 🟨 Gelb für Informationen
  • 🟩 Grün für positive Effekte
  • 🔷 Für Überschriften oder Kategorien

Wenn ihr Personen mit Farbblindheit oder Rot / Grün Schwäche habt, arbeitet einfach mit Symbolen.

Remote-Setup

Wenn euer Team verteilt arbeitet, könnt ihr die Session auch online durchführen. Achtet darauf, dass die Technik stabil läuft und dass alle wissen, wie das Setup funktioniert.

Bewährt hat sich:

  • ein Videokonferenzsystem mit Breakout-Räumen,
  • ein gemeinsam genutztes Online-Whiteboard (z. B. Miro, Canva, Conceptboard).

Gute Vorbereitung spart in der Session selbst Zeit. Prüft am besten vorher:

  • Können alle Teilnehmenden mit dem Toolset umgehen?
  • Gibt es für jede Kleingruppe eine vorbereitete Whiteboard-Vorlage?
  • Kennt jede:r die Grundfunktionen der Videoplattform?

Generelle Hinweise

Gerade wenn euer Team dieses Format zum ersten Mal durchführt, hilft Orientierung. Nicht alle kennen Methoden wie 1‑2‑All oder Rollen aus dem Team Programming – gebt also Sicherheit durch klare Strukturen.

  • Gestaltet die Phasen so, wie es euer Team gewohnt ist.
    Wenn Team Programming neu ist, wählt z. B. eine Person als Typist, die aktiv Input vom Team einholt.
  • Hängt ein Flipchart oder Whiteboard mit „Inhalt und Regeln“ jeder Phase gut sichtbar auf.
    So wissen alle, was Typist und Navigator tun, wann gewechselt wird und wie lange Runden dauern.
  • Verwendet visuelle Hilfen – kleine Sketchnotes oder Symbole machen das Ganze anschaulich und professionell.

Durchführung der einzelnen Phasen

1. Connect

In der Connect‑Phase geht es darum, gemeinsam ins Thema hineinzufinden und eine erste Verbindung zum eigenen Entwickleralltag herzustellen. Diese kurze Einstiegsrunde läuft hier drei Schritten ab:

Runde Aktivität Dauer
1 Für sich alleine. Auf Post-its notieren 2 Minuten
2 Mit einer Person austauschen 3 Minuten
All Die Quintessenz der gesamten Gruppe mitteilen 4 Minuten
 

2. Concept

Verstehen, bevor wir üben. In der Concept‑Phase geht es darum, ein gemeinsames Verständnis über die sechs Core Refactorings zu schaffen, bevor der praktische Teil beginnt. Die Teilnehmenden arbeiten in Zweierteams und erarbeiten jeweils ein bis zwei der sechs Techniken. So entsteht in kurzer Zeit ein kollektives Bild.

Als Moderator leitest du diese Phase mit einer klaren Aussage ein: 

„Es gibt sechs kleine, aber zentrale Refactorings, die so einfach sind, dass sie keine Unit‑Tests erfordern – aber richtig eingesetzt erst den Weg zu lesbaren Code öffnen.“

Danach verteilst du die sechs Themen und erklärst die Arbeitsweise:

Jede Gruppe nutzt die Materialien, die sie zur Hand hat – Notebooks, Bücher, IDE, Handy – und erstellt eine kurze visuelle Darstellung (z. B. mit Post‑its). Die Darstellung kann in Form einer Mind‑Map, Liste, Context Map oder anders erfolgen. Wichtig ist nicht das Layout, sondern das gemeinsame Nachdenken darüber, wann und wie das jeweilige Refactoring angewendet wird.

Im Anschluss präsentieren die Teams ihre Erkenntnisse den anderen Gruppen.

Um die Ergebnisse besser vergleichbar zu machen, nutzt ihr Farbmarkierungen für die Inhalte der Post‑its:

  • 🟨 Gelb – Information oder Beschreibung: Was genau macht dieses Refactoring, und wie funktioniert es in der IDE?
  • 🟥 Rot – Gefahren oder Grenzen: Wann ist Vorsicht angesagt? Wo verliert das Refactoring seinen Nutzen?
  • 🟩 Grün – Positive Wirkung: Welche Verbesserungen entstehen? Wie trägt es zu Lesbarkeit oder Testbarkeit bei?

Diese farbliche Systematik sorgt dafür, dass ein gemeinsames Foto aller Gruppen später leicht ausgewertet werden kann. So hat jede Session ein visuelles Gesamtbild, das euer erlangtes Wissen bündelt. Deine Aufgabe als Moderator in dieser Phase sind:

  • Alle Teilnehmer verstehen den Ablauf
  • Du stehst für Rückfragen zur Verfügung
  • Du sorgst für das Einhalten der Zeit

3. Concrete Practise: Team Programming

Die Concrete‑Phase dauert 30 Minuten. In dieser Zeit üben die Teilnehmenden an einer kleinen Refactoring‑Kata in Form eines Team - Programmings. Team Programming ist eine erweiterte form des Pair Programmings. Es wird hier sehr detailliert beschrieben. Beim Team Programming bedient eine Person die IDE und die anderen geben vor, was umzusetzen ist, Es gibt Rollen

  • Typist: Bedient die IDE und setzt die Anweisungen um.
  • Navigator: Gibt Anweisungen, bewertet Vorschläge, fordert Input ein und sorgt dafür, dass leise Stimmen Gehör finden.
  • Crowd: Beobachtet, bringt Vorschläge ein und diskutiert Verbesserungsansätze.

Der Quellcode wird auf einem großen Bildschirm gemeinsam betrachtet und weiterentwickelt.

Die Rollen wechseln alle 5 Minuten, sodass in 30 Minuten insgesamt 5 Runden entstehen. Der Moderator achtet auf den regelmäßigen Wechsel und die konsequente Einhaltung der Rollen.

Das Refactoring selber kann an frei verfügbaren Katas, wie der

geübt werden.

Ziel der praktischen Phase ist es, die sechs Core‑Refactorings praktisch auszuprobieren — vor allem einfache Schritte wie Rename Things, Inline Temporary Variable oder Extract Method — und dabei zu erleben, wie kleine, nachvollziehbare Änderungen die Lesbarkeit des Codes verbessern.

Benötigte Materialien

  • Computer oder Laptop mit funktionierender Entwicklungsumgebung (IDE).
  • Projektdateien der gewählten Kata (lokal geklont oder heruntergeladen).
  • Timer für die 5‑Minuten‑Wechsel.
  • Sichtbare Rollenbeschreibung (z. B. Flipchart oder Whiteboard).
  • Beamer oder Bildschirmfreigabe für die Arbeit in der Gruppe

Hinweise für den Ablauf

Auch wenn die Fülle der unteren Punkte und Hinweise etwas anderes suggereieren. Die wichtigeste Regel ist Gib den Teilnehmern Zeit zum Denken, sowie Halte die Stille aus!. Eine Gruppe benötigt Zeit sich zu finden.

  • Rollen klar trennen: Teilnehmende neigen dazu, durcheinander zu reden oder mehrere Rollen gleichzeitig einzunehmen. Moderator erinnert freundlich an die vereinbarte Struktur.
  • Fokus auf kleine Schritte, Ziel im Auge behalten: Ziel ist nicht, den ganzen Code umzubauen, sondern bewusste, sichere Refactoring‑Schritte zu üben.
  • Kommunikation beobachten: Leise Teilnehmende gezielt ansprechen oder vom Navigator aktiv einbinden lassen.
  • Tempo steuern: Wenn Gruppen zu tief in technische Details abdriften, an die Übungsziele und die verbleibende Zeit erinnern.

Deine Rolle als Moderator ist es Impulse zu geben, und nicht zu einer (deiner) Lösung hin zu führen. Das ist gerade am Anfang schwer. Daher helfen dir diese Punkte vieleicht klar zu werden, was deine Aufgabe als Moderator eines Team Programming Events ausmacht:

  • Zeit im Blick behalten: Sorge dafür, dass der Timer sichtbar läuft und die Wechsel pünktlich erfolgen. Eine rechtzeitige Ankündigung kurz vor Ablauf hilft beim flüssigen Übergang.
  • Ruhige Momente zulassen: 60 Sekunden Stille sind kein Problem – oft entstehen in diesen Pausen gute Beobachtungen oder Aha‑Momente.
  • Refactoring sichtbar machen: Lass den Typist kurz vor und nach einer Änderung zeigen, wie sich der Code verbessert hat.
  • Kleine, sichere Schritte fördern: Lieber ein einfaches, sauberes Refactoring durchführen als ein riskantes, halbfertiges Experiment.
  • Erwartungen klären: Formuliere zu Beginn, dass es um Übung, nicht um Produktivcode geht – das nimmt Druck.
  • Prozess moderieren, nicht führen: Stelle Fragen, die Denken anregen, statt technische Lösungen vorzugeben.
  • Erfolge anerkennen: Kurzes positives Feedback („gute Namenswahl“, „jetzt deutlich lesbarer“) verstärkt Lerneffekte.

Fragen als Hilfestellung

Falls dein Team nicht weiterkommt, oder abdriftet, kannst du mit diesen Fragen Impulse geben. Die Fragen sind bewusst offen und erfordern keine richtige Antwort.

  • Was fällt euch am aktuellen Code besonders auf, bevor ihr etwas verändert?
  • Welche kleine Änderung würde den größten Unterschied in der Verständlichkeit machen?
  • Wie würdet ihr jemandem erklären, was dieser Codeabschnitt gerade tut?
  • An welcher Stelle unterstützt euch die IDE gerade – oder wo tut sie es nicht?
  • Woran würdet ihr merken, dass dieser Teil jetzt lesbarer oder klarer geworden ist?
  • Wenn jemand mit stärkerem fachlichen Hintergrund und weniger Technikwissen den Code morgen liest – was würde der oder die vermutlich denken?
  • Was würde euer zukünftiges Ich, das diesen Code in sechs Monaten wieder anfasst, euch jetzt raten?

4. Conclude

Die Concrete‑Phase bildet den praktischen Kern der Learning Hour. Hier wenden die Teilnehmenden das Gelernte aktiv an und erleben die Wirkung der kleinen Refactorings unmittelbar im Code. Nun folgt in der Conclude‑Phase die gemeinsame Reflexion und der persönliche Transfer, in unserer Session ist das in Form einer kurzen Abschluss‑E‑Mail.

Du leitest in dieser Phase die Reflexion ein.

"Zum Abschluss schreibt jede:r von euch am besten direkt nach der Session eine kurze E-Mail. Diese hilft euch, das Gelernte zu reflektieren und den Transfer in den Alltag leichter zu machen."

Die Mail besteht aus zwei Sätzen:

  1. Diese eine besondere / spezielle Sache habe ich heute neu gelernt: …
  2. Ich kann Folgendes direkt in meinen Refactorings einsetzen: …

Hier ein Link, den du direkt aufrufen lassen kannst: Learning Hour, 6 Core Refactorings – meine Erkenntnisse oder als Barcode zur Verfügung stellen kannst.

Je wie es zu eurem Team passt schreibt entweder:

  • an euch selbst zur eigenen Erinnerung oder Reflexion,
  • an die Kollegin oder den Kollegen links von euch (eventuell mit einer kurzen Antwort),
  • oder an euch als Moderator, wenn ihr ein direktes Feedbak möchtet.

Das Schreiben selbst sorgt aber dafür, dass die Erkenntnis bewusster bleibt. Solltet ihr noch zu viel Zeit haben, könnt ihr das Feedback auch direkt in der Gruppe teilen.

Quellen

  • Primär: Sammam Coaching
    Sammam Coaching von Emily Bache bietet euch viele Learning Hours und eine Sammlung von Katas. Perfekt zum Vertiefen.

Viel Spaß bei der Learning Hour!