Réusinage de code legacy en C# : guide pas à pas

Introduction : Pourquoi le refactoring du code legacy en C# est une nécessité

Chaque développeur .NET est tôt ou tard confronté à du code legacy. Il ne s'agit pas forcément d'un projet vieux de 20 ans sur .NET Framework 1.1 — souvent, un code devient « legacy » après avoir été écrit dans l'urgence un an plus tôt, sans tests et en violation des principes SOLID. Travailler avec un tel code devient un cauchemar : toute modification casse des fonctionnalités à des endroits inattendus, et la seule façon de comprendre la logique est le débogage.

Le refactoring n'est pas une réécriture complète. C'est une amélioration de la structure interne du code sans modifier son comportement externe. Dans cet article, nous allons analyser des techniques pratiques de refactoring de code legacy en C# que vous pouvez appliquer immédiatement, en minimisant les risques.

1. Préparation : La règle d'or du refactoring

Avant de modifier le code, assurez-vous d'avoir un « filet de sécurité » — un ensemble de tests automatisés. Sans eux, le refactoring devient un jeu de devinettes.

Création de tests de caractérisation

S'il n'y a pas de tests, écrivez des tests de caractérisation (également connus sous le nom de tests golden master ou snapshot). L'idée est simple : exécutez la méthode avec différentes données d'entrée, enregistrez le résultat, puis vérifiez qu'après le refactoring, le résultat n'a pas changé.

// Exemple de test de caractérisation pour une méthode legacy[Test]public void CalculateTotal_ShouldReturnSameResult_AfterRefactoring(){    // Arrange    var order = new Order { Items = new List<Item> { new Item { Price = 100, Quantity = 2 } } };    var expected = 200; // Résultat connu à l'avance

    // Act    var result = LegacyOrderCalculator.CalculateTotal(order);

    // Assert    Assert.AreEqual(expected, result);}

Conseil : Utilisez des bibliothèques comme Verify ou ApprovalTests pour les tests snapshot automatisés.

2. Technique n°1 : Extraction de méthode (Extract Method)

La technique la plus simple et la plus efficace. Lorsque vous voyez une méthode de 200 lignes avec des commentaires comme « // ici calcul de la remise » — c'est un candidat idéal.

Exemple : Grande méthode

public decimal ProcessOrder(Order order){    decimal total = 0;    foreach (var item in order.Items)    {        total += item.Price * item.Quantity;    }

    // Calcul de la remise    if (order.Customer.IsPremium)    {        total *= 0.9m; // 10% de remise    }    else if (order.TotalAmount > 1000)    {        total *= 0.95m; // 5% de remise    }

    // Application de la taxe    total *= 1.2m; // 20% de taxe

    return total;}

Après le refactoring

public decimal ProcessOrder(Order order){    decimal subtotal = CalculateSubtotal(order.Items);    decimal afterDiscount = ApplyDiscount(subtotal, order.Customer);    return ApplyTax(afterDiscount);}

private decimal CalculateSubtotal(IEnumerable<Item> items){    return items.Sum(item => item.Price * item.Quantity);}

private decimal ApplyDiscount(decimal total, Customer customer){    if (customer.IsPremium)        return total * 0.9m;    if (total > 1000)        return total * 0.95m;    return total;}

private decimal ApplyTax(decimal amount){    return amount * 1.2m;}

Avantages :

• Chaque méthode a une seule responsabilité
• Le code devient lisible et testable
• La logique de remise peut être réutilisée ailleurs

3. Technique n°2 : Remplacement de la logique conditionnelle par le polymorphisme

Le code legacy contient souvent de longues chaînes de if-else ou switch. Cela viole le principe d'ouverture/fermeture (OCP).

Exemple : Switch par type de document

public decimal CalculateShippingCost(Order order){    switch (order.ShippingType)    {        case "Standard":            return 5;        case "Express":            return 15;        case "Overnight