Retour de conférence d’Adrien Joly du DevFest de Nantes 2022
Qu’est-ce que le Code Legacy ?
Il s’agit d’un code qui apporte de la valeur, mais qui fait peur quand il faut le changer.
Un des symptômes du code Legacy est qu’il comporte des « code smell ». Un « code smell » est une indication visible dans le code reflétant des problèmes plus profonds. Par exemple, une imbrication de code, une duplication de fonction, un nommage mystérieux, ou autre…
Cela est en lien avec la dette technique. Celle-ci est un effort de refactoring (changer la structure du code, sans changer la fonctionnalité) nécessaire pour ajouter des nouvelles fonctionnalités de manière non-invasive.
1er exemple de refactoring : La duplication de code
Le problème est que plus le code est dupliqué, plus nous devons changer le code dans différents endroits.
Pour éviter de devoir changer de façon manuelle tous les codes, il faut extraire la fonction choisie et encapsuler le code pour n’avoir qu’un endroit où modifier ce code.
Il faut toutefois être vigilant et valider qu’avant et après cette modification, notre action reste identique. La mise en place de test de non-régression est donc importante.
Après l’extraction de fonction et la réalisation des tests validés, nous pouvons faire un commit pour approuver le nouvel état stable. L’application est donc toujours fonctionnelle et le comportement est iso-prod.
2ème exemple de refactoring : Le code commenté
Le code commenté est un frein à sa bonne lecture et ne sert à rien (ou très peu). Il est préférable de les enlever afin d’améliorer la lisibilité, d’alléger le code et de faciliter le travail des développeurs. Si nous voulons récupérer du code déjà supprimé, il suffit d’utiliser les outils de versionning.
Comme dans le 1er exemple, quand les tests sont validés et l’état est stable, nous pouvons envoyer les changements sur le gestionnaire de version.
3ème exemple de refactoring : Réduire la taille des fichiers
Quand des fichiers de code où des modules JS sont trop longs, ceux-ci sont complexes à lire. Ils empêchent la bonne compréhension des actions.
Afin de les simplifier, il est possible de les segmenter en plusieurs petits modules avec des domaines fonctionnels propres pour que chacun ait sa responsabilité. Cette action permet de rendre les codes plus compréhensibles et agréables à lire. Elle va également permettre de nettoyer le fichier principal en supprimant les imports inutiles et les constantes inutilisées.
4ème exemple de refactoring : Transformer les callbacks en Promise
Il est parfois, même souvent, compliqué de faire évoluer une application vieille dont le code JS a évolué. Dans ce genre d’application, il y a souvent des callbacks qui sont beaucoup utilisés. Dans ce cas, il est intéressant de transformer les callbacks en promesses. Cela facilite la lecture du code et aide à la compréhension de toutes les actions qui étaient enchaînées lorsqu’une action était faite par l’utilisateur.
Dans l’intervention d’Adrien Joly, il a mis en scène 6 fonctions qui s’enchaînaient les unes après les autres. Mais avec les callbacks, nous ne voyons pas ce qu’il se passait.
Alors qu’en créant des promesses, les unes à la suite des autres, nous créons une procédure mieux structurée et plus compréhensible.
Quand nous sommes amenés à reprendre une application comprenant du code legacy, il est important de commencer par bien définir le périmètre sur lequel nous allons agir. Bien mettre en place des tests afin de s’assurer qu’il n’y ait pas de régressions entre avant et après notre action.
Il est possible de cartographier les flux (enchaînement des actions faites à l’intérieur du code). Cela peut par exemple se traduire sous la forme d’un diagramme de séquence.
Supprimer les codes non–utiles et/ou morts.
Ces actions de refactoring permettent de faciliter les modifications demandées.
Enfin, il est préférable de faires ces étapes les unes après les autres, et de bien les finaliser avant de créer une nouvelle action. Cela semble logique, mais il est parfois bon de le rappeler pour garder un état stable de l’application.
Pour plus d’informations, vous pouvez allez-vous la conférence d’Adrien le Joly en cliquant ICI.
Ou lire son article, en cliquant ICI.
Et si vous souhaitez plus d’explications sur les callbacks en promise, cliquez ICI.
