La dette technique : comment l'identifier et l'éliminer avant qu'elle ne vous coûte cher

Le refactoring est l'art d'améliorer la structure interne du code sans modifier son comportement externe. C'est la clé pour maintenir une base de code saine, réduire la dette technique et conserver une vélocité de développement élevée. Dans ce guide complet, nous explorons les techniques essentielles de refactoring, identifions les mauvaises odeurs de code courantes (code smells), et apprenons comment appliquer ces patterns en utilisant un TypeScript propre.

Pourquoi le Refactoring est Important

La dégradation du code est inévitable. Au fur et à mesure que les exigences changent et que les correctifs rapides s'accumulent, la conception se dégrade. Le refactoring est le processus d'inversion de cette dégradation.

• Lisibilité Améliorée : Le code est lu bien plus souvent qu'il n'est écrit. Le refactoring rend le code auto-documenté.
• Complexité Réduite : Décomposer les grandes fonctions et classes rend le système plus facile à comprendre.
• Prévention des Bugs : Un code propre cache moins de bugs. Les conditions complexes et les effets de bord sont des terrains fertiles pour les erreurs.
• Développement Plus Rapide : Il est plus rapide d'ajouter des fonctionnalités à une base de code propre qu'à une base de code désordonnée.

Mauvaises Odeurs de Code (Code Smells) : Quand Refactorer

Les mauvaises odeurs de code sont des indicateurs de problèmes dans votre code. Ce ne sont pas des bugs, mais ils suggèrent des faiblesses qui peuvent ralentir le développement ou augmenter le risque de bugs ou d'échecs à l'avenir.

1. Les Ballonnements (Bloaters)

Les ballonnements sont des fragments de code, méthodes et classes qui ont pris des proportions telles qu'ils sont difficiles à utiliser.

• Méthode Longue : Une méthode contient trop de lignes de code. En général, toute méthode de plus de 10 lignes devrait vous amener à poser des questions.
• Classe Volumineuse : Une classe contient de nombreux champs/méthodes/lignes de code. Elle essaie généralement de faire trop (Objet Dieu).
• Liste de Paramètres Longue : Plus de trois ou quatre paramètres pour une méthode.

2. Mauvais Usages de l'Orienté Objet

Toutes ces odeurs sont une application incomplète ou incorrecte des principes de la programmation orientée objet.

• Instructions Switch : Vous avez un opérateur switch complexe ou une séquence d'instructions if.
• Héritage Refusé : Une sous-classe utilise seulement une partie des méthodes et propriétés héritées de ses parents.

3. Empêcheurs de Changement

Ces odeurs signifient que si vous devez modifier quelque chose à un endroit dans votre code, vous devez faire de nombreux changements à d'autres endroits également.

• Changement Divergent : Vous vous retrouvez à devoir modifier la même classe de nombreuses façons différentes pour des raisons différentes.
• Chirurgie au Fusil de Chasse (Shotgun Surgery) : Toute modification requiert que vous fassiez de nombreux petits changements dans de nombreuses classes différentes.

Techniques Essentielles de Refactoring

1. Extraire une Méthode (Extract Method)

Problème : Vous avez un fragment de code qui peut être regroupé.

Solution : Déplacez ce code dans une nouvelle méthode (ou fonction) séparée et remplacez l'ancien code par un appel à la méthode.

// Avant
function printOwning(invoice: Invoice): void {
  printBanner();
  let outstanding = calculateOutstanding(invoice);

  // afficher les détails
  console.log("name: " + invoice.customer);
  console.log("amount: " + outstanding);
}

// Après
function printOwning(invoice: Invoice): void {
  printBanner();
  const outstanding = calculateOutstanding(invoice);
  printDetails(invoice, outstanding);
}

function printDetails(invoice: Invoice, outstanding: number): void {
  console.log(`name: ${invoice.customer}`);
  console.log(`amount: ${outstanding}`);
}
    

2. Remplacer le Conditionnel par le Polymorphisme

Problème : Vous avez un conditionnel qui effectue diverses actions selon le type ou les propriétés d'un objet.

Solution : Créez des sous-classes correspondant aux branches du conditionnel.

// Avant
enum BirdType { EUROPEAN, AFRICAN, NORWEGIAN_BLUE }

class Bird {
  constructor(private type: BirdType, private voltage: number, private coconuts: number) {}

  getSpeed(): number {
    switch (this.type) {
      case BirdType.EUROPEAN:
        return this.getBaseSpeed();
      case BirdType.AFRICAN:
        return this.getBaseSpeed() - this.getLoadFactor() * this.coconuts;
      case BirdType.NORWEGIAN_BLUE:
        return (this.voltage > 100) ? 0 : this.getBaseSpeed(this.voltage);
      default:
        throw new Error("Unknown bird type");
    }
  }

  private getBaseSpeed(val?: number): number { return 10; }
  private getLoadFactor(): number { return 1.5; }
}

// Après
abstract class Bird {
  abstract getSpeed(): number;
}

class European extends Bird {
  getSpeed(): number {
    return 10;
  }
}

class African extends Bird {
  constructor(private coconuts: number) { super(); }

  getSpeed(): number {
    return 10 - 1.5 * this.coconuts;
  }
}

class NorwegianBlue extends Bird {
  constructor(private voltage: number) { super(); }

  getSpeed(): number {
    return (this.voltage > 100) ? 0 : 10 + this.voltage;
  }
}
    

3. Introduire un Objet Paramètre

Problème : Vos méthodes contiennent un groupe répétitif de paramètres.

Solution : Remplacez ces paramètres par une interface ou un alias de type.

// Avant
function amountInvoiced(start: Date, end: Date): number { /*...*/ }
function amountReceived(start: Date, end: Date): number { /*...*/ }
function amountOverdue(start: Date, end: Date): number { /*...*/ }

// Après
interface DateRange {
  start: Date;
  end: Date;
}

function amountInvoiced(range: DateRange): number { /*...*/ }
function amountReceived(range: DateRange): number { /*...*/ }
function amountOverdue(range: DateRange): number { /*...*/ }
    

4. Renommer une Méthode

Problème : Le nom d'une méthode n'explique pas ce que la méthode fait.

Solution : Renommez la méthode.

Idéalement, le code devrait se lire comme du français. Si vous avez besoin de commentaires pour expliquer ce que fait une fonction, essayez d'abord de la renommer.

Le Refactoring en Pratique

Dans notre écosystème moderne, ces principes s'appliquent directement à nos outils :

• Composants React : Extraire une Méthode devient "Extraire un Composant".
• Hooks Personnalisés : La logique complexe dans les composants est extraite dans des hooks réutilisables.
• Services NestJS : La logique dans les Contrôleurs est extraite dans les Services sous forme de méthodes.

Conclusion

Le refactoring n'est pas un événement ponctuel ; c'est une habitude. Il devrait faire partie de votre flux de travail quotidien. La Règle du Scout s'applique parfaitement ici : "Laissez toujours le code dans un meilleur état que vous ne l'avez trouvé."