Améliorer la détection de la dette technique avec BERT

Dans le développement logiciel, la "Dette technique" désigne les compromis que les développeurs font quand ils choisissent une solution rapide plutôt qu'une plus complète. Ça arrive souvent pour accélérer la livraison des fonctionnalités ou des versions de logiciels. Le terme "Dette Technique Auto-Reconnue" (SATD) décrit la dette technique que les développeurs reconnaissent dans leurs commentaires dans le code. Reconnaître et traiter la SATD est important car ça peut faire grimper significativement les coûts de maintenance des projets logiciels avec le temps. Des études suggèrent que la dette technique peut représenter 20% à 40% de la valeur d'un projet logiciel avant dépréciation. Donc, détecter la SATD à temps permet aux ingénieurs logiciels et aux décideurs de la gérer efficacement.

#Défi de la Détection de la SATD

Détecter la SATD dans les commentaires du code source est complexe à cause du déséquilibre entre les commentaires SATD et non-SATD. Par exemple, dans certaines bases de données, les commentaires SATD ne représentent que 1,27% des commentaires totaux. Une si petite représentation rend la classification des commentaires complexe. Dans de nombreux cas, une base de données peut n'avoir que quelques commentaires SATD disponibles pour les tests, rendant difficile l'évaluation des méthodes de détection.

Des recherches passées ont montré que certaines phrases peuvent signaler des commentaires SATD, comme "todo" ou "hack". Cependant, les méthodes existantes ne tiennent souvent pas compte de la difficulté de classer ces commentaires, surtout quand les bases de données ont des caractéristiques différentes.

En plus, beaucoup d'études n'utilisent pas de méthodes fiables comme la validation croisée K-fold stratifiée pour évaluer leurs résultats. Ça peut mener à des repères peu clairs quand il s'agit de comparer la performance de classification entre différentes méthodes.

#Nouvelle Approche pour la Détection de la SATD

Pour améliorer la détection de la SATD, on a adopté un modèle plus récent appelé BERT, qui est conçu pour traiter le langage. Notre étude a impliqué deux approches principales : une où on a entraîné le modèle BERT avec des commentaires de divers projets logiciels (cross-project), et une autre où on l'a entraîné avec des commentaires d'un seul projet (intra-project).

On visait à appliquer diverses techniques pour améliorer le Traitement des données. Pour le scénario cross-project, on a entraîné le modèle sur des commentaires de 19 dépôts et l'a testé sur le dépôt restant. Pour le scénario intra-project, on a entraîné le modèle sur 90% des commentaires d'un projet et utilisé les 10% restants pour évaluer sa performance.

#Techniques de Traitement des Données

Avant de nourrir le modèle BERT avec les données, on a préparé les commentaires pour s'assurer que le modèle puisse mieux les comprendre. On a utilisé un tokenizer qui gérait bien le texte, prenant en compte le mélange de langage informel et d'éléments de type code trouvés dans les commentaires. Par exemple, on a formaté les commentaires pour correspondre aux meilleures pratiques de Java pour nommer des variables.

On a aussi élargi le vocabulaire du tokenizer BERT. Ça impliquait d'identifier des mots dans notre base de données qui n'étaient pas déjà reconnus par le tokenizer et de les ajouter. On visait à développer un tokenizer universel qui pourrait gérer efficacement à la fois le langage naturel et les éléments de codage.

#Entraînement et Augmentation des Données

Tout au long de notre étude, on a inclus diverses stratégies pour traiter le déséquilibre de données lié aux commentaires SATD et non-SATD. L'une de ces stratégies impliquait d'utiliser le "re-sampling forcé de minorité". Ça veut dire qu'en entraînant, on veillait à ce que les commentaires SATD soient inclus dans les lots plus souvent, surtout quand les commentaires non-SATD dominaient les lots.

En plus du re-sampling, on a aussi exploré l'augmentation des données en dupliquant les commentaires SATD avec des mots clés signalant la dette technique enlevés. Par exemple, un commentaire qui disait à l'origine "// FIXME: Ça devrait probablement..." pouvait être reformulé en "Ça devrait probablement..." pour créer une nouvelle entrée tout en gardant son sens.

#Résultats du Modèle BERT

Dans nos évaluations cross-project, le modèle BERT a montré des résultats impressionnants en améliorant la performance par rapport aux méthodes existantes dans presque tous les cas avec les jeux de données donnés. Cependant, dans les évaluations intra-project, les résultats étaient moins favorables. La performance ne correspondait pas à celle des autres approches en moyenne. Nos résultats soutiennent l'idée que plus on a de données, mieux c'est pour obtenir des résultats avec des modèles comme BERT.

Les résultats montrent que, même si le modèle pouvait identifier les commentaires SATD correctement quand il était entraîné sur des jeux de données complets, il avait du mal avec des jeux de données plus petits provenant de projets uniques. Les résultats ont aussi montré que les techniques existantes fonctionnaient toujours mieux dans des scénarios où les données étaient limitées.

#Futures Directions pour la Recherche sur la SATD

Pour l'avenir, la classification des commentaires SATD bénéficierait beaucoup de méthodes plus raffinées qui distinguent les commentaires plus faciles à classer de ceux plus difficiles. En identifiant quels commentaires sont plus faciles à classifier et lesquels sont plus challengeants, on peut développer de meilleurs modèles qui prennent cette info en compte.

De plus, on voit qu'il y a besoin de meilleures techniques d'augmentation des données pour profiter au max des modèles NLP comme BERT quand les jeux de données sont rares. Ça pourrait impliquer d'explorer de nouvelles façons de remplacer des mots par des synonymes ou de générer des exemples d'entraînement supplémentaires basés sur les commentaires qu'on a.

#Conclusion

En résumé, notre exploration de la détection des commentaires SATD avec le modèle BERT montre que, même si des améliorations significatives peuvent survenir avec assez de données, des défis restent dans des situations avec peu de données. L'étude souligne l'importance d'utiliser des techniques de traitement des données appropriées et de chercher continuellement de meilleures façons d'augmenter les jeux de données pour obtenir des résultats plus fiables. En affinant notre compréhension et nos méthodes dans ce domaine, on pave la voie pour une gestion plus efficace de la dette technique dans les projets logiciels, menant finalement à une meilleure qualité logicielle et à des coûts de maintenance réduits.