Refactoring intelligent avec Codex

Introduction

Imaginez une maison ancienne. Vous refaites entièrement l'électricité, la plomberie et l'isolation. Depuis la rue, la façade n'a pas changé d'un millimètre. Les passants ne remarquent rien. Mais pour ceux qui y vivent, le confort est incomparable et les risques d'incendie ont disparu.

Le refactoring suit exactement le même principe en programmation. C'est l'art d'améliorer la structure interne d'une application sans en modifier l'apparence ou les fonctionnalités pour l'utilisateur.

Beaucoup de débutants pensent qu'un bon développeur passe 100% de son temps à créer de nouvelles choses. C'est faux. Il passe près de la moitié de son temps à nettoyer et améliorer ce qu'il a déjà écrit. Avec Codex, cette étape parfois fastidieuse devient un jeu d'enfant.

Qu'est-ce que le refactoring ?

C'est la réécriture d'un code source pour le rendre plus simple, plus lisible, et plus facile à maintenir, sans ajouter de nouvelles fonctionnalités ni modifier son comportement.

Pourquoi refactoriser un projet ?

En programmation, le code qui fonctionne s'appelle le code. Le code qui est moche s'appelle la "Dette Technique". Plus vous accumulez de dette technique, plus les intérêts coûtent cher, c'est-à-dire que la moindre modification vous prendra des heures au lieu de quelques minutes.

Les signes qu'un projet a besoin d'un refactoring

Voici la checklist des mauvaises odeurs (Code Smells) qui doivent vous alerter :

• [ ] La fonction "Dieu" : Une fonction fait 150 lignes et calcule tout, vérifie tout et affiche tout en même temps.
• [ ] Le syndrome x, y, z : Des variables nommées a, data1, valeur2. Personne ne sait ce qu'elles contiennent.
• [ ] Le Copier-Coller : Vous avez copié exactement le même code de bouton sur 4 pages différentes. S'il faut changer la couleur, il faut le faire 4 fois.
• [ ] Le fichier Monolithe : Votre script.js atteint les 1000 lignes.
• [ ] La pyramide infernale : Vous avez 5 niveaux de conditions "If" imbriqués les uns dans les autres.

Demander un refactoring à Codex (Exemples de Prompts)

La règle d'or d'un prompt de refactoring est d'exiger explicitement le maintien du comportement exact de l'application.

D'autres prompts redoutables :

• "Découpe ce composant de 300 lignes en 3 sous-composants plus petits."
• "Mets à jour la syntaxe de ce vieux fichier vers du JavaScript moderne (ES6+)."
• "Remplace cette série de conditions `if/else if` par un `switch` beaucoup plus lisible."
• "Sépare tout le HTML de la logique JavaScript."
• "Renomme toutes les variables pour qu'elles suivent la convention camelCase (monExemple)."

Le Refactoring Progressif (Ne cassez pas la baraque)

Demander à Codex "Refactorise tout le projet" est le meilleur moyen de tout détruire. Suivez le cycle des professionnels :

graph LR;
    A[Git Commit] --> B[Choix d'une fonction];
    B --> C[Codex nettoie la fonction];
    C --> D[Vérification sur le site];
    D --> E[Git Commit 'Refacto OK'];
    E --> F[Fonction suivante];

Exemple de scénario catastrophe :
Vous lui donnez 15 fichiers. Il renomme des variables, supprime 3 fonctions, et regroupe le tout. Votre site affiche une erreur critique. Vous ne saurez jamais lequel des 15 fichiers a provoqué l'erreur.

Les différents types de refactoring

1. Refactoring CSS

Objectif : Alléger le fichier de styles, supprimer le code mort, regrouper les classes.
Exemple : Fusionner .btn-rouge et .btn-bleu en un seul .btn et utiliser des modificateurs.
Prompt : "Analyse ce fichier CSS et rassemble toutes les propriétés de marge qui sont redondantes."

2. Refactoring HTML (Sémantique)

Objectif : Rendre le code compréhensible pour les moteurs de recherche (SEO) et les lecteurs d'écran.
Exemple : Remplacer une "soupe" de <div> par des <header>, <main>, <article>.
Prompt : "Améliore l'accessibilité sémantique de ce fichier HTML sans changer la structure visuelle ni les classes CSS."

3. Refactoring de l'Arborescence

Objectif : Ranger les dossiers de votre ordinateur.
Exemple : Placer toutes les images dans /public/img/, tout le code dans /src/.
Prompt : "Je veux réorganiser mon projet. Où devrais-je ranger mes fichiers CSS et JS pour suivre les standards actuels ?"

Améliorer les performances sans modifier les fonctionnalités

Le refactoring, c'est aussi alléger le moteur.

• Optimisation des boucles : Si une liste parcourt 10 000 éléments, demandez à Codex si la méthode `reduce` ou `filter` serait plus rapide que votre vieille boucle `for`.
• Suppression du code mort (Dead Code) : Avec les mois, on oublie des morceaux de code obsolètes. "Cherche les fonctions déclarées dans ce fichier qui ne sont appelées nulle part."
• Factorisation : Au lieu de charger une fonction complexe sur 3 pages différentes, mettez-la dans un fichier utilitaire `utils.js` importé proprement.

Renommer intelligemment : Le super-pouvoir caché

S'il ne fallait faire qu'un seul refactoring, ce serait celui du nommage. Le nom d'une variable doit être une documentation à lui tout seul.

let t = d * 1.2; if(u.stat == 1) { f(t); }

let prixTTC = prixHT * TAUX_TVA; if (utilisateur.isActif) { appliquerReduction(prixTTC); }

Prompt : "Renomme toutes les variables de cette fonction pour que leur utilité métier soit évidente au premier coup d'œil."

Les erreurs les plus fréquentes en refactoring

• Symptôme : "J'ai voulu nettoyer et maintenant le panier ne marche plus."
  Cause : Vous avez demandé d'ajouter une fonctionnalité EN MÊME TEMPS que le refactoring.
  Bonne pratique : Le refactoring ne s'accompagne jamais de nouvelles fonctionnalités. C'est l'un ou l'autre.
• Symptôme : L'IA renomme les classes CSS dans le CSS, mais pas dans le HTML.
  Cause : Manque de contexte.
  Bonne pratique : Exigez : "Renomme la classe dans le fichier CSS, et donne-moi la commande pour la remplacer partout dans les fichiers HTML."
• Symptôme : Le code est propre, mais vous avez des doutes sur son fonctionnement.
  Cause : Vous n'avez pas testé l'application après le nettoyage.
  Bonne pratique : Test manuel exhaustif (ou test automatisé) obligatoire après un refactoring.
• Symptôme : Vous ne pouvez plus revenir en arrière.
  Cause : Vous n'avez pas fait de commit Git avant de commencer à nettoyer.
  Bonne pratique : git commit -m "Avant le grand nettoyage du composant Header".

Atelier pratique

Conseils vitaux

Tableau récapitulatif des stratégies

Foire aux questions

À retenir

Transition vers le chapitre suivant

Refactoriser, c'est bien. Mais comment être absolument certain à 100% que votre nettoyage ou vos nouvelles fonctionnalités n'ont causé aucun bug caché dans les coins sombres de l'application ?

C'est ici qu'entre en jeu l'art des tests. Dans le prochain chapitre, nous allons voir comment utiliser Codex pour valider le code, s'assurer que tout fonctionne dans toutes les situations, et automatiser ces vérifications.