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

Cette étude utilisant le suivi oculaire auprès de novices en Java révèle que le choix entre l'extraction et l'inlining de méthodes dépend de la difficulté de la tâche, l'extraction améliorant les performances pour les tâches complexes mais les dégradant pour les tâches simples en augmentant la charge cognitive et les allers-retours visuels.

L'essentiel

Voici une explication simple de cette étude scientifique, imaginée comme une histoire sur la façon dont notre cerveau lit le code.

🧠 L'histoire : Le mystère du "Code Propre"

Imaginez que vous apprenez à cuisiner. Vous avez deux façons de préparer un plat :

1. La méthode "Tout-en-un" (Inline) : Vous prenez tous les ingrédients, vous les mélangez directement dans la casserole, et vous mangez. C'est rapide, tout est sous vos yeux.
2. La méthode "Recette séparée" (Extract) : Vous écrivez une petite recette sur un bout de papier pour une étape précise (par exemple, "préparer la sauce"), vous la posez sur le côté, et vous lisez cette recette quand vous en avez besoin.

Les experts en cuisine (les développeurs confirmés) adorent la méthode 2. Ils disent : "C'est plus propre, plus réutilisable, et plus facile à comprendre !" C'est comme ranger ses outils dans des boîtes étiquetées.

Mais cette étude se pose une question fascinante : Est-ce que ça marche aussi bien pour les débutants ?

Les chercheurs ont décidé de tester cela avec 32 étudiants débutants en Java (le langage de programmation). Mais au lieu de juste demander "C'est facile ?", ils ont utilisé une technologie de pointe : un suivi des yeux (eye-tracking). C'est comme si on mettait des caméras sur les yeux des étudiants pour voir exactement où ils regardent, à quelle vitesse, et combien de fois ils reviennent en arrière.

🔍 Ce qu'ils ont découvert (Les surprises)

L'étude a révélé que la réponse n'est pas "oui" ou "non", mais "ça dépend de la difficulté de la tâche".

1. Pour les tâches complexes : La recette séparée est une aide 🏰

Imaginons qu'il faut calculer une factorielle (un calcul mathématique un peu compliqué avec des boucles).

• Ce qui se passe : Avec la méthode "Tout-en-un", le débutant doit lire une longue suite d'instructions. Son cerveau s'embrouille. Ses yeux font des allers-retours constants (comme un ping-pong) pour essayer de comprendre la logique. C'est fatiguant !
• Le résultat : Quand les chercheurs ont séparé le calcul dans une petite fonction nommée "CalculerFactorielle", les yeux des étudiants se sont calmés. Ils ont pu lire le nom de la fonction, comprendre l'idée générale, et aller plus vite.
• Analogie : C'est comme lire un roman. Si un chapitre est trop long et dense, il est difficile de suivre. Si l'auteur met un résumé en haut de page ("Ici, le héros combat le dragon"), votre cerveau se repose et avance plus vite.

2. Pour les tâches simples : La recette séparée est un obstacle 🚧

Maintenant, imaginons une tâche très simple : calculer l'aire d'un carré (juste côté x côté).

• Ce qui se passe : Avec la méthode "Tout-en-un", c'est une ligne de code. C'est immédiat. Mais avec la méthode "Recette séparée", le débutant doit lire la ligne principale, puis sauter vers le haut de l'écran pour lire la recette, puis revenir en bas pour voir le résultat.
• Le résultat : Les yeux des étudiants ont fait des allers-retours inutiles. Le temps de lecture a explosé (parfois jusqu'à 166% plus long !).
• Analogie : C'est comme si vous vouliez juste allumer la lumière de votre chambre. Au lieu d'appuyer sur l'interrupteur à côté de vous, on vous oblige à ouvrir une porte, aller dans le couloir, appuyer sur un interrupteur, revenir, et ensuite allumer la lumière. C'est de la "navigation inutile". Le cerveau du débutant se dit : "Pourquoi je fais tout ce chemin pour quelque chose d'évident ?"

🧐 Le paradoxe des débutants

Le plus intéressant dans cette étude, c'est le décalage entre ce que les débutants pensent et ce qu'ils font.

• Ce qu'ils disent : "J'aime mieux la méthode séparée ! Ça a l'air plus organisé, plus pro, et le nom de la fonction m'aide."
• Ce que leurs yeux disent : "Attends, je suis en train de faire des allers-retours inutiles et je mets plus de temps à comprendre !"

Les débutants sont attirés par les "noms magiques" (les étiquettes sur les boîtes), mais ils n'ont pas encore assez d'expérience pour utiliser ces étiquettes efficacement. Ils doivent encore vérifier ce qu'il y a à l'intérieur de la boîte, ce qui annule l'avantage de l'étiquette.

💡 La leçon pour les professeurs et les étudiants

Cette étude est une alerte pour les enseignants de programmation :

1. Ne pas sur-organiser trop tôt : Pour les tout-petits exercices (comme calculer une aire ou vérifier si un nombre est pair), il vaut mieux laisser le code "tout en un". Ajouter une fonction séparée crée une friction inutile.
2. La complexité est la clé : La séparation du code (l'extraction de méthode) est un super-pouvoir, mais seulement quand la tâche est assez complexe pour justifier le voyage vers la "recette".
3. Les yeux ne mentent pas : On ne peut pas se fier uniquement à ce que les gens disent. Parfois, ils pensent qu'une chose est meilleure, alors que leurs yeux révèlent qu'ils souffrent en silence.

En résumé

Pensez au code comme à un voyage.

• Si le voyage est court (tâche simple), prendre un taxi qui vous fait faire un détour pour passer par une station-service (la fonction séparée) est une perte de temps.
• Si le voyage est long et compliqué (tâche complexe), avoir une carte détaillée (la fonction nommée) vous évite de vous perdre et vous fait gagner du temps.

Les chercheurs nous disent : "Ne copiez pas les experts aveuglément. Adaptez la structure du code à la difficulté de la tâche, surtout quand on apprend."

Résumé technique

Voici un résumé technique détaillé de l'article de recherche intitulé "Refactoring for Novices in Java: An Eye Tracking Study on the Extract vs. Inline Methods".

1. Problématique

Le réfactoring (restructuration de code) est une pratique courante en génie logiciel, notamment les techniques Extract Method (extraction d'une méthode) et Inline Method (inlining d'une méthode). Bien que des études antérieures utilisant des métriques statiques (comme les "code smells") n'aient pas trouvé de différences claires entre ces pratiques, la compréhension humaine du code reste sous-exploitée.

L'hypothèse centrale est que l'extraction de méthodes, souvent guidée par des noms significatifs agissant comme des "balises" (beacons) sémantiques, pourrait ne pas toujours faciliter la compréhension, en particulier pour les débutants (novices). Pour les tâches simples, l'ajout d'une indirection (appel de méthode) pourrait augmenter l'effort visuel et cognitif en forçant le développeur à naviguer entre l'appel et la définition, perturbant ainsi le raisonnement linéaire.

2. Méthodologie

L'étude adopte une approche mixte combinant une expérience contrôlée, des entretiens qualitatifs et une enquête en ligne, en utilisant le suivi oculaire (eye tracking) comme mesure dynamique principale.

• Participants :
  • 32 novices en Java (étudiants universitaires) pour l'expérience contrôlée.
  • 58 novices supplémentaires pour une enquête en ligne sur les préférences.
• Tâches :
  • 8 tâches de programmation simples (ex: calculer une factorielle, calculer l'aire d'un carré, vérifier si un nombre est pair).
  • Chaque tâche était présentée sous deux versions fonctionnellement équivalentes : Inline (logique dans main) et Extract (logique dans une méthode nommée).
• Mesures (Métriques) :
  • Performance : Temps de complétion, nombre de tentatives pour obtenir le bon résultat.
  • Effort Visuel (Eye Tracking) : Durée des fixations, nombre de fixations, et surtout le nombre de régressions (mouvements oculaires en arrière, indiquant une relecture ou une confusion).
  • Qualitatif : Entretiens semi-structurés et enquête sur les préférences et motivations.
• Analyse : Utilisation de tests statistiques (t-test, Mann-Whitney) et de la théorie ancrée (grounded theory) pour les données qualitatives.

3. Contributions Principales

• Première étude utilisant l'eye tracking pour comparer spécifiquement les refactorings Extract Method et Inline Method auprès de novices en Java.
• Démonstration de la limite des métriques statiques : L'étude montre que les métriques traditionnelles ne capturent pas l'effort cognitif et visuel réel induit par de petites transformations structurelles.
• Validation empirique du rôle des "balises" (beacons) : L'étude remet en question l'idée reçue que des noms de méthodes significatifs facilitent toujours la compréhension pour les débutants.
• Modèle théorique intégratif : Proposition d'un modèle reliant les caractéristiques de la tâche, la représentation du code, les mécanismes cognitifs et les résultats de compréhension, modérés par le coût de navigation et la qualité des noms.

4. Résultats Clés

Les résultats révèlent une hétérogénéité significative selon la complexité de la tâche :

• Tâches Complexes (ex: Factorielle, Plus grand élément d'une liste) :

  • L'extraction de méthode (Extract) a amélioré la compréhension.
  • Réductions observées : Temps réduit jusqu'à 78,8 %, régressions réduites jusqu'à 84,6 %.
  • Les novices ont bénéficié de la décomposition logique et des noms de méthodes pour structurer leur raisonnement.

• Tâches Simples (ex: Aire d'un carré, Vérifier si pair) :

  • L'extraction de méthode a nui à la performance.
  • Augmentations observées : Temps augmenté jusqu'à 166,9 %, régressions augmentées jusqu'à 200 %.
  • Pour ces tâches triviales, l'indirection imposée par l'appel de méthode a forcé les novices à faire des allers-retours visuels inutiles, perturbant leur flux de lecture linéaire.

• Perception vs Réalité :

  • Les novices préfèrent majoritairement la version extraite (jugée plus lisible et réutilisable) dans les enquêtes.
  • Cependant, cette préférence ne correspond pas toujours à leur performance réelle. Pour les tâches simples, ils passent plus de temps et font plus d'erreurs avec la version extraite, malgré leur perception positive.

• Comportement de lecture :

  • Les débutants ne semblent pas utiliser efficacement les noms de méthodes comme des balises sémantiques pour éviter de lire le corps de la méthode. Ils vérifient souvent le code de la méthode même lorsque le nom est explicite, augmentant l'effort cognitif.

5. Signification et Implications

• Pour l'Éducation : Les enseignants devraient être prudents avec la modularisation prématurée. Pour les débutants, imposer l'extraction de méthodes pour des opérations triviales peut ralentir l'apprentissage et la résolution de problèmes. Il est recommandé d'adapter le niveau de modularisation à la complexité de la tâche.
• Pour la Recherche : L'eye tracking est un outil essentiel pour révéler des effets cognitifs que les métriques statiques (comme la complexité cyclomatique) ne détectent pas.
• Pour la Pratique : Le réfactoring n'est pas une solution universelle. L'application de l'Extract Method doit être contextuelle : bénéfique pour la complexité, mais potentiellement contre-productive pour la simplicité excessive chez les novices.

En conclusion, cette étude démontre que la "lisibilité" est subjective et dépend de l'expérience du développeur et de la complexité de la tâche. Une bonne pratique pour un expert (modularisation) peut être un obstacle cognitif pour un novice dans un contexte spécifique.