Refactoring: Code sicher verbessern

Beim Refactoring veränderst du den inneren Aufbau eines bestehenden Programms. Sein beobachtbares Verhalten soll dabei gleich bleiben: Unter denselben Voraussetzungen und mit derselben Eingabe liefert es weiterhin dieselben Ergebnisse und Wirkungen. Eine Eingabe sind die Daten, die das Programm erhält. Beobachtbar sind zum Beispiel angezeigte Texte, zurückgegebene Ergebnisse und Änderungen an gespeicherten Daten.

Auch Fehlermeldungen gehören zum beobachtbaren Verhalten. Gibt ein Programm nach dem Umbau bei leerer Eingabe eine zusätzliche Fehlermeldung aus, hat sich dieses Verhalten verändert. Eine neue Funktion oder eine Fehlerkorrektur kann sinnvoll sein. Sobald sie das beobachtbare Verhalten verändert, ist diese Änderung jedoch kein Refactoring.

Eine Variable ist ein Name für einen gespeicherten Wert. Du kannst einen rein internen Variablennamen ändern und alle seine Verwendungen passend ersetzen. Bleiben dadurch Ergebnisse und Wirkungen gleich, ist das ein Beispiel für Refactoring. Eine sichtbare Meldung um einen Begrüßungssatz zu erweitern, verändert dagegen die Ausgabe.

Die erfundenen Modelle dieser Lektion haben außer den ausdrücklich genannten Ausgaben und Ergebnissen keine weiteren Wirkungen. Wir untersuchen an ihnen keine Ausführungszeiten.

Ein Code-Smell ist ein auffälliges Merkmal im Code, das auf ein tieferes Problem hinweisen kann. Der englische Ausdruck bedeutet sinngemäß „verdächtiger Geruch im Code“. Er ist ein Anlass zum Prüfen, kein Beweis für einen Fehler.

Eine Funktion ist eine benannte Teilaufgabe eines Programms. Sie kann Eingaben erhalten und ein Ergebnis zurückgeben. Eine Methode ist eine solche Teilaufgabe innerhalb einer Klasse. Eine Klasse fasst hier zusammengehörige Methoden unter einem Namen zusammen.

Bei Code-Duplizierung erledigen mehrere Codeabschnitte dieselbe Arbeit. Die Abschnitte können fast gleich aussehen oder trotz unterschiedlicher Schreibweise dieselbe Aufgabe erfüllen. Steht derselbe benötigte Ablauf in mehreren Methoden derselben Klasse, kannst du ihn in eine neue Methode auslagern. An jeder bisherigen Stelle ersetzt ein Aufruf den ausgelagerten Ablauf. Ein Aufruf bedeutet: Das Programm führt die benannte Teilaufgabe aus. Die benötigten Ausführungen und ihre Reihenfolge bleiben erhalten. Den alten Ablauf stehen zu lassen und zusätzlich aufzurufen, würde die Arbeit doppelt ausführen.

Eine lange Methode kann mehrere schwer überschaubare Teilaufgaben enthalten. Prüfe, ob du zusammengehörige Anweisungen sinnvoll in eigene Methoden auslagern kannst. Teile nach Aufgaben auf, nicht nach einer festen Zeilenzahl. Benötigte Arbeit darf beim Verkürzen nicht entfallen.

Eine lange Methode kann auch gut verständlich sein. Ebenso kann das Zusammenführen ähnlicher Abschnitte die Verständlichkeit verschlechtern, wenn ihre Aufgaben eigentlich verschieden sind. Entscheidend ist deshalb die Prüfung des konkreten Falls.

Lege zuerst fest, welche Eingaben erlaubt sind und welche Ergebnisse du erwartest. Prüfe diese Erwartungen am bestehenden Programm. Weicht es schon vorher davon ab, klärst du die Abweichung, bevor du den Umbau bewertest.

Wähle dann eine kleine, zusammengehörige Änderung. Du kannst zum Beispiel eine Teilaufgabe auslagern und an ihrer bisherigen Stelle aufrufen. Prüfe anschließend erneut die erwarteten Ergebnisse. Bei einer Abweichung hältst du an: Untersuche und korrigiere die letzte Änderung oder nimm sie zurück. Passe die Erwartung nicht bloß an die neue Ausgabe an. Erst nach der Prüfung folgt der nächste kleine Schritt. Kleine Schritte erleichtern es, die Ursache einer Abweichung einzugrenzen; sie garantieren keine Fehlerfreiheit.

Das folgende Beispiel ist Pseudocode: eine vereinfachte Beschreibung eines Ablaufs, kein direkt ausführbares Programm einer bestimmten Sprache. FUNKTION beginnt eine benannte Teilaufgabe. In den Klammern steht ihr Eingabename. Ein Doppelpunkt und eingerückte Zeilen zeigen, welche Anweisungen dazugehören. Ein Name mit Klammern innerhalb einer Anweisung ruft die entsprechende Funktion auf.

Das Zeichen ← weist einer Variablen einen Wert zu. Texte stehen in deutschen Anführungszeichen. Das Zeichen + verbindet hier Texte in ihrer Reihenfolge. RÜCKGABE liefert ein Ergebnis an die aufrufende Stelle; AUSGABE zeigt einen Text an. Ein zurückgegebener Text wird also nicht schon dadurch angezeigt. Leerer Text enthält kein Zeichen und fügt beim Verbinden nichts hinzu.

Im Beispiel ist jeder Text als Eingabe erlaubt, auch leerer Text. Jeder Probelauf beginnt mit dem Aufruf von zeigeHinweis. Die aufgeführten Funktionen bilden den vollständigen Ablauf dieses Modells. Vorher und nachher soll genau ein Text ausgegeben werden.

Ein Test führt das Programm mit einer gewählten Eingabe aus und vergleicht das tatsächliche mit dem erwarteten Ergebnis. Stimmen beide überein, passt das beobachtete Ergebnis für diesen Probelauf. Tests vor und nach einer Umstrukturierung können zeigen, dass sich geprüfte Ergebnisse verändert haben. So helfen sie, Fehler früh zu entdecken.

Ein bestandener Test untersucht die tatsächlich ausgeführten Fälle. Für ungeprüfte Eingaben liefert sein Erfolg keine Garantie. Auch eine falsche Erwartung im Test kann einen Fehler verdecken. Die Zahl bestandener Tests allein macht ein Programm deshalb nicht sicher.

Wähle Tests passend zur Aufgabe: typische Eingaben und erlaubte Randfälle. Ein Randfall liegt an einer Grenze des erlaubten Eingabebereichs, etwa bei der kleinsten oder größten erlaubten Textlänge. Prüfe leeren Text, wenn er erlaubt ist. Eine Abweichung bei einem solchen Fall kann unentdeckt bleiben, wenn du ihn nicht ausführst.

Tests vergleichen Verhalten mit Erwartungen. Sie messen nicht, wie verständlich Methodennamen oder der Aufbau des Codes sind. Dafür musst du den Code zusätzlich lesen und beurteilen. Auch nach erfolgreichen Tests bleibt eine Restunsicherheit.