Réusinage de code

Un article de Wikipédia, l'encyclopédie libre.
(Redirigé depuis Refactorisation)
Aller à : navigation, rechercher
Synonymes de « Réusinage de code » : Réusinage (au Québec).

Le réusinage de code (parfois nommé refactorisationanglicisme venant de refactoring) consiste à retravailler le code source d'un code informatique sans ajouter de fonctionnalités au logiciel ni corriger de bogues, mais en améliorant sa lisibilité pour simplifier sa maintenance, ou le rendre plus générique (par exemple afin de faciliter le passage de simple en multiple précision) ; on parle aussi de remaniement.

Le terme réusinage est originaire du Québec. Cette technique utilise quelques méthodes également utilisées en optimisation du code, avec des objectifs différents. Selon l'OQLF, l'emploi du terme refactorisation est à éviter[1].

Pourquoi réusiner ?[modifier | modifier le code]

Au cours de la vie d'un logiciel, on lui ajoute souvent des fonctions, et en tout cas on corrige ses bogues. Ces modifications successives n'améliorent pas en général sa lisibilité, donc la facilité de sa maintenance ultérieure.

Le code source d'un programme a tout intérêt à rester, malgré ses modifications, le plus clair possible.

Les techniques de programmation agile, où évolution et mise à disposition se font en quasi-continu, rendent cette exigence encore plus critique.

Pour toujours conserver un code aussi simple que possible, on :

  • S'assure que toute l'information nécessaire est disponible ;
  • Supprime toute information redondante ou duplication de code ;
  • Simplifie lorsque c'est possible l'algorithmique des méthodes ;
  • Limite la complexité de chaque classe ;
  • Limite le nombre de classes.

Les niveaux de réusinage[modifier | modifier le code]

Durant une même session de réusinage, on considèrera ces différents niveaux :

Modification de la présentation[modifier | modifier le code]

À ce niveau améliorent la présentation du code source sans modifier le code exécuté : les commentaires (suppression de commentaires superflus, l'ajout de commentaires sur des sections complexes…) et la mise en page (indentation du code rendue homogène, passages à la ligne…). Des logiciels comme Eclipse ou même l'historique cb (C beautifier) de Linux peuvent faciliter cette opération cosmétique, voire la prendre en charge. Eclipse en propose même plusieurs variantes.

Modification de l'algorithmique[modifier | modifier le code]

Ce type de modification vise à conserver des méthodes aussi simples que possible, par exemple en scindant une méthode ou un algorithme en plusieurs parties et/ou en confiant à un objet annexe une partie du traitement.

Ce type de modification introduisant fréquemment des bogues, il s'accompagne nécessairement d'une batterie de tests unitaires exécutée après chaque modification proposée pour s'assurer d'une non-régression.

Relocalisation de procédures[modifier | modifier le code]

Consiste à déplacer une procédure soit dans une autre procédure, soit dans le corps principal de la classe. Peut également induire un déplacement de procédure dans une classe-mère (Pull-Up), ou dans une classe-fille (Push-Down). (à compléter).

Refonte de la conception[modifier | modifier le code]

Cette modification plus radicale remanie la hiérarchie des classes composant l'application. La progressivité et les tests de non-régression sont plus que jamais indispensables. Utiliser un explorateur de classes facilite le processus.

Des activités de réusinage[modifier | modifier le code]

Suppression du code mort[modifier | modifier le code]

Le code mort est le code dont on constate qu'il ne sert à rien faute d'être appelé par une autre partie du programme. Sans doute utile dans une étape antérieure du développement ou du débogage, il n'a plus de raison d'être, rend la lecture du code source plus complexe et déconcentre les responsables de la maintenance.

Pour détecter le code mort, on peut utiliser les techniques suivantes :

  • recherche statique par l'outil grep sur le code source pour vérifier si une méthode est bien appelée quelque part ;
  • analyseur de références croisées (par exemple l'outil objxref livré avec le compilateur turbo C de Borland) ;
  • outil de mesure de couverture de code. Cette opération très pratique permet également de vérifier des portions de méthodes. Risque : du code peut être marqué à tort comme non couvert simplement parce que la suite de test n'est pas complète (or aucune ne peut être prouvée l'être totalement hormis dans des cas triviaux).

Autre forme de code mort : le code commenté ("commented out"). Il arrive souvent que suite à des modifications, on laisse des pans entiers de l'ancien code pour pouvoir éventuellement revenir à la version antérieure facilement. Ce type de code devrait également être supprimé à la fin de la session de développement.

Dans tous les cas, il n'est jamais recommandé de conserver du code qui pourrait servir un jour. Il est toujours préférable de le supprimer de la version de travail et d'utiliser un outil de gestion de versions pour archiver ce type de code.

Ajout d'assertions[modifier | modifier le code]

Les assertions définissent un ensemble de règles à respecter par une application, dans le cadre de la programmation par contrat. Elles sont très intéressantes d'une part car elles permettent de simplifier le débogage en détectant les erreurs au plus tôt, mais également parce qu'elles sont placées à l'intérieur du code qu'elles contrôlent et peuvent donc aider à la compréhension de l'état du système.

Renommage[modifier | modifier le code]

Au fur et à mesure du développement d'un logiciel, le rôle des classes et des méthodes devient moins clair. Il est donc souvent utile de modifier les noms de classes ou de méthodes pour bien indiquer ce rôle.

Commentaires[modifier | modifier le code]

Il n'existe pas de consensus sur la question des commentaires en documentation du logiciel. Il est cependant important de toujours synchroniser commentaire, code et documentation externe (voir POD).

Notes[modifier | modifier le code]

  1. L'expression refactorisation, calquée sur l'anglais refactoring, est en effet un faux ami : l'origine du mot anglais refactoring est factory (usine) et non factor. Il est donc sans rapport avec le terme français factorisation (ou son dérivé refactorisation) qui, en algèbre, est associé à l'utilisation d'un produit de facteurs.

Références[modifier | modifier le code]

  • Jean-Philippe Retaillé, Refactoring des applications Java/J2EE, Eyrolles, 2005, 390 p., ISBN 2-212-11577-6
  • Martin Fowler, Kent Beck, Refactoring: Improving the Design of Existing Code, Addison-Wesley Professional, 1999, 464 p., ISBN 0-201-48567-2
    • (en) refactoring.com référence les modèles pour la refactorisation tirés du livre, ainsi que de nouveaux modèles.
  • Joshua Kerievsky, Refactoring to Patterns, Addison-Wesley Professional, 2004, 400 p., ISBN 0-321-21335-1