Ein Team übernimmt ein Abrechnungsmodul, das niemand so recht versteht. Es gibt keine Tests, die das bestehende Verhalten absichern. Ein Sprint soll das Modul „aufräumen“, und der Plan sieht vor, den Kern in einer neuen Struktur neu zu schreiben. Niemand kann garantieren, dass die neue Version den Kunden weiterhin korrekte Gebühren berechnet.
Dies ist ein beispielhaftes Szenario, kein dokumentierter Vorfall. Es verdeutlicht die Lücke, die ein Refactoring-Schulungsprojekt schließen muss: Entwickler, die zwar erkennen, dass der Code unübersichtlich ist, aber noch keine konkrete Verbesserung planen und nachweisen können, dass das Verhalten erhalten bleibt.
Dieser Leitfaden richtet sich an Verantwortliche für die technische Weiterbildung und an Führungskräfte im technischen Bereich. Er beschreibt, wie man Leistungsprobleme beschreibt, Lücken analysiert, Schulungen vorbereitet und durchführt, einen Fall bearbeitet und beurteilt, ob die erlernten Fähigkeiten auf die reale Arbeit übertragbar sind. Es geht um die Konzeption von Schulungen. Der Code, die Tests und die Regeln Ihres Programms sollten von erfahrenen Ingenieuren mit Ihrer eigenen Technologieumgebung validiert werden.
Was ist ein Refactoring-Schulungsprojekt?
Ein Refactoring-Schulungsprojekt ist eine strukturierte Arbeit an bestehendem Code, deren Ziel es ist, sowohl die Kompetenzen der Teilnehmenden zu erweitern als auch den Code zu verbessern. Die Teilnehmenden planen eine kleine, überschaubare Änderung, sichern das bestehende Verhalten durch Tests ab, optimieren das Design schrittweise und weisen nach, dass keine Fehler aufgetreten sind. Der Code wird dadurch besser, und – noch wichtiger – die Entwickler üben die Fähigkeit, mit realen technischen Schulden umzugehen.
Schnelle Fakten
| Frage | Kurze Antwort |
|---|---|
| Was ist die Aufgabe? | Planen und validieren Sie eine begrenzte Verbesserung des bestehenden Codes. |
| Welche Punktzahl erreichst du? | Risikoanalyse und Nachweis, dass das bestehende Verhalten beibehalten wurde. |
| Ist eine umfassende Überarbeitung ein gutes Schulungsprojekt? | Normalerweise nicht. Es verdeckt die geübte Fertigkeit und macht es schwierig, das erlernte Verhalten zu zeigen. |
| Reicht ein Quiz zu Refactoring-Mustern aus? | Nein. Es bestätigt zwar die Voraussetzungen, aber nicht, ob ein Ingenieur eine Änderung planen und validieren kann. |
| Wer prüft die Inhalte? | Ein Engineering Manager und ein Senior Engineer, der die Codebasis kennt. |
| Was kann Training nicht beheben? | Fehlende Testwerkzeuge, Freigabedruck, unklare Zuständigkeiten und keine Zeit für Wartungsarbeiten. |
| Woran erkennt man, dass es funktioniert hat? | Ein neuer, bisher unbekannter Legacy-Code-Fall, bewertet anhand vereinbarter Kriterien, mit anschließender Überprüfung der realen Arbeit. |
1. Beschreiben Sie das Leistungsproblem
Beginnen Sie mit der Aufgabe: Planen und validieren Sie eine begrenzte Verbesserung des bestehenden Codes. „Begrenzt“ ist hierbei das entscheidende Wort. Der Lernende wählt eine Änderung, die klein genug ist, um sie abzuschließen, und kann genau definieren, was zum Umfang der Verbesserung gehört und was nicht.
Es ist hilfreich, Begriffe präzise zu definieren. Martin Fowler beschreibt Refactoring als eine kontrollierte Technik zur Verbesserung des Designs einer bestehenden CodebasisSie besteht aus kleinen, verhaltenserhaltenden Transformationen. Der Begriff „verhaltenserhaltend“ unterscheidet Refactoring von einer kompletten Neuentwicklung und muss in Schulungen verdeutlicht werden. Die Metapher der technischen Schulden selbst wurde von Ward Cunningham geprägt.Fowlers Ausführungen erinnern uns daran, dass Schulden auch bewusst und umsichtig aufgenommen werden können, sodass nicht jedes unübersichtliche Modul ein Fehler ist, der behoben werden muss.
Michael Feathers' Buch über Legacy-Code verfolgt denselben Ansatz. Laut Verlagsbeschreibung lehrt es Entwickler, Tests zu schreiben, die sicherstellen, dass... Sie verändern die Anwendung nicht unbeabsichtigt.und die bestehende Software ohne vollständige Neuentwicklung unter Kontrolle zu bringen.
Formulieren Sie die Leistungsbeschreibung in einem Satz und lassen Sie sie von einem Entwicklungsleiter überprüfen: „Ausgehend von einem bestehenden Modul und einem definierten Ziel schlägt der Entwickler eine begrenzte Änderung vor, fügt Tests hinzu, die das aktuelle Verhalten genau bestimmen, führt die Änderung in kleinen Schritten durch und zeigt, dass das Verhalten erhalten bleibt.“
2. Lern- und Kontextlücken diagnostizieren
Bevor Sie etwas entwickeln, vergleichen Sie die geforderte Aufgabe mit dem, was Sie in Ihren aktuellen Tätigkeiten üben und bewerten. Drei Fragen helfen in der Regel dabei, eine Schulungslücke von anderen Problemen zu unterscheiden:
- Wird in der aktuellen Praxis die reale Aufgabe berücksichtigt? Wenn in Schulungen Refactoring-Muster in Folien behandelt werden, aber niemand jemals ungetesteten Code ändert, hat niemand das Schutzverhalten geübt. Wenn die Bewertung aus einem Multiple-Choice-Test zu Code-Smells besteht, misst sie lediglich das reine Erinnerungsvermögen.
- Welche kognitiven Anforderungen werden gestellt? In Blooms revidierter Taxonomie fällt die Beurteilung der Sicherheit einer Änderung auf die Analyse- und Bewertungsebene, während die Planung und die Durchführung der Tests der Erstellungsebene zugeordnet werden. Die Zuordnung von Aktivitäten zu diesen Ebenen wird in unserem Leitfaden erläutert. Zuordnung von Lernaktivitäten zu Blooms Taxonomie.
- Steht da etwas anderes als Können im Weg? Überprüfen Sie Personal, Werkzeuge und Arbeitsabläufe. Dauert der Build eine Stunde, wird niemand regelmäßig Tests durchführen. Werden Wartungsarbeiten nie eingeplant, reprogrammieren die Entwickler nur heimlich. Melden Sie Ursachen, die nicht auf Schulungsinhalte zurückzuführen sind, denjenigen, die sie beheben können.
3. Gezielte Vorbereitung und Übung gestalten
Sobald Sie wissen, welche Lücken durch Schulungen geschlossen werden können, weisen Sie jeder Phase eine klar definierte Aufgabe zu.
Vorbereitung. Prüfen Sie die Voraussetzungen mit einer kurzen Diagnose: Wie funktioniert Ihr Testframework? Was ist ein Charakterisierungstest? Wie prüft und integriert Ihr Team die Testergebnisse? Selbststudium eignet sich für diese Phase. Eine Wissensüberprüfung bestätigt lediglich das Vorliegen der Voraussetzungen.
Praxis. Nutzen Sie systematische Refactoring-Projekte mit klarer Struktur. Beginnen Sie mit einem kleinen, sicheren Beispiel und gehen Sie dann zu einem realen, aber abgegrenzten Teil Ihrer eigenen Codebasis über. Die Gilded Rose Kata ist ein bekannter Einstiegspunkt für den ersten Schritt. Die zugehörige README-Datei wird von Emily Bache gepflegt. empfiehlt, vor Codeänderungen Tests zu schreiben. Die Übung wird als Praxis des Vorgehens in kleinen Schritten, des häufigen Testens und der schrittweisen Verbesserung des Designs verstanden. Eine sinnvolle Vorgehensweise für jedes Projekt ist: Ziel und Rahmenbedingungen definieren, Tests schreiben, die das aktuelle Verhalten des Codes abbilden, jeweils nur eine Sache ändern, nach jedem Schritt die Tests ausführen und die gewonnenen Erkenntnisse dokumentieren.
Feedback bekommen. Verknüpfen Sie Feedback mit Entscheidungen, nicht mit einer Gesamtpunktzahl. „Sie haben die Rabattlogik extrahiert, aber Ihre Tests deckten nur den Normalfall ab, sodass Sie die Rundungsänderung nicht bemerkt haben konnten“ ist hilfreicher als „3 von 5“.
Live-Eingabe durch den Dozenten oder asynchrone Überprüfung? Live-Feedback ist besonders wertvoll bei unklaren Entscheidungen, beispielsweise ob man anhalten und einen fehlenden Test nachholen oder fortfahren soll. Asynchrones Feedback reicht aus, wenn Lernende ihren Plan und ihre Tests mit einer kommentierten Expertenversion vergleichen. Viele Teams nutzen beides: zunächst selbstständiges Vorbereiten, anschließend eine moderierte Sitzung zu den schwierigen Fällen.
4. Arbeiten Sie ein realistisches Beispiel durch.
Beispielhaft. Ein technischer Leiter sollte den Anwendungsfall und die Antwortkriterien vor der Verwendung prüfen.
Der Fall. Eine bestehende Funktion berechnet den Gesamtbetrag einer Bestellung inklusive Rabatt, Steuer und Versandregel. Sie ist nicht getestet. Ein Team schlägt vor, das gesamte Abrechnungsmodul zu überarbeiten, um es übersichtlicher zu gestalten.
Die Aufgabe. Der Lernende erklärt, was er tun würde, nennt die Beweise, die er sammeln würde, und sagt, welche weiteren Informationen oder Unterstützung er benötigt.
Ein erster Versuch. „Ich würde das Modul in drei Dienste aufteilen, die Logik übertragen und anschließend die Ergebnisse in der Testumgebung überprüfen.“ Der Lernende hat sich für eine umfangreiche Änderung und eine späte, manuelle Überprüfung entschieden. Es lässt sich nicht feststellen, ob die alte und die neue Version in Grenzfällen übereinstimmen.
Feedback geben und es erneut versuchen. Der Prüfer fragt, wie die Funktion sich aktuell bei einem leeren Warenkorb, einem Rabatt, der zu einem negativen Gesamtbetrag führt, und bei Rundungsfehlern verhält. Im Wiederholungsversuch wird der Lernende gebeten, den Anwendungsbereich auf ein einzelnes Verhalten einzugrenzen und zu erläutern, wie er beweisen würde, dass sich dieses Verhalten nicht geändert hat.
Ein stärkerer Versuch. „Ich würde die Modulstruktur vorerst unverändert lassen. Ich würde die aktuellen Ergebnisse der Bestellsummenfunktion für verschiedene Eingaben, einschließlich der Sonderfälle, als Tests erfassen. Anschließend würde ich die Rabattberechnung in eine separate Funktion auslagern, die Tests nach diesem Schritt erneut durchführen und dann aufhören. Ich würde mir vermerken, dass die Versandregel ein mir unbekanntes Verhalten aufweist und einen Kollegen um Rat fragen, bevor ich sie ändere.“ Diese Antwort grenzt die Änderung ein, schützt das bestehende Verhalten und benennt die Unbekannten.
Warum jede Antwort vertretbar oder unvollständig ist. Beurteilen Sie jeden Versuch anhand festgelegter Kriterien, nicht nach der Präferenz eines Gutachters. Der erste Versuch mag zwar eine sinnvolle langfristige Richtung vorgeben, ist aber als Plan unvollständig, da er keine Belege für ein nachhaltiges Verhalten enthält. Der ausgereiftere Versuch ist klein, überprüfbar und geht offen mit Unsicherheiten um.
5. Fähigkeiten einschätzen und Transfer planen
Der Nachweis der Kompetenz erfolgt durch die Bearbeitung eines neuen, dem Lernenden unbekannten Legacy-Code-Falls. Bewertet werden die Risikoanalyse und der Nachweis, dass das Verhalten beibehalten wurde. Eine einfache Bewertungsmatrix verwendet eine Skala von 0 bis 2 pro Kriterium.
| Kriterium | Sichtbare Beweise |
|---|---|
| Aufgabenausführung | Plant und validiert eine begrenzte Verbesserung des bestehenden Codes und dokumentiert die durchgeführten Maßnahmen sowie die zugrunde liegenden Beweise. |
| Argumentation | Erläutert die Einschränkungen, Alternativen und Unsicherheiten und prüft die Risiken sowie die Nachweise dafür, dass das Verhalten beibehalten wurde. |
| Boundaries | Wendet genehmigte Verfahren an und bittet um Hilfe, wenn Informationen oder Befugnisse nicht ausreichen. |
Bewertungsskala: 0 bedeutet fehlend oder nicht belegt, 1 bedeutet teilweise mit relevanten Auslassungen und 2 bedeutet vollständig und anhand vereinbarter Kriterien begründet. Kritische Fehler, wie z. B. Verhaltensänderungen ohne erkennbaren Test, müssen separat definiert werden, damit sie nicht in der Gesamtbewertung verborgen bleiben. Diese Bewertungsmatrix ist ein Vorschlag, kein validierter Bereitschaftsstandard: Passen Sie sie gemeinsam mit einem Entwicklungsleiter an und erproben Sie sie. Unser Leitfaden dazu Gestaltung interaktiver Übungen mit hilfreichem Feedback zeigt, wie man Feedback verfasst, das mit Entscheidungen verknüpft ist.
Planen Sie den Transfer gezielt. Geben Sie jedem Ingenieur nach der Übung eine kleine, konkrete Aufgabe, die er mit einem Reviewer besprechen soll, oder führen Sie eine kurze Retrospektive zu einer kürzlich vorgenommenen Änderung durch, die zu einem Fehler geführt hat. Überprüfen Sie den Transfer erst nach ausreichender Einarbeitungszeit in die reale Arbeit, nicht direkt nach dem Workshop.
Wo interaktive Bereitstellung hilft
Interaktive Formate sind hilfreich, wenn sich alle Beteiligten vor der Präsentation in der Gruppe festlegen sollten. In einer Live-Sitzung kann ein Moderator einen kurzen Codeausschnitt aus einer älteren Anwendung zeigen, jeden Entwickler bitten, die erste Änderung, die er vornehmen würde, und deren Sicherheit nachzuweisen, und anschließend die Ergebnisse vor der Diskussion präsentieren. Dieselbe Aufgabe kann zur Vorbereitung auch im Selbststudium bearbeitet werden. AhaSlides unterstützt interaktives Lernen und den Wechsel zwischen Live- und Selbststudium. Es handelt sich um ein Präsentations- und Lernwerkzeug, nicht um eine Plattform zum Ausführen oder Analysieren von Code. Führen Sie daher das Refactoring selbst in Ihrer eigenen Umgebung durch. Überprüfen Sie alle Funktionen zur Erstellung, zum Feedback oder zur Berichterstellung, die Sie verwenden möchten, anhand Ihres eigenen Workflows. Hinweise zur Auswahl von Formaten finden Sie in unserem Artikel zu diesem Thema. Wann sollte man adaptives, interaktives und Live-Lernen einsetzen?.
Messen Sie, was sich verändert hat
Legen Sie im Vorfeld fest, woran Sie erkennen, dass die Ingenieure die Aufgabe bewältigen können. Vergleichen Sie die Qualität der Risikoanalyse und die Nachweise für ein korrektes Verhalten in einem nicht simulierten Fall mit einer Referenzgruppe. Definieren Sie die Einschlusskriterien, den Nenner und den Zeitraum. Verbessern sich die Ergebnisse, prüfen Sie, welche anderen Veränderungen sich im selben Zeitraum ergeben haben, z. B. neue Testwerkzeuge, eine schnellere Produktion oder ein Eigentümerwechsel, bevor Sie die Schulung anrechnen.
Einschränkungen, die möglicherweise bestehen bleiben
- Zeit für Wartungsarbeiten. Wenn keine Schuldenarbeiten anfallen, haben ausgebildete Ingenieure trotzdem keine Möglichkeit, ihre Fähigkeiten einzusetzen.
- Testwerkzeuge. Ohne einen brauchbaren Testaufbau oder eine schnelle Konstruktion sind kleine Schritte und häufige Kontrollen schwer durchzuhalten.
- Fallabdeckung. Ein historischer Fall verdeutlicht verschiedene Risikoarten. Eine Punktzahl beschreibt im Allgemeinen nicht das Urteilsvermögen eines Ingenieurs.
- Die Beurteilung, wann man nicht refaktorisieren sollte. Manche Codeabschnitte sollten besser unverändert bleiben, ersetzt oder außer Betrieb genommen werden, und diese Entscheidung erfordert mehr als nur Fachkenntnisse.
- Übertragung. Die Leistung in einer Kata ist nicht dasselbe wie die Leistung in einem Produktionsmodul unter Lieferdruck.
Weisen Sie die Sponsoren frühzeitig auf diese Punkte hin und planen Sie separate Lösungen. Schulungen verbessern die Planungs- und Nachweisfähigkeiten von Ingenieuren. Sie schaffen jedoch weder die Zeit noch die Werkzeuge.
Häufig gestellte Fragen
Was ist ein Refactoring-Schulungsprojekt?
Es handelt sich um eine strukturierte Vorgehensweise bei bestehendem Code, bei der die Ingenieure eine kleine Änderung planen, das bestehende Verhalten mit Tests absichern, das Design in kleinen Schritten ändern und zeigen, dass nichts kaputt gegangen ist.
Ist eine vollständige Neuentwicklung eine gute Methode, um etwas über technische Schulden zu lernen?
In der Regel nicht. Eine komplette Neuentwicklung ist umfangreich, schwer zu validieren und verdeckt die Kompetenz, die Sie eigentlich aufbauen möchten. Eine gezielte Änderung mit Tests, die das aktuelle Verhalten abbilden, macht die Gründe dafür nachvollziehbar.
Wie lässt sich beurteilen, ob Ingenieure sicher refaktorisieren können?
Geben Sie einen neuen Legacy-Code-Fall an und bewerten Sie die Risikoanalyse sowie die Nachweise für die Beibehaltung des Verhaltens anhand vereinbarter Kriterien. Ein Quiz zu Refactoring-Mustern dient lediglich der Bestätigung der Voraussetzungen.
Benötigen Sie eine Beispielcodebasis für die Schulung?
Sie benötigen einen sicheren Übungsbereich. Viele Teams beginnen mit einer öffentlichen Kata und gehen dann zu einem abgegrenzten Teil ihres eigenen Codes über. Ihr Entwicklungsleiter sollte bestätigen, dass der Code geeignet ist.
Wo soll ich anfangen
Wählen Sie eine kleine, wiederkehrende Legacy-Änderung in Ihrer Codebasis. Verfassen Sie eine Performance-Analyse, lassen Sie einen Entwicklungsleiter den Anwendungsfall und die Tests, die das erhaltene Verhalten nachweisen, validieren und erstellen Sie eine Bewertungsmatrix mit drei Kriterien (0 bis 2) und einer Liste kritischer Fehler. Testen Sie die Änderung zunächst mit einer kleinen Gruppe, bevor Sie sie flächendeckend einführen.
Um zu sehen, wie eine Refactoring-Entscheidungsübung live mit Ihrem eigenen Team durchgeführt und anschließend im eigenen Tempo wiederverwendet werden kann, erkunden Sie AhaSlides.
