MORCoRA: Multi-Objective Refactoring Recommendation Considering Review Availability

L'article présente MORCoRA, une technique de recherche multi-objectif qui recommande des séquences de refactorisation améliorant la qualité du code tout en identifiant des réviseurs experts et disponibles pour garantir une revue rapide et efficace.

L'essentiel

Imaginez que vous êtes le chef d'une grande cuisine (un projet de logiciel). Vos chefs cuisiniers (les développeurs) ont une idée géniale pour réorganiser les placards, changer l'ordre des ingrédients et rendre la cuisine plus efficace. C'est ce qu'on appelle le refactoring (restructuration du code).

Le problème ? Parfois, ces idées sont si complexes qu'elles risquent de faire tomber des casseroles ou de gâcher le plat si elles ne sont pas bien vérifiées. De plus, vos chefs sont déjà débordés : ils préparent déjà des commandes urgentes. Si vous leur demandez de vérifier votre nouvelle idée alors qu'ils sont au bord de l'épuisement, ils vont probablement dire : « Je verrai ça plus tard... » et l'oublieront. Résultat : la cuisine devient de plus en plus désordonnée.

C'est là qu'intervient MORCoRA, le nouveau super-héros de cette histoire.

1. Le Problème : La Cuisine en Chaos

Dans le monde du logiciel, on utilise souvent des robots intelligents (des algorithmes) pour trouver les meilleures façons de réorganiser le code. Mais ces robots sont un peu comme des architectes fous : ils proposent des changements qui rendent le code magnifique sur le papier, mais ils oublient une chose cruciale : qui va vérifier le travail ?

Si le robot propose une modification, il doit trouver un chef cuisinier qui :

1. Connaît bien les placards (expertise technique).
2. A le temps de vérifier (pas trop occupé par d'autres commandes).

Si le robot ne vérifie pas ces deux points, il risque de proposer des changements que personne ne pourra jamais valider. Le projet reste bloqué, et la qualité du logiciel se dégrade.

2. La Solution : MORCoRA, le Chef d'Orchestre Intelligents

Les auteurs de l'article (Lei Chen et Shinpei Hayashi) ont créé MORCoRA. C'est un outil qui ne cherche pas seulement la perfection technique, mais qui cherche aussi la réalité humaine.

Imaginez MORCoRA comme un chef d'orchestre très attentionné qui a trois objectifs simultanés :

• Objectif 1 : La Beauté du Code. Il veut que la musique (le code) soit plus harmonieuse et facile à jouer.
• Objectif 2 : La Cohérence. Il veut s'assurer que le changement ne brise pas la mélodie existante (on ne change pas les notes d'un instrument sans que cela sonne faux).
• Objectif 3 : La Disponibilité (Le secret !). C'est la grande nouveauté. Avant même de proposer la partition, MORCoRA regarde l'agenda de chaque musicien. Il se demande : « Qui a les compétences pour jouer cette partie ? Et qui a le temps de la lire maintenant ? »

3. Comment ça marche ? (L'Analogie du Restaurant)

Prenons l'exemple du projet Mockito mentionné dans l'article.

• Sans MORCoRA : Le robot propose de changer le nom d'une fonction. Il trouve un expert, mais cet expert est en train de gérer 7 autres urgences. Il repousse la vérification indéfiniment. Le changement n'est jamais fait.
• Avec MORCoRA : Le robot dit : « Attends, cet expert est trop occupé. Regardons plutôt l'autre chef, qui a aussi les compétences et qui a un moment de libre. » Il propose donc le changement avec le bon chef désigné pour le vérifier.

MORCoRA utilise une technique mathématique avancée (appelée NSGA-II) qui fonctionne comme un jeu de sélection naturelle. Il teste des milliers de combinaisons de changements et de chefs disponibles, et ne garde que les meilleures équipes : celles qui améliorent la cuisine ET qui peuvent être validées immédiatement.

4. Les Résultats : Moins de Promesses, Plus d'Actions

Les chercheurs ont testé MORCoRA sur six grands projets informatiques (comme des restaurants très fréquentés).

• Le verdict : MORCoRA a réussi à trouver des améliorations de code qui étaient 433 % plus susceptibles d'être vérifiées par les développeurs que les anciennes méthodes.
• La qualité : Même si les changements étaient légèrement moins "parfaits" mathématiquement que ceux des robots anciens, ils étaient réalistes. Ils étaient validés, appliqués, et le code s'en trouvait meilleur.

En Résumé

MORCoRA nous apprend une leçon simple mais puissante : La meilleure idée du monde ne sert à rien si personne n'a le temps de la mettre en œuvre.

Au lieu de simplement demander « Comment rendre ce code parfait ? », MORCoRA demande : « Comment rendre ce code meilleur et qui peut le valider aujourd'hui ? » C'est un pas de géant vers des logiciels plus sains, car il respecte le temps et l'énergie des humains qui les construisent.

Résumé technique

1. Problématique

Le refactoring (restructuration de code) vise à améliorer la structure interne du code sans en modifier le comportement externe. Bien que les techniques de recherche basées sur la recherche (Search-Based Software Engineering - SBSE) soient efficaces pour identifier des séquences de refactorisation optimisant la qualité du code, elles négligent souvent un aspect critique du développement logiciel réel : la disponibilité des développeurs pour la revue de code.

Dans les projets open-source et l'intégration continue, toute modification de code doit être révisée avant d'être appliquée. Cependant, une séquence de refactorisation recommandée peut échouer à être appliquée si :

1. L'expertise manque : Les développeurs disponibles ne possèdent pas les compétences nécessaires sur les fichiers modifiés.
2. La charge de travail est trop élevée : Les experts potentiels sont déjà surchargés par d'autres tâches (Pull Requests, Issues), ce qui entraîne des retards ou l'abandon de la revue.

L'article identifie le manque de prise en compte de cette « disponibilité de la revue » (Review Availability) comme un défi majeur. Une recommandation théoriquement parfaite mais impossible à réviser en pratique est inutile et peut même dégrader la qualité logicielle si elle n'est jamais appliquée.

2. Méthodologie : MORCoRA

Les auteurs proposent MORCoRA, une approche de recherche basée sur les algorithmes évolutionnaires multi-objectifs (NSGA-II) qui recommande simultanément des séquences de refactorisation et les révélateurs appropriés.

Objectifs de l'optimisation

MORCoRA cherche à optimiser trois objectifs simultanés :

1. Amélioration de la qualité du code (Qual) : Utilisation du modèle QMOOD (Quality Model for Object-Oriented Design) pour maximiser les attributs de maintenabilité (réutilisabilité, flexibilité, etc.) via des métriques de conception de bas niveau.
2. Préservation de la cohérence sémantique (Sem) : Pour éviter des refactorisations incohérentes (ex: déplacer une méthode study() d'une classe Student vers une classe Car), l'algorithme calcule une similarité sémantique basée sur le vocabulaire et les dépendances entre les classes source et cible.
3. Haute disponibilité de la revue (RA - Review Availability) : C'est la contribution centrale. Un score de RA élevé est attribué aux séquences pouvant être révisées par un petit groupe de développeurs (max 2) qui possèdent à la fois :
   • Une expertise suffisante sur les fichiers modifiés.
   • Une charge de travail (workload) faible au moment de la recommandation.

Modélisation de la Disponibilité de Revue

• Expertise : Calculée en pondérant la fréquence des commits d'un développeur sur un fichier par leur récence. Un commit récent compte plus qu'un ancien, reflétant une connaissance actuelle du code.
• Charge de travail (Workload) : Estimée par le nombre de Pull Requests et d'Issues dans lesquelles un développeur est actif sur une période donnée (7 jours dans l'étude).
• Score RA : La moyenne des expertises des révélateurs sélectionnés qui ne sont pas surchargés.

Algorithme de Recherche

L'approche utilise l'algorithme NSGA-II (Non-dominated Sorting Genetic Algorithm II) pour explorer l'espace des solutions.

• Représentation : Une solution est une séquence vectorielle d'opérations de refactorisation (ex: Move Method, Inline Class).
• Opérateurs : Croisement (Crossover) et Mutation sont appliqués pour générer de nouvelles séquences.
• Sortie : Un front de Pareto contenant des solutions offrant les meilleurs compromis entre les trois objectifs.

3. Contributions Clés

1. Proposition de MORCoRA : Une nouvelle technique de recommandation de refactorisation qui intègre explicitement la contrainte de disponibilité des révélateurs dans le processus de recherche.
2. Métrique de Disponibilité de Revue (Review Availability) : Conception d'une métrique quantitative combinant l'expertise (basée sur la fréquence et la récence des commits) et la charge de travail actuelle des développeurs.
3. Évaluation Comparative : Comparaison avec l'état de l'art (l'approche d'Ouni et al. qui ne considère que la qualité et la sémantique) et évaluation de différents algorithmes évolutionnaires (SPEA2, MOCell, IBEA, Recherche Aléatoire).
4. Recommandation de Révélateurs : Le système ne recommande pas seulement quoi refactoriser, mais aussi qui devrait le réviser.

4. Résultats de l'Évaluation

L'approche a été évaluée sur six dépôts open-source Java populaires (ex: Mockito, Retrofit, Glide).

Analyse Quantitative

• Performance de l'algorithme : NSGA-II s'est avéré être l'algorithme le plus performant parmi ceux testés (SPEA2, MOCell, IBEA, Recherche Aléatoire) pour trouver des solutions équilibrées sur les trois objectifs.
• Impact de l'objectif de disponibilité :
  • MORCoRA (avec l'objectif RA) a généré 433,8 % de solutions « révisables » en plus par rapport à l'approche de référence (sans objectif RA).
  • Bien que les scores de qualité (Qual) et de sémantique (Sem) soient légèrement inférieurs (environ 25 % et 33 % de moins respectivement) par rapport à l'approche sans contrainte de revue, la disponibilité de la revue (RA) est massivement supérieure.
  • MORCoRA évite de recommander des refactorisations qui, bien que techniquement bonnes, seraient bloquées par l'absence de révélateurs disponibles.

Analyse Qualitative

• Élimination des odeurs de code (Code Smells) : Sur un échantillon de 60 solutions analysées manuellement, 58,3 % ont réussi à éliminer des odeurs de code tout en restant sémantiquement cohérentes et révisables.
• Étude de cas (Glide) : Un exemple montre comment MORCoRA identifie un développeur surchargé (participant à 13 PRs/Issues) et exclut sa recommandation, privilégiant à la place un autre développeur expert mais disponible.
• Comparaison avec l'état de l'art : L'approche de référence (RA-) recommandait souvent des séquences pour lesquelles aucun révélateur disponible n'existait (score RA = 0), rendant ces refactorisations inapplicables en pratique.

5. Signification et Conclusion

L'article démontre que la recherche de refactorisation ne doit pas se limiter à l'optimisation pure du code. La faisabilité humaine (disponibilité et expertise des développeurs) est un facteur déterminant pour le succès de l'application des refactorisations.

• Pratique : Les outils de recommandation de refactorisation doivent intégrer des contraintes de ressources humaines pour éviter de surcharger les équipes ou de proposer des changements impossibles à réviser.
• Futur : Les auteurs suggèrent d'étendre l'évaluation de la charge de travail au-delà des seuls dépôts GitHub (en incluant d'autres projets ou tâches non techniques) et de valider l'outil via des études humaines avec des développeurs industriels.

En résumé, MORCoRA représente une avancée significative vers des outils d'ingénierie logicielle plus réalistes, alignant les objectifs d'optimisation technique avec les contraintes organisationnelles et humaines du développement logiciel moderne.