Integrating Structural and Semantic Analysis for Code Smell Refactoring Prediction

Le logiciel n'est jamais vraiment terminé. Tel une ville qui croît de manière organique sur des décennies, un programme informatique accumule des couches d'ajouts, de correctifs et de solutions rapides. Avec le temps, cette croissance organique peut entraîner des faiblesses structurelles, à l'instar d'un bâtiment dont le couloir aurait été élargi sans que les murs ne soient renforcés. Dans le monde du génie logiciel, ces défauts localisés sont appelés « odeurs de code » (code smells). Il ne s'agit pas d'erreurs provoquant le plantage d'un programme, mais plutôt de signes de mauvaise conception qui rendent le code difficile à comprendre, à modifier ou à maintenir. Lorsque les développeurs repèrent ces odeurs, ils effectuent souvent un « refactoring » (remaniement), un processus méticuleux de réorganisation du code afin d'en améliorer la structure sans changer ce que le logiciel fait réellement. Le défi réside dans le fait que les développeurs ne corrigent pas toujours toutes les odeurs qu'ils trouvent, et prédire lesquelles seront corrigées est difficile car la décision dépend souvent de l'intention humaine et du contexte, et non seulement du code lui-même.

Une équipe de chercheurs de l'Université de Milano-Bicocca s'est donné pour mission de voir si les machines pouvaient apprendre à prédire ces décisions humaines. Ils voulaient savoir si un ordinateur pouvait examiner un morceau de code, identifier un défaut et deviner avec précision si un développeur finirait par le nettoyer. Pour ce faire, ils ont construit un système combinant deux manières différentes d'analyser le code. La première est traditionnelle : compter des propriétés telles que la longueur d'une méthode ou le nombre de variables qu'elle utilise. La seconde est plus moderne et complexe : transformer le code en une carte de sa logique et de son comportement, puis traduire cette carte en une représentation mathématique qu'un ordinateur peut analyser pour y déceler des motifs cachés. En injectant ces informations combinées dans des modèles d'apprentissage automatique, les chercheurs ont testé si les ordinateurs pouvaient apprendre les règles subtiles qui guident les développeurs lorsqu'ils choisissent de procéder à un refactoring.

Les chercheurs ont rassemblé des données provenant de 79 projets Java open-source, une collection de logiciels qui ont été développés et maintenus par de nombreuses personnes au fil du temps. Ils ont utilisé des outils automatisés pour scanner l'historique de ces projets, identifiant des milliers d'occurrences où des odeurs de code étaient présentes et suivant lesquelles elles ont été corrigées par des actions de refactoring spécifiques, telles que le renommage d'une variable, l'extraction d'une méthode en une portion plus petite ou le changement d'un paramètre. Ils ont ensuite créé un ensemble de données hybride pour chaque morceau de code. Cet ensemble comprenait des mesures standards, comme le nombre de lignes dans une méthode, ainsi que deux types différents de « plongements » (embeddings). Un type de plongement cartographiait le flux de contrôle, montrant l'ordre d'exécution des instructions. L'autre, plus avancé, cartographiait les relations sémantiques profondes, capturant comment les données circulent dans le programme et comment les différentes parties du code dépendent les unes des autres, créant ainsi un portrait riche et multidimensionnel du comportement du code.

Les résultats ont montré que les modèles d'apprentissage automatique sont effectivement capables de prédire le refactoring avec un haut degré de fiabilité. Lorsque les modèles ont été testés sur dix types différents d'opérations de refactoring, ils ont fréquemment atteint des scores AUC bien supérieurs à 0,70, et pour certaines tâches, ont même dépassé 0,80. Cela suggère qu'il existe effectivement des motifs détectables dans le code qui signalent l'intention d'un développeur de le nettoyer. Cependant, l'étude a révélé une nuance cruciale : toutes les odeurs de code ne se valent pas. Les modèles étaient exceptionnellement doués pour prédire les changements structurels, tels que l'ajout d'un paramètre à une méthode ou le changement du type d'une variable. Ces actions sont souvent dictées par des facteurs clairs et mesurables comme la longueur d'une instruction ou la complexité d'un calcul. En revanche, les modèles avaient du mal à prédire les changements conceptuels, comme le renommage d'une méthode. Le renommage est une décision souvent subjective, basée sur la façon dont un développeur conçoit l'objectif du code, un facteur difficile à capturer par de simples chiffres ou des cartes structurelles.

La découverte la plus significative concerne le type de représentation des données utilisé. Les chercheurs s'attendaient initialement à ce que l'ajout de cartes plus complexes du flux d'exécution du code améliore les prédictions. Au lieu de cela, ils ont découvert qu'un type spécifique de carte de flux, qui suivait l'ordre des instructions, introduisait du bruit qui perturbait les modèles. Lorsque cette carte de flux était combinée aux mesures traditionnelles, elle rendait souvent les prédictions moins bonnes, car l'ordinateur peinait à ignorer les détails non pertinents. Cependant, lorsque les chercheurs sont passés à la représentation plus avancée qui combinait les dépendances structurelles avec le texte et la logique réels du code, les résultats ont radicalement changé. Cette représentation plus riche a fourni un signal complémentaire que les modèles ont pu utiliser efficacement. En fait, pour certaines tâches, les modèles entraînés uniquement sur cette représentation avancée ont presque aussi bien performé que ceux entraînés sur l'ensemble des données, prouvant que la compréhension structurelle et sémantique profonde du code est un prédicteur puissant en soi.

L'étude a également mis en lumière les limites de ce qui peut être prédit à partir du seul code. Si les modèles peuvent prévoir de manière fiable les corrections techniques dictées par la complexité, ils ne peuvent pas facilement anticiper les décisions humaines derrière le renommage ou la réorganisation du code pour des raisons de clarté. Cela suggère que si les machines peuvent être excellentes pour identifier quand un logiciel est techniquement en retard sur sa maintenance, la décision finale de refactoriser repose souvent sur une vision et un contexte du développeur qui existent en dehors du code lui-même. La recherche conclut que l'avenir de la maintenance logicielle automatisée ne réside pas dans le remplacement du jugement humain, mais dans l'utilisation de ces outils prédictifs pour mettre en évidence les dettes structurelles les plus urgentes, permettant ainsi aux développeurs de concentrer leur temps limité sur les changements qui comptent le plus. En comprenant quels signaux sont forts et lesquels sont du bruit, nous pouvons construire de meilleurs outils pour aider à maintenir notre infrastructure numérique saine et durable.