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

Een oogbewegingsstudie onder Java-novices toont aan dat het effect van het extraheren versus inline houden van methoden sterk afhangt van de taakcomplexiteit, waarbij extractie bij complexe taken de prestaties verbetert maar bij simpele taken juist leidt tot meer cognitieve belasting en langzamere uitvoering.

De kern

De Code-Kaas: Waarom "Oplossen" soms juist "Verwarren" is voor beginners

Stel je voor dat je een grote, rommelige keuken hebt. Je wilt een taart bakken, maar je ingrediënten liggen overal verspreid: bloem op de vloer, eieren in de kast, en suiker in de koelkast.

Er zijn twee manieren om dit op te lossen:

1. De "Inline" methode: Je pakt alles wat je nodig hebt en doet het direct in één grote kom. Alles gebeurt op één plek. Je hoeft niet te rennen.
2. De "Extract" methode: Je maakt een klein, apart bakje voor de suiker, een ander bakje voor de bloem, en noemt ze duidelijk: "Suikerbakje" en "Blokje". Je loopt dan heen en weer tussen je grote kom en deze bakjes om te kijken wat erin zit.

In de programmeerwereld noemen we dit Refactoring. Programmeurs maken code vaak netter door stukken code uit te knippen en in een aparte, duidelijk benoemde functie te stoppen (Extract Method). De gedachte is: "Dit maakt het overzichtelijker!"

Maar een nieuw onderzoek uit Brazilië vraagt zich af: Is dit echt makkelijker voor beginners?

Het Experiment: De Oogvolger

De onderzoekers deden iets heel slimme. Ze lieten 32 beginners (studenten die net Java leren) code lezen, maar ze keken niet alleen naar of ze het antwoord hadden. Ze keken naar hun ogen.

Ze gebruikten een speciale bril met camera's (eye-tracking) om te zien waar de ogen van de studenten naar keken, hoe lang ze stopten bij een woord, en hoe vaak ze terugkeken naar een vorige regel. Het is alsof je een spoor van hun gedachten ziet.

Wat vonden ze? Het verrassende resultaat

Het onderzoek toont aan dat "netter maken" niet altijd "makkelijker maken" betekent. Het hangt af van hoe complex de taak is.

1. De moeilijke taak: De "Factorial" (Vermenigvuldigen)

Stel je voor dat je een ingewikkeld recept moet volgen met veel stappen.

• Bij de "Inline" versie: De code was één lange, saaie lijst. De studenten moesten hun ogen over de hele lijst laten glijven en steeds terugkrabben om te zien wat er gebeurde. Het was als een lange, saaie wandeling zonder borden.
• Bij de "Extract" versie: De code was opgesplitst in een klein stukje met een duidelijke naam, zoals berekenFactorial.
• Het resultaat: De studenten keken minder vaak terug, waren sneller klaar en hadden minder "visuele stress". De naam fungeerde als een lichtbaken. Ze hoefden niet te lezen hoe het werkte, ze wisten al wat het deed.

2. De simpele taak: De "Oppervlakte van een Vierkant"

Stel je voor dat je alleen maar moet doen: breedte * lengte.

• Bij de "Inline" versie: Alles staat in één regel. Je kijkt er naar, en klaar. Het is als een kort stukje lopen.
• Bij de "Extract" versie: De onderzoekers maakten er een apart bakje van met de naam berekenOppervlakte.
• Het resultaat: Dit was een ramp voor de beginners!
  • De studenten moesten nu heen en weer springen: van de regel waar ze de opdracht gaven, naar het bakje om te zien wat erin zat, en weer terug.
  • Hun ogen maakten veel meer sprongetjes (regressies).
  • Ze deden er 166% langer over dan bij de simpele versie.
  • Het was alsof je voor een glas water moet rennen naar de keuken, terwijl het glas toch al op de tafel staat. De "netheid" creëerde onnodige afstand.

De Grote Leerlessen

1. De "Naam" is niet altijd een redder
In de programmeerwereld denken we: "Als ik het goed noem, begrijpen mensen het wel." Maar voor beginners werkt dat niet altijd. Als de taak heel simpel is, is de naam berekenOppervlakte niet nodig. De beginners kijken er niet naar als een hint, maar als een uitnodiging om te gaan zoeken. Ze vertrouwen de naam niet en kijken toch in het bakje.

2. Beginners houden van een rechte lijn
Beginners denken vaak lineair: "Dit, dan dat, dan dit." Als je code opsplitst in stukjes, forceer je hen om te springen. Voor complexe taken is dat goed (het helpt om te structureren), maar voor simpele taken is het als het versnipperen van een verhaal in losse zinnen die je over de hele kamer moet zoeken.

3. Wat ze zeggen vs. Wat ze doen
Interessant genoeg zeiden de studenten in een enquête: "Ik vind de opgesplitste versie mooier en logischer." Maar toen ze het moesten doen, waren ze met de opgesplitste versie juist trager en moeizamer. Ze voelden zich slimmer met de nette code, maar hun ogen en hersenen werkten harder.

Wat betekent dit voor ons?

Voor docenten en mensen die beginners leren programmeren is dit een belangrijke waarschuwing: Wees voorzichtig met het te vroeg "opknappen" van code.

• Als je een beginner een simpele som laat maken, laat het dan in één regel. Split het niet op in tien kleine, nette stukjes. Dat maakt het alleen maar lastiger.
• Gebruik de "opgesplitste" methode alleen als de taak echt complex is en de naam echt helpt om het hoofd niet te verliezen.

Kortom: Soms is een rommelige keuken sneller om een taart te bakken dan een keuken met honderd perfect gelabelde bakjes, vooral als je nog maar net begint met koken. Netheid is goed, maar niet als het ten koste gaat van de snelheid en het begrip van de beginner.

Technische samenvatting

Hier is een gedetailleerde technische samenvatting van het artikel "Refactoring for Novices in Java: An Eye Tracking Study on the Extract vs. Inline Methods" in het Nederlands.

Probleemstelling

Ontwikkelaars gebruiken veelvuldig refactorings zoals Extract Method (een codefragment uit een methode halen en in een nieuwe, benoemde methode plaatsen) en Inline Method (een methode-oproep vervangen door de inhoud ervan) om code leesbaarder, begrijpelijker en herbruikbaarder te maken. Hoewel eerdere studies met statische code-metrics (zoals cyclomatische complexiteit) geen duidelijke verschillen hebben gevonden tussen deze twee praktijken, blijft de menselijke factor in code-comprehensie onderbelicht.

De kernvraag is of deze structurele veranderingen daadwerkelijk de cognitieve last en het visuele inspanningsniveau van novice programmeurs (beginners) beïnvloeden. Bestaande theorieën suggereren dat goed benoemde methoden als "baken" (beacons) kunnen fungeren die het begrip vergemakkelijken. Echter, het is onduidelijk of beginners deze baken effectief gebruiken of dat de noodzaak om heen en weer te navigeren tussen een methode-aanroep en de methode-definitie juist extra cognitieve last veroorzaakt, vooral bij simpele taken.

Methodologie

De auteurs hebben een gecontroleerd experiment uitgevoerd met een mix van kwantitatieve en kwalitatieve methoden:

1. Deelnemers:
   • Experiment: 32 Java-novices (onderwijsstudenten met gemiddeld 12 maanden Java-ervaring).
   • Enquête: 58 aanvullende Java-novices voor kwalitatieve data over voorkeuren en motivaties.
2. Experimenteel Ontwerp:
   • Deelnemers losten 8 eenvoudige programmeertaken op (bijv. factorial berekenen, oppervlakte van een vierkant, controleren op even/oneven).
   • Voor elke taak werden twee functioneel equivalente versies gepresenteerd: één met Inline Method en één met Extract Method.
   • Een Latin Square design werd gebruikt om leer-effecten te minimaliseren; elke deelnemer zag elke taak slechts één keer, maar in een van de twee vormen.
3. Datacollectie (Eye Tracking):
   • Gebruik van een Tobii Eye Tracker 4C (90 Hz) om oogbewegingen te registreren.
   • Metrieken:
     • Tijdsduur: Totale tijd en tijd in de "Area of Interest" (AOI).
     • Aantal pogingen: Hoe vaak een deelnemer een antwoord probeerde voordat het correct was.
     • Visuele inspanning: Fixatieduur, aantal fixaties en het aantal regressies (oogbewegingen terug naar eerder gelezen code, wat wijst op herlezing of verwarring).
   • De AOI werd gedefinieerd als de code-regels waar de logica door het refactoring veranderde (de methode-definitie en de aanroep bij Extract; de directe regels bij Inline).
4. Kwalitatieve Analyse:
   • Semi-gestructureerde interviews na het experiment.
   • Een online enquête over voorkeuren.
   • Gebruik van Grounded Theory om de interviewdata te coderen en thema's te identificeren.

Belangrijkste Bijdragen

1. Eerste Eye-Tracking Studie: Dit is het eerste onderzoek dat Extract vs. Inline Method refactorings bij Java-novices analyseert met behulp van oogbewegingsdata.
2. Dynamisch Inzicht: Het toont aan dat statische metrics niet voldoende zijn om de impact van refactorings op de menselijke cognitie te meten. Visuele metrics onthullen patronen van verwarring en navigatie die anders onzichtbaar blijven.
3. Nuance in Modularisatie: Het onderzoek weerlegt het idee dat "extracten" altijd beter is. Het bewijst dat de effectiviteit sterk afhankelijk is van de complexiteit van de taak.
4. Integratief Model: De auteurs presenteren een theoretisch model dat taakkenmerken, code-representatie, cognitieve mechanismen en uitkomsten met elkaar verbindt, gemoduleerd door factoren zoals navigatiekosten en naamkwaliteit.

Resultaten

De resultaten tonen een complex en taak-afhankelijk beeld:

• Complexe Taken (Bijv. Factorial, Hoogste Cijfer):
  • Bij deze taken verbeterde Extract Method de prestaties aanzienlijk.
  • Resultaten: Tijd in de AOI daalde met tot 78,8%, en het aantal regressies daalde met 84,6%.
  • De naam van de methode fungeerde als een effectief baken, waardoor novices de logica in één keer konden begrijpen zonder constant terug te hoeven kijken.
• Simpele Taken (Bijv. Oppervlakte Vierkant, Controleren op Even):
  • Bij deze taken verslechterde Extract Method de prestaties.
  • Resultaten: Tijd in de AOI steeg met tot 166,9%, en regressies namen toe met 200%.
  • De extra stap om van de aanroep naar de definitie te springen (en terug) onderbrak de lineaire leesflow. De "baken" (de naam) werd niet effectief gebruikt; novices keken toch terug naar de code om te verifiëren wat er gebeurde.
• Perceptie vs. Realiteit:
  • Hoewel de meeste novices in de enquête aangaven dat ze de Extract Method prefereerden vanwege leesbaarheid en herbruikbaarheid, correspondeerde dit niet altijd met hun feitelijke prestatie.
  • Bij simpele taken vonden ze de inline-versie vaak sneller en directer, hoewel ze in theorie de "modulaire" versie als professioneler zagen.
• Cognitieve Patronen:
  • Bij inline-code lezen novices vaak lineair maar met veel terugblikken binnen de loop-structuren.
  • Bij extracted-code bij simpele taken ontstaat een "heen-en-weer" patroon tussen aanroep en definitie, wat de cognitieve last verhoogt.

Betekenis en Implicaties

• Voor Onderwijs: Docenten moeten voorzichtig zijn met het toepassen van "premature modularization" (te vroeg uitpakken in methoden) bij beginners. Voor zeer simpele logica kan het inlines houden van code de cognitieve last verlagen en het begrip versnellen.
• Voor Onderzoek: Het onderzoek benadrukt de waarde van eye tracking als een instrument om de effecten van refactorings te meten die statische code-metrics missen. Het toont aan dat "betekenisvolle namen" niet altijd werken als cognitieve hulpmiddelen voor beginners zonder voldoende ervaring.
• Voor Praktijk: De keuze tussen inline en extract moet context-afhankelijk zijn. Modularisatie is nuttig voor complexe logica, maar kan contraproductief zijn voor triviale berekeningen bij beginners.

Conclusie:
Hoewel Extract Method een fundamentele techniek is voor schaalbaarheid en onderhoud, is het niet altijd de beste keuze voor code-comprehensie bij beginners. De studie concludeert dat de "baken"-theorie (dat namen het begrip vergemakkelijken) bij novices faalt bij simpele taken omdat de navigatiekosten de voordelen van de naam overschaduwen. Een gebalanceerde aanpak, waarbij de complexiteit van de taak de mate van modularisatie bepaalt, is essentieel.