Clones phénoménologiques

Origine et évaluation des clones

Taxonomie des clones

Dans cette section, nous classons les clones selon deux critères principaux. Le premier critère porte sur l’origine du clone : s’agit-il d’un clone effectif lié à une opération de copie intra-projet, inter-projets et avec quelle motivation ? Dans un second temps, nous étudions les niveaux des clones selon leur étendue sur le code source. Nous ne nous intéressons pas ici au degré d’approximation des clones qui sera analysé dans le chapitre suivant consacré aux opérations d’édition et d’obfuscation sur les clones.

Clones phénoménologiques

Quels sont les processus à l’origine de l’apparition de clones intra- et inter-projets ? Une première possibilité est liée à un procédé de copie de code par le développeur dont les motivations peuvent être diverses. Au sein d’un même projet, cette opération permet de réutiliser rapidement du code dans un nouveau contexte. Lorsque la copie est réalisée d’un projet extérieur, celle-ci peut être légitime ou non. Dans ce deuxième cas, il s’agit d’une opération de plagiat généralement suivie de procédés d’obfuscation afin de rendre la détection du clone moins aisée. Enfin d’autres clones de niveau structurel (architecture de paquetages ou unités de compilation) peuvent témoigner de l’utilisation de patrons de conception classiques.

Clones intra-projet

La copie de morceaux de code dans l’optique d’une réutilisation dans de nouveaux contextes est un processus (malheureusement) courant chez la plupart des programmeurs. Il apparaît ainsi selon plusieurs études [103, 102, 104] sur certains projets Open Source que leur volume pourrait être réduit jusqu’à 15% par la factorisation de morceaux de code copiés.

Un moyen simple de détecter à leur source ces clones phénoménologiques pourrait être de surveiller les opérations de copie-collage de code au sein de l’environnement de développement utilisé [68]. Il serait ainsi possible d’inciter le programmeur à factoriser son code pour éviter toute redondance. Cependant, si dans certains cas la factorisation est possible, dans d’autres contextes celle-ci demeure impossible à cause des limitations du langage utilisé. Ainsi par exemple, un langage tel que Java n’offrant pas de mécanisme de généricité de type primitif nécessite la copie de code avec adaptation de types pour utiliser du code avec des types primitifs différents1 .

Dans certains cas, en programmation objet, l’intégration de plusieurs fonctionnalités déjà implantées peut se heurter à l’absence d’héritage multiple. Une autre situation problématique est rencontrée lorsque le code correspondant à une fonctionnalité est éparpillé au sein d’un projet (aspect). Une solution serait d’étendre le langage pour surmonter ces limitations (introduction du support de composition de caractéristiques [88] ainsi que des aspects) ou alors d’utiliser des outils de génération automatique de code (pratique couramment utilisée pour le développement de Software Product Lines).

La réduction du volume de code d’un projet par la factorisation de clones permet principalement une diminution de l’effort de maintenance généralement justifiée par un souci temporel et financier. La fiabilité et la sécurité du code produit est également un critère important car un bug causé par un exemplaire de code cloné a une faible probabilité d’être corrigé spontanément sur les autres exemplaires. D’autre part, une réécriture optimisée d’un exemplaire de clone peut ne pas être reportée.

Dès lors le choix délibéré d’introduire une duplication de code ne peut être rationnellement motivé que par un gain de productivité à court terme qui surpasserait le gain à long terme d’un code factorisé. Ce choix est notamment réalisé lorsque la production d’un code abstrait nécessite un effort de développement important et/ou lorsque sa compréhension serait difficile. Introduire des clones peut également être utile dans des cas d’optimisation du code à l’exécution ou pour l’adaptation de composantes sur des architectures différentes (tel que par exemple le module multi-thread du serveur web Apache [124]). 

Clones inter-projets légitimes L’emprunt de code d’un projet vers un autre permet généralement un gain de temps de développement même si quelquefois certaines adaptations plus ou moins importantes doivent être menées. Cette pratique, pouvant consister à la réutilisation de portions plus [101] ou moins importantes de code (méthodes, classes et unité de compilation) peut être légitime si la licence du projet source du clone l’autorise. C’est le cas notamment des licences Open Source2 autorisant les œuvres dérivées et donc l’emprunt de code.

Cependant une licence Open Source est libre de fixer ses propres conditions quant à la licence de l’œuvre dérivée : ainsi si les licences de type BSD n’imposent aucune condition quant au projet destination du clone (si ce n’est de conserver les informations concernant l’auteur du code original), les licences de type GPL conditionnent la redistribution d’œuvres dérivées sous les mêmes termes. Il convient donc de choisir judicieusement la licence du projet destination.