Refactoring for Novices in Java: An Eye Tracking Study on the Extract vs. Inline Methods

Eine Eye-Tracking-Studie mit Java-Anfängern zeigt, dass die Extraktion von Methoden die Lesbarkeit und Leistung bei komplexen Aufgaben verbessert, bei einfachen Aufgaben jedoch durch erhöhten Navigationsaufwand und kognitive Last die Performance verschlechtert, was zu einer vorsichtigen Anwendung von Modularisierung im Anfängerunterricht raten lässt.

Das Wesentliche

Titel: Warum das „Zerlegen" von Code Anfänger manchmal verwirrt – Eine Studie mit Augen-Tracking

Stellen Sie sich vor, Sie lesen ein Kochrezept. Es gibt zwei Möglichkeiten, wie es geschrieben sein kann:

1. Variante A (Inline): Alles steht in einer langen Liste. „Nehmen Sie 2 Eier, schlagen Sie sie auf, geben Sie Mehl dazu, rühren Sie um, backen Sie bei 180 Grad..." – alles in einem Durchgang.
2. Variante B (Extract): Das Rezept ist in Abschnitte unterteilt. Zuerst steht dort: „Bereiten Sie den Teig vor." Dann, an einer anderen Stelle im Buch, finden Sie die Anleitung: „Teig vorbereiten: 2 Eier schlagen, Mehl hinzufügen..."

In der Welt der Programmierung nennen wir das Inline Method (alles in einem Block) und Extract Method (Teile in eine eigene Funktion auslagern). Die Experten sagen seit Jahren: „Variante B ist besser! Sie ist übersichtlicher, wiederverwendbar und professioneller."

Aber eine neue Studie aus Brasilien stellt diese Weisheit infrage – zumindest für Anfänger.

Das Experiment: Ein Blick in die Gedanken der Anfänger

Die Forscher wollten wissen: Wie verstehen Anfänger (Leute, die gerade erst Java lernen) diese beiden Varianten? Um das herauszufinden, ließen sie 32 Anfänger vor einem Computer sitzen, während eine spezielle Kamera ihre Augenbewegungen verfolgte.

Stellen Sie sich die Augen wie eine Taschenlampe vor. Wo die Lampe hinfällt, denkt das Gehirn gerade.

• Feste Blicke (Fixationen): Wo die Lampe kurz stehen bleibt, um etwas zu lesen.
• Rückwärts-Sprünge (Regressions): Wenn die Lampe schnell wieder nach oben springt, weil man etwas nicht verstanden hat und es noch einmal lesen muss.

Die Teilnehmer mussten einfache Aufgaben lösen, wie zum Beispiel: „Berechne die Fläche eines Quadrats" oder „Berechne die Fakultät einer Zahl" (eine etwas komplexere Rechnung). Für jede Aufgabe gab es zwei Versionen des Codes: eine, bei der alles in einem Stück stand, und eine, bei der Teile herausgeschnitten und in eine eigene Funktion verpackt wurden.

Die überraschenden Ergebnisse

Das Ergebnis war wie ein Zungenbrecher: Es kommt darauf an, wie kompliziert die Aufgabe ist.

1. Bei einfachen Aufgaben: „Zerlegen" ist hinderlich

Bei sehr einfachen Aufgaben (z. B. „Fläche eines Quadrats berechnen") war die Inline-Variante (Variante A) viel besser.

• Warum? Die Logik war so simpel, dass sie auf einen Blick verstanden wurde.
• Das Problem bei Variante B: Als die Forscher den Code in eine separate Funktion packten, mussten die Anfänger ständig hin- und herspringen. Sie schauten auf den Befehl „Fläche berechnen", sprangen dann zur Definition der Funktion, sprangen wieder zurück.
• Die Metapher: Stellen Sie sich vor, Sie müssen nur einen Brief öffnen. Wenn der Brief in einem Umschlag liegt, der in einem anderen Raum steht, müssen Sie erst zum anderen Raum gehen, den Brief holen, zurückkommen und ihn öffnen. Das kostet Zeit und Energie. Bei einer so simplen Aufgabe ist der „Umschlag" (die separate Funktion) nur unnötiger Aufwand.
• Ergebnis: Die Anfänger brauchten bis zu 167 % mehr Zeit und sprangen bis zu 200 % öfter zurück, wenn der Code „zerlegt" war.

2. Bei komplexeren Aufgaben: „Zerlegen" hilft

Bei etwas schwierigeren Aufgaben (z. B. „Fakultät berechnen" oder „Größte Note finden") war die Extract-Variante (Variante B) deutlich besser.

• Warum? Hier war der Code lang und verworren. Die separate Funktion wirkte wie ein Schild oder ein Hinweisschild. Der Name der Funktion (z. B. „Fakultät berechnen") sagte dem Anfänger sofort: „Hier passiert das Wichtigste, du musst nicht jede einzelne Zeile lesen."
• Die Metapher: Wenn Sie einen ganzen Koffer voller Kleidung sortieren müssen, hilft es, wenn Sie die Socken in einen Korb und die Hemden in einen anderen packen. Sie müssen nicht alles durcheinanderwühlen. Der Name des Korbes („Socken") gibt Ihnen Orientierung.
• Ergebnis: Die Anfänger waren bis zu 78 % schneller und sprangen viel weniger zurück. Sie konnten sich auf die Logik konzentrieren, anstatt sich in Details zu verlieren.

Das große Missverständnis: Was wir glauben vs. was wir tun

Ein besonders interessanter Punkt der Studie ist die Diskrepanz zwischen Gefühl und Realität.

• Die Umfrage: Als die Forscher die Anfänger befragten, sagten die meisten: „Ich mag die zerlegte Version (Variante B) viel lieber! Sie sieht ordentlicher aus und ist besser strukturiert."
• Die Realität: Während sie die Aufgaben lösten, zeigten ihre Augenbewegungen, dass sie bei einfachen Aufgaben mit der zerlegten Version viel mehr Stress hatten. Sie dachten, es sei einfacher, aber ihre Augen bewiesen, dass sie mehr Arbeit hatten.

Es ist, als würde jemand sagen: „Ich mag es, wenn mein Auto viele separate Knöpfe hat, weil es professioneller aussieht", aber beim Fahren merkt er, dass er ständig die Hände vom Lenkrad nehmen muss, um die Knöpfe zu drücken, und dadurch langsamer ist.

Was bedeutet das für uns?

Diese Studie ist wie ein Warnschild für Lehrer und Ausbilder:

1. Nicht zu früh modularisieren: Wenn man Anfängern beibringt, Code sofort in viele kleine Funktionen zu zerlegen, kann das bei einfachen Übungen verwirrend sein. Es zwingt sie, ständig hin- und herzuschauen, anstatt den Fluss zu verstehen.
2. Der Name ist nicht alles: Man glaubt oft, ein guter Name (wie „Fläche berechnen") reicht aus, um das Verständnis zu erleichtern. Aber für Anfänger reicht das oft nicht. Sie müssen trotzdem zur Funktion springen, um zu prüfen, ob der Name stimmt. Das kostet Zeit.
3. Kontext ist König: Es gibt keine „eine beste Lösung". Bei einfachen Dingen ist „alles an einem Ort" oft besser. Bei komplexen Dingen hilft die Aufteilung.

Fazit

Die Studie zeigt uns, dass das, was für erfahrene Entwickler „sauberer Code" ist, für Anfänger manchmal wie ein Labyrinth wirken kann. Die Augen der Anfänger verraten uns: Manchmal ist weniger Struktur (weniger Zerlegen) mehr, wenn die Aufgabe einfach ist. Und manchmal ist mehr Struktur (Zerlegen) der Schlüssel zum Verständnis, wenn die Aufgabe schwer ist.

Es ist eine Erinnerung daran, dass wir beim Unterrichten von Programmieren nicht nur auf den Code schauen sollten, sondern auch darauf, wie das menschliche Gehirn (und die Augen) damit umgeht.

Technische Zusammenfassung

Hier ist eine detaillierte technische Zusammenfassung des Papers „Refactoring for Novices in Java: An Eye Tracking Study on the Extract vs. Inline Methods" auf Deutsch:

1. Problemstellung

Software-Entwickler nutzen Refactoring-Techniken wie Extract Method (Herausziehen von Code in eine benannte Methode) und Inline Method (Einfügen des Methodenkörpers direkt an die Aufrufstelle), um Code lesbarer und wartbarer zu machen. Während frühere Studien auf Basis statischer Metriken (z. B. Code-Metriken) keine klaren Unterschiede zwischen diesen Praktiken fanden oder sogar negative Effekte auf „Code Smells" feststellten, bleibt der menschliche Faktor bei der Code-Verständlichkeit unterbeleuchtet.

Die zentrale Forschungsfrage lautet: Wie beeinflussen diese kleinen strukturellen Änderungen die kognitive Belastung und das visuelle Suchverhalten von Java-Anfängern? Die Autoren vermuten, dass statische Metriken dynamische Aspekte wie den visuellen Aufwand (z. B. das Hin-und-Her-Springen zwischen Aufruf und Definition) nicht erfassen können. Besonders relevant ist die Annahme, dass gut benannte Methoden als „Leuchtfeuer" (Beacons) dienen sollen, die das Verständnis erleichtern – eine Annahme, die bei Anfängern jedoch nicht immer zutrifft.

2. Methodik

Die Studie kombiniert ein kontrolliertes Experiment mit einer Umfrage und qualitativen Interviews, um ein umfassendes Bild zu erhalten.

• Teilnehmer:
  • Experiment: 32 Java-Anfänger (Studierende mit durchschnittlich 12 Monaten Java-Erfahrung).
  • Umfrage: 58 weitere Java-Anfänger (weniger als 10 Jahre Erfahrung).
• Aufgaben:
  • Acht einfache Programmieraufgaben (z. B. Fakultät berechnen, Fläche eines Quadrats, Primzahl prüfen), adaptiert aus Einführungskursen.
  • Jede Aufgabe wurde in zwei funktional äquivalenten Versionen präsentiert: einmal mit Inline Method und einmal mit Extract Method.
  • Verwendet wurde ein Latin Square Design, um Lerneffekte zu minimieren (jeder Teilnehmer sah nur eine Version pro Aufgabe).
• Datenerhebung (Eye Tracking):
  • Einsatz eines Tobii Eye Tracker 4C (90 Hz).
  • Gemessene Metriken:
    • Fixationsdauer: Zeit, die das Auge auf einem Punkt verweilt (kognitiver Aufwand).
    • Fixationsanzahl: Anzahl der Blickpunkte.
    • Regressionsanzahl: Anzahl der Rückwärtsbewegungen der Augen (Hin-und-Her-Springen zwischen Codezeilen), ein Indikator für Verständnisprobleme oder mangelnde Linearität.
    • Aufgabenzeit und Anzahl der Versuche bis zur korrekten Ausgabe.
  • Definition von Areas of Interest (AOI): Die Codezeilen, die durch das Refactoring direkt betroffen waren.
• Qualitative Analyse:
  • Semi-strukturierte Interviews mit den 32 Experiment-Teilnehmern (Grounded Theory).
  • Online-Umfrage zur Erfassung von Präferenzen und Motivationen der 58 zusätzlichen Teilnehmer.

3. Wichtige Beiträge

1. Erste Eye-Tracking-Studie zu Refactoring bei Anfängern: Dies ist die erste Arbeit, die Extract- und Inline-Method-Refactorings spezifisch bei Java-Anfängern mittels Eye-Tracking untersucht.
2. Multimodaler Ansatz: Kombination von objektiven Leistungsdaten (Zeit, Versuche), physiologischen Daten (Eye-Tracking) und subjektiven Feedbacks (Interviews, Umfrage).
3. Entdeckung des „Beacon-Effekt"-Versagens: Die Studie zeigt, dass gut benannte Methoden (Beacons) bei Anfängern nicht automatisch zu besserem Verständnis führen, sondern bei einfachen Aufgaben sogar kontraproduktiv sein können.
4. Kontextabhängigkeit: Nachweis, dass die Wirksamkeit eines Refactorings stark von der Komplexität der Aufgabe abhängt.

4. Ergebnisse

Die Ergebnisse zeigen ein nuanciertes, aufgabenabhängiges Bild, das oft den subjektiven Präferenzen der Teilnehmer widerspricht.

• Komplexe Aufgaben (z. B. Fakultät, höchste Note finden):

  • Extract Method war überlegen.
  • Die Aufgabenzeit sank um bis zu 78,8 %.
  • Die Anzahl der Regressionen (Rückwärtsbewegungen) sank um bis zu 84,6 %.
  • Die Fixationsdauer und -anzahl nahmen signifikant ab.
  • Interpretation: Die Modularisierung half, die kognitive Last zu reduzieren, da die Logik in überschaubare Blöcke unterteilt wurde. Die Teilnehmer nutzten den Methodennamen als Orientierungspunkt.

• Einfache Aufgaben (z. B. Fläche eines Quadrats, gerade/ungerade prüfen):

  • Inline Method war überlegen.
  • Die Aufgabenzeit stieg bei der Extract-Version um bis zu 166,9 %.
  • Die Anzahl der Regressionen stieg um bis zu 200 %.
  • Interpretation: Bei trivialer Logik führt das Herausziehen in eine separate Methode zu unnötigem visuellen Navigationsaufwand. Die Teilnehmer mussten ständig zwischen Aufruf und Methodendefinition hin- und herspringen, was den linearen Lesefluss unterbrach.

• Diskrepanz zwischen Wahrnehmung und Leistung:

  • In der Umfrage bevorzugten die meisten Anfänger die Extract-Version (76 % bei Summenbildung), motiviert durch bessere Lesbarkeit und Wiederverwendbarkeit.
  • Im Experiment zeigten Eye-Tracking-Daten jedoch, dass bei einfachen Aufgaben die Inline-Version effizienter war.
  • Anfänger scheinen die Vorteile der Modularisierung zu überbewerten, während sie den visuellen Navigationskosten (Context Switching) nicht ausreichend Rechnung tragen.

• Verhalten bei „Beacons":

  • Trotz aussagekräftiger Methodennamen (z. B. calculaFatorial) kehrten Anfänger oft zum Methodenkörper zurück, um die Logik zu überprüfen. Sie vertrauten dem Namen allein nicht und nutzten ihn nicht effektiv als semantisches Chunking-Tool, was zu erhöhtem visuellen Aufwand führte.

5. Bedeutung und Implikationen

• Für die Ausbildung (Lehre): Dozenten sollten vorsichtig sein mit einer vorzeitigen Modularisierung bei Anfängern. Das Einfügen von Methoden bei sehr einfachen Aufgaben (z. B. eine Zeile Code) kann das Verständnis erschweren und den Lernprozess verlangsamen. Die Wahl zwischen Inline und Extract sollte sich an der Komplexität der Logik orientieren.
• Für die Forschung: Die Studie unterstreicht den Wert von Eye-Tracking, um Effekte zu erkennen, die statische Metriken übersehen. Es zeigt, dass „Lesbarkeit" nicht immer mit „Effizienz des Verständnisses" gleichzusetzen ist.
• Theoretisches Modell: Die Autoren entwickeln ein integratives Modell, das zeigt, dass Code-Verständnis von der Interaktion zwischen Aufgabenkomplexität, Code-Repräsentation (Inline vs. Extract) und kognitiven Mechanismen (Aufmerksamkeit, Arbeitsgedächtnis) abhängt. Modularisierung ist nur dann vorteilhaft, wenn sie die kognitive Last tatsächlich reduziert; bei einfachen Aufgaben führt sie zu Overhead.

Fazit:
Das Paper widerlegt die pauschale Annahme, dass Extract Method immer besser für das Verständnis ist. Für Java-Anfänger gilt: Bei komplexer Logik hilft Modularisierung, bei trivialer Logik behindert sie durch unnötige Navigation. Die „Beacon"-Wirkung von Methodennamen ist bei Anfängern oft schwächer als erwartet und kann durch den Navigationsaufwand überkompensiert werden.