Lab 2.4 : Amélioration Incrémentale

Module : 2.4 - Refactoring Sécurisé | ← SlidesDurée : 1 heure Projet Exemple : node-express-mongoose-demo

Objectifs d'Apprentissage

À la fin de ce lab, vous serez capable de :

• Refactoriser du code en toute sécurité avec vérification par les tests
• Effectuer des changements incrémentaux (petites étapes)
• Améliorer la lisibilité sans changer le comportement
• Utiliser les tests comme filet de sécurité

Prérequis

• Labs 2.2 et 2.3 complétés
• Tests en place pour le code que vous allez refactoriser
• Confiance dans l'exécution de la suite de tests

Le Workflow de Refactoring Sécurisé

1. Vérifier que les tests passent (baseline)
2. Faire un petit changement
3. Lancer les tests
4. Si vert : commit et continuer
5. Si rouge : annuler et réessayer

Configuration

# Naviguer vers le projet exemple
cd sample-projects/node-express-mongoose-demo

# Vérifier que les tests passent AVANT de commencer
npm test

# Démarrer Claude Code
claude

---

Tâche 1 : Identifier les Code Smells

Durée : 10 minutes

Trouver du code qui nécessite des améliorations.

Prompts à essayer :

What code smells exist in app/controllers/articles.js?

Are there any functions with too many responsibilities?

Find examples of duplicated code in this project.

Code smells courants :

• Méthodes longues (>20 lignes)
• Code dupliqué
• Noms peu explicites
• Imbrication profonde
• Nombres/chaînes magiques

Critères de réussite :

• [ ] 2-3 code smells identifiés
• [ ] Un sélectionné pour correction

---

Tâche 2 : Refactoriser pour la Lisibilité

Durée : 15 minutes

Améliorer les noms de variables et de fonctions.

Étape 1 : Lancer les tests (baseline)

npm test

Étape 2 : Améliorer le nommage

Rename the variables in this function to be more descriptive. Don't change any behavior.

The function name 'proc' is unclear. Suggest a better name and rename it throughout the codebase.

Étape 3 : Vérifier que les tests passent

npm test

Critères de réussite :

• [ ] Les noms sont plus clairs
• [ ] Les tests passent toujours
• [ ] Comportement inchangé

---

Tâche 3 : Extraire des Fonctions Auxiliaires

Durée : 20 minutes

Décomposer les fonctions complexes.

Étape 1 : Identifier les opportunités d'extraction

This function is too long. What parts could be extracted into separate functions?

Étape 2 : Extraire une partie

Extract the [specific logic] into a separate helper function.

Étape 3 : Lancer les tests

npm test

Étape 4 : Répéter pour les autres parties

Critères de réussite :

• [ ] Au moins une fonction extraite
• [ ] Les tests passent après chaque extraction
• [ ] La fonction principale est maintenant plus courte

---

Tâche 4 : Supprimer la Duplication

Durée : 15 minutes

Appliquer le principe DRY au code.

Étape 1 : Trouver la duplication

Find duplicated code between the create and update functions.

Étape 2 : Extraire la logique partagée

Extract the common validation logic into a shared function used by both create and update.

Étape 3 : Vérifier

npm test

Critères de réussite :

• [ ] Duplication supprimée
• [ ] Fonction partagée créée
• [ ] Les tests passent

---

Techniques de Refactoring

Technique	Quand l'Utiliser	Exemple
Renommer	Noms peu clairs	x → userId
Extraire Fonction	Méthodes longues	Extraire 10 lignes dans un helper
Inliner	Sur-abstraction	Supprimer un wrapper inutile
Déplacer	Mauvais emplacement	Déplacer un utilitaire du contrôleur vers utils/
Remplacer Magique	Valeurs en dur	86400 → SECONDS_PER_DAY

---

La Règle d'Or

Rappel

"Le refactoring, c'est modifier le code sans changer son comportement."

Après chaque modification :

1. Lancer les tests
2. S'ils passent, vous êtes en sécurité
3. S'ils échouent, vous avez changé le comportement (annulez !)

---

Stratégie de Commit

Commiter après chaque refactoring réussi :

# Après chaque test au vert
git add .
git commit -m "Refactor: Extract validation helper from article controller"

Petits commits = retour arrière facile si quelque chose se passe mal.

---

Conseils pour Réussir

1. Un changement à la fois - Ne pas combiner les refactorings
2. Lancer les tests constamment - Après chaque modification
3. Commiter fréquemment - Sauvegarder votre progression
4. Garder le comportement identique - Si les tests échouent, vous êtes allé trop loin

---

Prompts de Refactoring Courants

Rename this variable to something more descriptive.

Extract the loop body into a separate function.

Replace this magic number with a named constant.

Simplify this nested if-else into an early return pattern.

---

Signaux d'Alerte (Arrêter le Refactoring)

• Les tests commencent à échouer de manière inattendue
• Vous ajoutez de nouvelles fonctionnalités (ce n'est pas du refactoring)
• Les changements deviennent trop importants à suivre
• Vous refactorisez depuis >30 min sans commiter

---

Objectifs Bonus

Si vous finissez en avance :

1. Refactoriser des conditionnels profondément imbriqués en clauses de garde
2. Extraire un objet de configuration à partir de valeurs magiques dispersées
3. Améliorer la cohérence de la gestion des erreurs

---

Livrables

À la fin de ce lab, vous devriez avoir :

1. Un code plus propre et plus lisible
2. Des fonctions plus petites et ciblées
3. Une duplication réduite
4. Tous les tests qui passent toujours
5. Un historique de commits propre montrant les changements incrémentaux

---

Prochaines Étapes

Après avoir complété ce lab, passez au Lab 2.7 : Mini-Projet de Modernisation - le projet final du Jour 2.