Refactoring : améliorer son code sans casser les fonctionnalités

Le refactoring est l'art d'améliorer la structure interne du code sans modifier son comportement externe. C'est une pratique essentielle pour maintenir un code sain sur le long terme. Comme le dit Martin Fowler, le père du refactoring : "Toute fois que tu ressens le besoin d'écrire un commentaire, essaie d'abord de refactorer le code pour le rendre auto-documenté."

Quand refactoriser ?

Refactorisez avant d'ajouter une fonctionnalité (pour la rendre plus simple à ajouter), après l'avoir ajoutée (pour nettoyer), et lors d'une revue de code. La règle des trois : la première fois, faites-le fonctionner. La deuxième fois, notez la duplication. La troisième fois, refactorisez.

Les "code smells" qui signalent le besoin de refactoring : fonctions de plus de 20 lignes, classes de plus de 200 lignes, duplication de code, commentaires expliquant le quoi (et non le pourquoi), paramètres en trop grand nombre.

Extract Method : la technique la plus utile

Extraire un bloc de code en méthode nommée améliore la lisibilité :

// Avant refactoring
public function processOrder(array $order): void {
    // Validation
    if (empty($order['items'])) throw new Exception('Commande vide');
    if ($order['total'] <= 0) throw new Exception('Total invalide');

    // Calcul taxes
    $taxes = $order['total'] * 0.2;
    $total = $order['total'] + $taxes;

    // Sauvegarde
    $this->db->insert('orders', [...]);
    $this->mailer->sendConfirmation($order['email'], $total);
}

// Après refactoring
public function processOrder(array $order): void {
    $this->validateOrder($order);
    $total = $this->calculateTotal($order);
    $this->saveOrder($order, $total);
    $this->notifyCustomer($order['email'], $total);
}

Rename : nommer pour clarifier

Le renommage est le refactoring le plus fréquent et souvent le plus impactant :

// Avant
function calc(array $d, int $t): float {
    return array_sum(array_column($d, 'p')) * (1 + $t/100);
}

// Après refactoring
function calculateTotalWithTax(array $orderItems, int $taxRate): float {
    $subtotal = array_sum(array_column($orderItems, 'price'));
    return $subtotal * (1 + $taxRate / 100);
}

Decompose Conditional

Les conditions complexes se lisent mieux extraites en méthodes nommées :

// Avant
if ($order['status'] === 'pending' && $order['total'] > 1000
    && $user['verified'] && !$user['blacklisted']) {
    $this->applyDiscount($order);
}

// Après refactoring
if ($this->isEligibleForDiscount($order, $user)) {
    $this->applyDiscount($order);
}

private function isEligibleForDiscount(array $order, array $user): bool {
    return $order['status'] === 'pending'
        && $order['total'] > 1000
        && $user['verified']
        && !$user['blacklisted'];
}

Replace Magic Number with Named Constant

// Avant
if ($password_length < 8) { ... }
$ttl = 86400;

// Après refactoring
const MIN_PASSWORD_LENGTH = 8;
const SESSION_TTL_SECONDS = 86400; // 24 heures

if (strlen($password) < self::MIN_PASSWORD_LENGTH) { ... }

Stratégie de refactoring sécurisée

La règle d'or : ne refactorisez jamais sans tests. Les tests unitaires sont votre filet de sécurité qui garantit que le refactoring ne casse rien. Procédez par petites étapes : un refactoring à la fois, commit, vérification que les tests passent.

Pour une analyse automatique des code smells PHP, PHP Mess Detector (phpmd) et PHP CodeSniffer scannent votre code et suggèrent des améliorations.

Conclusion

Le refactoring continu maintient la dette technique sous contrôle. Sans lui, le code se dégrade progressivement jusqu'à devenir impossible à maintenir. Intégrez le refactoring dans votre routine quotidienne : chaque PR doit laisser le code un peu plus propre qu'elle ne l'a trouvé.

Le refactoring efficace repose sur deux piliers : des tests automatisés comme filet de sécurité, et des petits pas incrémentaux plutôt que des réécritures totales. Le livre "Refactoring" de Martin Fowler catalogue 66 techniques avec des exemples concrets. En pratique, commencez par les "smells" les plus impactants : classes trop grandes, méthodes trop longues, et duplications. Les outils SonarQube ou PHPStan détectent automatiquement les problèmes structurels. Planifiez du temps de refactoring régulier dans vos sprints — la règle du Boy Scout (laisser le code plus propre qu'avant) suffit à maintenir une codebase saine sur le long terme. Consultez Refactoring.Guru pour des explications visuelles claires et des exemples détaillés.