Réusinage de code legacy en JavaScript : de A à Z

Introduction : pourquoi le code legacy n'est pas une fatalité

Chaque développeur rencontre tôt ou tard du code legacy en JavaScript. Il peut s'agir de scripts monolithiques sur Node.js, écrits "à la va-vite" il y a 5 ans, ou de fonctions callback complexes que même les développeurs senior hésitent à toucher. Cependant, le réusinage de code legacy n'est pas simplement "tout réécrire", mais un travail systématique d'amélioration de l'architecture sans modifier le comportement externe.

Dans cet article, nous allons détailler un plan étape par étape pour le réusinage en JavaScript (Node.js) : de l'analyse et des tests à l'implémentation de patrons modernes. Vous apprendrez comment transformer en toute sécurité un "bourbier" en code maintenable, en utilisant des exemples concrets.

1. Analyse et cartographie du code legacy

Avant de modifier le code, il faut comprendre son état actuel. Commencez par créer une carte des dépendances et identifier les "points chauds".

1.1. Outils d'analyse

Pour JavaScript/Node.js, utilisez :

• ESLint avec les règles complexity et max-lines — pour détecter les fonctions complexes.
• Plato ou CodeClimate — pour visualiser la complexité cyclomatique.
• Madge — pour construire le graphe des dépendances des modules.

1.2. Identification des "odeurs de code"

Problèmes typiques du JS legacy :

• Fonctions de plus de 100 lignes.
• Variables globales et mutation d'état.
• Callback hell (appels asynchrones imbriqués).
• Absence de modularité (un seul fichier de 2000+ lignes).

// Exemple d'"odeur" : une fonction qui fait tout à la foisfunction processUserData(userId) {    // 100 lignes : validation, requête BDD, formatage, envoi d'email    // ... difficile à tester et à maintenir}

2. Préparation du "filet de sécurité" : les tests

Sans tests, le réusinage est une "roulette russe". Créez des Characterization Tests (tests qui figent le comportement actuel).

2.1. Ajout de tests unitaires

Utilisez Jest ou Mocha. Commencez par les chemins critiques :

// Testons la fonction existante sans la modifierconst { processUserData } = require('./legacy');

describe('processUserData (legacy)', () => {    it('should process user with ID 1', () => {        const result = processUserData(1);        expect(result).toHaveProperty('email');        expect(result.status).toBe('processed');    });});

2.2. Tests d'intégration pour Node.js

Si le code interagit avec une BDD ou une API, utilisez supertest pour les requêtes HTTP :

const request = require('supertest');const app = require('../app');

describe('POST /api/users', () => {    it('should create user (legacy behavior)', async () => {        const res = await request(app)            .post('/api/users')            .send({ name: 'Test' });        expect(res.status).toBe(200);        expect(res.body.id).toBeDefined();    });});

3. Réusinage étape par étape : du monolithe aux modules

Divisons le processus en 3 étapes : isolation, décomposition, optimisation.

3.1. Isolation et enveloppes (Wrapper)

Ne touchez pas à l'intérieur — enveloppez la fonction legacy dans une nouvelle interface :

// Fonction legacyfunction oldFormatDate(date) {    // ... 50 lignes avec mutations    return formattedDate;}

// Nouvelle enveloppefunction formatDateSafe(date) {    if (!(date instanceof Date)) {        throw new Error('Invalid date');    }    return oldFormatDate(date);}

3.2. Décomposition avec Extract Function

Extrayez les blocs logiques dans des fonctions séparées :

// Avant : une fonction de 80 lignesfunction handleOrder(order) {    // 1. Validation    if (!order.id || !order.total) { ... }    // 2. Calcul de la remise