Au fil du développement d’une application, le code source accumule des lignes de code à la structure « sale », qui menacent les possibilités d’application et la compatibilité d’un logiciel. Pour résoudre ce problème, on peut soit écrire un code source entièrement nouveau, soit restructurer le code par petites étapes. Les programmeurs et les entreprises choisissent de plus en plus le refactoring, ou réusinage de code, pour optimiser à long terme un logiciel fonctionnel et favoriser sa lisibilité et sa clarté pour les autres programmeurs.
Quand on réusine un code, il faut se demander quels problèmes résoudre et avec quelle méthode. Désormais, le refactoring fait partie des bases pour apprendre la programmation et prend de plus en plus d’importance. Quelles méthodes faut-il mettre en œuvre et avec quels avantages et inconvénients faut-il composer ?
La programmation d’un logiciel est un processus fastidieux, auquel peuvent participer plusieurs développeurs. Ainsi, le code source rédigé est souvent retravaillé, modifié et complété. Par manque de temps ou à cause de pratiques désuètes, le code source accumule des lignes sales, que l’on appelle « code smells ». Ces points faibles développés au fil du temps menacent les possibilités d’application et la compatibilité d’un programme. Pour éviter l’érosion et la dégradation progressives d’un logiciel, il faut passer par le réusinage du code.
On peut comparer le refactoring à la relecture d’un livre. Sans produire un livre entièrement nouveau, la relecture aboutit à un texte qui sera plus compréhensible. Tout comme pour la relecture, qui emploie différentes approches comme raccourcir une phrase, reformuler, supprimer ou restructurer, le refactoring s’appuie sur plusieurs méthodes comme l’encapsulation, le reformatage ou l’extraction pour optimiser un code sans altérer son fonctionnement.
Ce processus est nettement plus efficace en termes de coûts que la rédaction d’un code entièrement nouveau. Pour le développement de logiciels itératif et incrémentaux, comme le développement logiciel agile, le refactoring est capital, car dans ce modèle cyclique, les programmeurs apportent continuellement des modifications à leur logiciel. Le refactoring est une étape de travail constante.
Il faut tout d’abord comprendre comment un code peut se modifier et muter en un tristement célèbre code spaghetti. Délais trop courts, manque d’expérience ou directives pas assez claires : en intégrant des instructions inutilement compliquées, la programmation d’un code entraîne des pertes de fonctionnalité. Plus son domaine d’application est rapide et complexe, plus la dégradation du code prend de l’ampleur.
Le terme code spaghetti désigne un code source brouillon et illisible, dont le langage de programmation est difficile à comprendre. Exemples simples de code brouillon : les sauts inconditionnels (goto) superflus, qui donnent l’instruction au programme de sauter d’un endroit à l’autre du code source. Citons aussi les boucles for/while et les instructions if superflues.
Ce sont particulièrement les projets auxquels participent de nombreux développeurs logiciels qui ont tendance à intégrer du texte source incompréhensible. Lorsqu’il passe entre plusieurs mains, et lorsqu’il contient déjà des faiblesses de départ, le code source intègre de plus en plus de liens prenant la forme de « solutions de contournement » : une révision du code dispendieuse est presque inévitable. Dans les cas les plus extrêmes, le code spaghetti peut mettre en danger le développement complet d’un logiciel. Alors, même le refactoring ne peut plus résoudre le problème.
Moins graves, on distingue aussi les codes smells et la pourriture du logiciel. Avec l’âge, un code peut commencer à « sentir », au sens figuré, à cause de lignes sales. Les lignes difficiles à comprendre empirent avec l’intervention d’autres programmeurs ou l’ajout de compléments. Si, dès l’apparition des premiers codes smells, on n’entreprend aucun réusinage du code, celui-ci se dégrade visiblement et perd sa fonctionnalité : il pourrit (de l’anglais « code rot »).
Le but du réusinage du code est purement et simplement de produire un meilleur code. Un code efficace permet de mieux intégrer de nouveaux éléments, sans générer de nouvelles erreurs. Si la lecture du code ne leur demande pas d’effort particulier, les programmeurs s’y retrouvent plus vite et peuvent corriger ou éviter les bugs plus facilement. Le refactoring a également pour objectif de simplifier l’analyse des erreurs et la maintenabilité d’un logiciel. Les programmeurs voient leur tâche allégée lorsqu’ils contrôlent un code source.
Les techniques employées pour réusiner un code sont aussi variées que les erreurs qu’elles doivent corriger. Au fond, le refactoring se définit en fonction des erreurs et fait apparaitre les étapes nécessaires pour raccourcir ou supprimer une méthode de résolution. Les sources d’erreurs que l’on peut corriger lors d’un réusinage du code sont, entre autres :
Le refactoring doit toujours avoir lieu avant de modifier une fonction du programme. Le mieux est de procéder par toutes petites étapes et de tester les modifications apportées au code avec des processus de développement de logiciels, comme le développement piloté par les tests (TDD pour Test Driven Development) ou l’intégration continue (CI pour Continuous Integration). En résumé, le TDD et la CI recommandent de tester continuellement les petites sections de code nouvellement ajoutées, que les programmeurs créent, intègrent et contrôlent sur le plan fonctionnel par des tests automatisés et fréquents.
La règle d’or : modifier le programme de l’intérieur par petites étapes sans toucher aux fonctions extérieures. Après chaque modification, lancer un cycle de test aussi automatisé que possible.
Il existe de très nombreuses techniques concrètes de refactoring. Les travaux foisonnants de Martin Fowler et Kent Beck en proposent un aperçu complet : « Refactoring: Improving the Design of Existing Code ». En voici un court résumé :
Le développement rouge-vert est une méthode pilotée par les tests du développement logiciel agile. Elle s’applique lorsque l’on souhaite intégrer une nouvelle fonction à un code existant. Le rouge symbolise le premier cycle de tests, avant l’implémentation de la nouvelle fonction dans le code. Le vert symbolise la section de code la plus simple possible et nécessaire à cette fonction pour réussir le test. Il en résulte une extension avec des cycles de tests en continu pour résoudre les lignes de code erronées et augmenter la fonctionnalité. Le développement rouge-vert est un pilier du refactoring en continu dans le cadre d’un développement logiciel également en continu.
Cette méthode de réusinage du code décrit une modification d’un système par étapes et l’adaptation d’anciennes lignes de code implémentées aux nouvelles sections de code. La technique Branching-by-Abstraction est généralement utilisée lors de grandes modifications portant sur la hiérarchie des classes, l’hérédité ou l’extraction. L’implémentation d’une abstraction qui reste liée à une ancienne implémentation permet de relier d’autres méthodes et classes à l’abstraction et de remplacer la fonctionnalité de l’ancienne section de code par cette même abstraction.
On arrive souvent à ce résultat en utilisant les méthodes pull-up ou push-down. Elles créent un lien entre une nouvelle fonction, de meilleure qualité, et l’abstraction, tout en orientant les liens vers celle-ci. Ainsi, on peut rediriger une classe inférieure vers une classe supérieure (pull-up), ou bien les composants d’une classe supérieure vers une classe inférieure (push-down).
On peut enfin supprimer les anciennes fonctions sans prendre de risque pour la fonctionnalité de l’ensemble. Grâce à ces petites modifications, le fonctionnement du système reste inchangé, tandis que l’on peut remplacer les lignes de code sales par des lignes de code propres, section par section.
Le refactoring doit rendre aussi lisibles que possible les méthodes du code. Dans le meilleur des cas, dès la lecture, même un programmeur extérieur doit être capable de comprendre la logique interne d’une méthode. Pour compiler efficacement les méthodes, le réusinage du code propose différentes techniques. L’objectif de chaque modification est de distinguer chaque méthode, de supprimer les doublons et de diviser les méthodes les plus longues en éléments distincts pour permettre leur modification ultérieure.
Voici des exemples de techniques adéquates :
Pour améliorer un code, on doit parfois décaler les attributs ou méthodes d’une classe à l’autre. Voici les techniques adaptées :
Cette méthode a pour objectif de répartir les données au sein des classes et de les maintenir aussi courtes et claires que possible. Les liens inutiles entre les classes, qui entravent le bon fonctionnement du logiciel dès la moindre modification, doivent être supprimés et répartis entre les classes adéquates.
Exemples de techniques adaptées :
Au cours du refactoring,il faut, autant que possible, simplifier les expressions conditionnelles. Exemple des techniques adaptées :
L’invocation des méthodes gagne en rapidité et en simplicité grâce aux techniques suivantes, entre autres :
Dans l’exemple suivant, on voit bien que, dans le code source, le nom de la méthode ne renseigne pas clairement et rapidement sur sa fonctionnalité. La méthode doit retourner le code postal contenu dans l’adresse d’un bureau, mais le code ne le reflète pas clairement. Pour gagner en précision dans la formulation, le réusinage du code préconise de renommer la méthode.
Avant :
String getPostalCode() {
return (theOfficePostalCode+“/“+theOfficeNumber);
}
System.out.print(getPostalCode());Après :
String getOfficePostalCode() {
return (theOfficePostalCode+“/“+theOfficeNumber);
}
System.out.print(getOfficePostalCode());| Avantages | Inconvénients |
|---|---|
| Une meilleure compréhension facilite la maintenance et les possibilités d’extension du logiciel. | Un manque de précision lors du refactoring peut implémenter de nouveaux bugs et de nouvelles erreurs dans le code. |
| La restructuration du code source peut se faire sans modifier le fonctionnement. | Il n’existe pas de définition précise de ce qu’est un « code propre ». |
| Une meilleure lisibilité accroît la compréhension du code pour les autres programmeurs. | Bien souvent, le client ne voit pas la différence lorsque le code est amélioré, car le fonctionnement reste identique : le gain n’est donc pas évident. |
| Retirer les redondances et les doublons améliore l’efficacité du code. | Dans de grandes équipes travaillant sur le réusinage du code, la coordination peut exiger un temps étonnamment long. |
| Des méthodes indépendantes évitent que les modifications locales aient un impact sur une autre partie du code. | |
| Un code propre, avec des méthodes et des classes courtes et indépendantes, se caractérise par une plus grande facilité de test. |
Le principe de base du refactoring est le suivant : ajouter de nouvelles fonctions uniquement si celles-ci ne modifient pas le comportement initial du code source. On peut apporter des modifications au code source (refactoring) uniquement si celles-ci ne créent pas de nouvelle fonction.
Les développeurs doivent considérer un certain nombre d’éléments : l’application doit être fonctionnelle et ergonomique, mais elle doit également disposer d’une performance optimale et être exempte d’erreurs de programmation. Finalement, le produit doit pouvoir fonctionner sur les plates-formes et les appareils ciblés. En quoi des Software Development Kits (SDK) peuvent-ils aider à atteindre ces...
Le « legacy code » est un terme anglais signifiant « ancien code ». Ce type de code est généralement incompréhensible ou difficile à entretenir et à utiliser pour les programmeurs, car il repose sur d’anciennes versions du logiciel ou a été écrit par d’autres entreprises. Il est impossible de vérifier un code legacy à l’aide de tests de régression. Cependant, il existe des moyens efficaces pour...
Le Behavior Driven Development (BDD) est une part importante du développement de logiciel agile ou piloté par le comportement. Au lieu d’un langage de programmation déterminé, la technique se base sur une forme textuelle grâce à laquelle des tests automatisés peuvent être conduits ultérieurement. Le BDD permet aux non-développeurs d’utiliser plus facilement des outils complexes qui contrôlent les...
Bien souvent, le fichier readme est la première source d’information pour démarrer un projet, installer un logiciel ou effectuer une mise à jour. Il est particulièrement important pour les développeurs lorsqu’ils intègrent des dépôts publics (comme GitHub) dans leurs projets. Nous vous expliquons ce qui se cache derrière le fichier readme et vous proposons une présentation pour un readme.md.
Dans le développement logiciel, le terme « Cloud Native » est sur toutes les lèvres depuis un certain temps. Mais qu’est-ce que le Cloud Native et comment est-il appliqué avec succès ? La méthode de développement agile vise à développer des applications qui s’intègrent parfaitement dans une infrastructure Cloud. Apprenez-en davantage sur les caractéristiques et les avantages de l’architecture...
Offrez un service performant et fiable à vos clients avec l'hébergement web de IONOS.
Voir les packs
