Réusinage de code

Le réusinage de code est l'opération consistant à retravailler le code source d'un programme informatique – sans toutefois y ajouter des fonctionnalités ni en corriger les erreurs – de façon à en améliorer la lisibilité et, par voie de conséquence, la maintenance, ou à le rendre plus générique (afin par exemple de faciliter le passage de simple à multiple précision) ; on parle aussi de « remaniement ». Cette technique utilise quelques méthodes propres à l'optimisation de code, avec des objectifs différents.

Le terme réusinage est originaire du Québec. L'équivalent en anglais est code refactoring, parfois rendu par refactorisation, terme qui, selon l'Office québécois de la langue française (OQLF), est à éviter.

Justification

Au cours de la vie d'un logiciel, on lui ajoute souvent des fonctions, et en tout cas on corrige ses erreurs (bugs ou bogues). Ces modifications successives, n'améliorant pas en général la lisibilité du logiciel, ne facilitent pas, de ce fait, 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 fondamentale.

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.

Niveaux de réusinage

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

Modification de la présentation

Ce niveau améliore 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

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 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

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).

Refonte de la conception

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.

Activités de réusinage

Suppression du code mort

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 qu'à la suite de 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.^{[réf. nécessaire]} 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

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

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

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).

Voir aussi

Bibliographie

• 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)