Réusinage de code legacy en TypeScript : techniques avancées

Introduction : Pourquoi le code legacy en TypeScript nécessite une approche particulière

Travailler avec du code hérité (legacy) est une réalité inévitable pour tout développeur, en particulier dans les grands projets. Souvent, ce code a été écrit sans typage strict, en utilisant any à tous les coins, et représente un enchevêtrement complexe de dépendances. Un simple réusinage ne fonctionne pas ici – il faut une approche systémique et avancée.

Dans cet article, nous examinerons les stratégies de réusinage de code legacy en TypeScript qui vont au-delà des guides de base. Vous apprendrez comment introduire en toute sécurité un typage strict, isoler les modifications à l'aide de patrons et utiliser les capacités du compilateur pour automatiser les tâches courantes.

Stratégie 1 : Introduction progressive du typage strict via des "ponts de types"

L'un des principaux problèmes du code legacy est l'utilisation généralisée de any. Tenter de remplacer tous les any par des types concrets en une seule fois entraînerait des centaines d'erreurs et paralyserait le développement. Utilisez plutôt la technique des "ponts de types".

Le principe de la méthode : nous ne réécrivons pas tout le module d'un coup, mais créons des types-ponts intermédiaires qui remplacent progressivement any.

Exemple : Typage d'un module "gris"

Supposons que nous ayons un ancien module pour travailler avec les utilisateurs :

// legacyModule.tsexport function processUser(data: any): any {  // ... beaucoup de code illisible  return { id: data.id, name: data.name, age: data.age };}

Au lieu de typer immédiatement toute la fonction, créons UserData et User :

// types.tsexport interface UserData {  id: number;  name: string;  age?: number; // le champ peut être absent}

export interface User {  id: number;  fullName: string;  isAdult: boolean;}

Utilisons maintenant ces types, tout en conservant l'ancienne signature pour la rétrocompatibilité :

// legacyModule.ts (réusinage étape 1)import { UserData, User } from './types';

export function processUser(data: UserData): User {  const isAdult = data.age ? data.age >= 18 : false;  return {    id: data.id,    fullName: data.name,    isAdult,  };}

// Ancienne signature pour la compatibilitéexport function processUserLegacy(data: any): any {  return processUser(data as UserData);}

Une fois que tous les consommateurs sont passés à la nouvelle fonction, supprimez processUserLegacy. Cette approche minimise le risque de casser les dépendances.

Stratégie 2 : Isolation des dépendances "sales" avec le patron "Adaptateur"

Le code legacy est souvent étroitement lié à des bibliothèques externes, des états globaux ou des API obsolètes. Pour effectuer un réusinage en toute sécurité, il faut isoler ces dépendances. Le meilleur outil pour cela est le patron "Adaptateur" combiné avec des interfaces.

Exemple : Isolation d'une API obsolète

// oldApi.ts (legacy)export function fetchOldData(callback: (data: any) => void): void {  // ancienne API avec callbacks  setTimeout(() => callback({ value: 42 }), 100);}

Créons une interface pour la nouvelle approche (basée sur les Promesses) et un adaptateur :

// apiAdapter.tsimport { fetchOldData } from './oldApi';

export interface IDataFetcher {  fetchData(): Promise<{ value: number }>;}

export class LegacyApiAdapter implements IDataFetcher {  fetchData(): Promise<{ value: number }> {    return new Promise((resolve, reject) => {      fetchOldData((data) => {        if (data) {          resolve(data);        } else {          reject(new Error('Pas de données'));        }      });    });  }}

Désormais, tout le nouveau code utilise IDataFetcher. Lorsque vous réécrirez complètement l'ancienne API, il vous suffira de remplacer l'implémentation de l'adaptateur, sans toucher au reste du code. Cela réduit le risque de régression au minimum.

Stratégie 3 :