Réusinage de code legacy en Java : guide étape par étape

Réfactorisation de code legacy en Java : guide étape par étape

Travailler avec du code legacy en Java est l'une des tâches les plus fréquentes et complexes auxquelles les développeurs sont confrontés. Souvent, ce code n'a pas de tests, est écrit dans un style monolithique et contient de nombreux anti-patrons. Cependant, réécrire entièrement le système est coûteux et risqué. Il est bien plus efficace d'appliquer une refactorisation méthodique. Dans cet article, nous allons détailler une approche pratique de la refactorisation du code Java legacy, qui permettra de le rendre plus propre, plus sûr et plus maintenable.

1. Préparation : analyse et création d'un "filet de sécurité"

Avant de modifier le code, il est nécessaire de comprendre ce qu'il fait et comment ne pas casser la logique existante. Le principe principal de la refactorisation du code legacy est de ne pas modifier le comportement. Pour cela, nous devons créer un "filet de sécurité" — un ensemble de tests.

Commencez par étudier le code. Trouvez les points d'entrée (les méthodes appelées depuis l'extérieur) et essayez de déterminer les résultats attendus. Même si le code est mal écrit, il fait quelque chose de correct.

Après l'analyse, écrivez des tests de caractérisation (Characterization Tests). Ce sont des tests qui figent le comportement actuel du code. Ils ne vérifient pas si la logique fonctionne correctement, mais documentent simplement ce qui se passe actuellement.

Exemple : nous avons une classe monstre qui traite les commandes.

public class OrderProcessor {    public void process(Order order) {        // 200 lignes de code spaghetti        if (order.getTotal() > 100) {            order.setStatus("VIP");        } else {            order.setStatus("STANDARD");        }        // ... beaucoup d'autre logique    }}

Nous ne savons pas ce qu'il y a à l'intérieur, mais nous pouvons écrire un test :

@Testpublic void testProcessOrderWithHighTotal() {    // Given    Order order = new Order();    order.setTotal(150);    OrderProcessor processor = new OrderProcessor();

    // When    processor.process(order);

    // Then (on fige le comportement actuel)    assertEquals("VIP", order.getStatus());}

Exécutez les tests. S'ils passent, vous avez figé le comportement actuel. Vous avez maintenant une protection contre la régression.

2. Extraction de méthode (Extract Method)

La refactorisation la plus sûre et la plus efficace pour les grandes méthodes. Le principe est simple : prenez un fragment de code qui fait une seule chose et extrayez-le dans une méthode séparée avec un nom explicite.

Considérons un exemple de mauvais code :

public double calculateEmployeePay(Employee emp) {    double basePay = emp.getBasePay();    double overtimePay = 0;    if (emp.getHoursWorked() > 40) {        overtimePay = (emp.getHoursWorked() - 40) * basePay * 1.5;    }    double tax = basePay * 0.13;    double insurance = 5000;    return basePay + overtimePay - tax - insurance;}

Ici, le calcul des heures supplémentaires, des impôts et de l'assurance sont mélangés. Séparons-les :

public double calculateEmployeePay(Employee emp) {    double basePay = emp.getBasePay();    double overtimePay = calculateOvertimePay(emp, basePay);    double tax = calculateTax(basePay);    double insurance = getInsuranceCost();    return basePay + overtimePay - tax - insurance;}

private double calculateOvertimePay(Employee emp, double basePay) {    if (emp.getHoursWorked() > 40) {        return (emp.getHoursWorked() - 40) * basePay * 1.5;    }    return 0;}

private double calculateTax(double basePay) {    return basePay * 0.13;}

private double getInsuranceCost() {    return 5000;}

Maintenant, chaque méthode est responsable d'une seule tâche. Le code est devenu plus lisible et plus facile à tester individuellement.

3. Suppression des duplications (DRY)

Le code legacy souffre souvent de copier-coller. Le même morceau de logique peut apparaître dans différentes classes. C'est dangereux : lors d'un changement d'exigences, vous pourriez oublier de corriger l'un des doublons.

Supposons que dans deux services différents