Cet article ne cite pas suffisamment ses sources (juin 2019).

Si vous disposez d'ouvrages ou d'articles de référence ou si vous connaissez des sites web de qualité traitant du thème abordé ici, merci de compléter l'article en donnant les références utiles à sa vérifiabilité et en les liant à la section « Notes et références ».

En pratique : Quelles sources sont attendues ? Comment ajouter mes sources ?

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^[1].

Cette activité est identifiée dans différentes méthodes de développement logiciel, et en particulier, extreme programming^[2].

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.

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

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.

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.

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

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.

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^[4]. 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.

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.

Quand il y a du code dupliqué, ou encore, du code qui réalise la même fonction, dans différentes procédures ou différents objets, il est bon de le factoriser, de l'encapsuler, de ne laisser qu'un exemplaire de cette fonction, dans une librairie. En effet, il est plus facile pour la compréhension et la correction d'erreurs de codage de n'avoir qu'un source unique^[5].

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^[3].

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 les outils de génération de documentation logicielle).

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

• Portail de l’informatique
• Portail de la programmation informatique