Modifier un code fonctionnel présente un risque. En effet il est possible d’y introduire des bogues et ainsi provoquer une régression de l’application. Le logiciel cesse alors de se comporter comme attendu.
Les bogues sont très souvent introduits parce que le code n’est pas lisible. On y trouve fréquemment des blocs d’instructions dupliqués à plusieurs endroits ou des structures conditionnelles complexes. Ces signes font partie de ce que l’on appelle code smells. Le compilateur ne se soucie pas de savoir si le code écrit est clair ou pas. Cependant toute modification du système implique un être humain, généralement un développeur, qui s’en préoccupe. Un système mal conçu est difficile à modifier, principalement parce qu’il n’est pas évident de savoir où le changement doit être effectué. S’il est difficile de savoir ce qu’il faut modifier, alors il y a de grandes chances que le programmeur fasse des erreurs et introduise des bogues. L’on peut être tenté de modifier le moins possible le système, après tout l’application est en production. Mais même si le programme marche, il complique la vie du développeur car ce dernier ne peut répondre convenablement aux besoins de son client. C’est pourquoi Abelson et al. [Abelson 1985] attirent notre attention sur le fait que les programmes doivent être écrits de sorte à être lus par les Hommes et non pas seulement pour être exécutés par les machines. D’après Fowler et al. [Fowler 1999] la clé pour avoir un code lisible et facilement modifiable est le refactoring. Les auteurs de [Fowler 1999] remarquent que le refactoring fait de façon disciplinée augmente non seulement la confiance dans le code résultant, mais aussi permet au processus de se dérouler avec moins de stress. Notre objectif est d’introduire à l’aide de quelques exemples la notion de refactoring. Nous illustrerons comment améliorer la structure interne de l’application sans introduire de bogue dans le code. Cet article commence par définir la notion de refactoring pour ensuite introduire le concept de code smell sur lequel est basé tout refactoring. Finalement nous appliquerons le refactoring sur quelques extraits de code qui présentent des smells préalablement identifiés.

Majirus Fansi