Lab 2.1 : L'Architecte
Module : 2.1 - Plan Mode et Analyse | ← SlidesDurée : 30 minutes Projet Exemple : hackathon-starter
Objectifs d'Apprentissage
À la fin de ce lab, vous serez capable de :
- Utiliser Plan Mode pour une analyse en lecture seule
- Créer des plans de refactoring détaillés avant d'écrire du code
- Identifier les risques et les dépendances dans un changement proposé
- Documenter des stratégies d'implémentation étape par étape
Prérequis
- Labs du Jour 1 terminés
- Projet hackathon-starter configuré
Qu'est-ce que Plan Mode ?
Plan Mode est un mode lecture seule où Claude peut :
- Explorer le codebase
- Analyser les dépendances
- Créer des plans étape par étape
- Identifier les risques
Mais ne peut pas :
- Modifier des fichiers
- Exécuter des commandes (sauf opérations de lecture sécurisées)
- Faire des commits
Quand Utiliser Plan Mode
Utilisez-le quand le changement touchera >3 fichiers ou prendra >1 heure.
Configuration
# Naviguez vers le projet exemple
cd sample-projects/hackathon-starter
# Démarrez Claude en Plan Mode
claude --permission-mode planOu depuis une session existante :
/planTâche 1 : Identifier une Cible de Refactoring
Durée : 5 minutes
Trouvez quelque chose dans le codebase qui nécessite un refactoring.
Prompts à essayer :
Quelles sont les parties les plus complexes ou difficiles à maintenir de ce codebase ?Y a-t-il des "God classes" ou des modules qui font trop de choses ?Quels fichiers ont le plus de lignes de code ?Bons candidats :
- Fichiers contrôleurs volumineux (>300 lignes)
- Modules avec de nombreuses responsabilités
- Fichiers avec une complexité cyclomatique élevée
Critères de réussite :
- [ ] Cible de refactoring identifiée
- [ ] Comprendre pourquoi elle nécessite un refactoring
Tâche 2 : Créer un Plan de Refactoring
Durée : 15 minutes
Demandez à Claude de créer un plan détaillé.
Prompts à essayer :
Crée un plan pour refactorer le contrôleur utilisateur en modules plus petits à responsabilité unique.Quelle serait l'approche la plus sûre pour diviser la configuration passport en stratégies d'authentification séparées ?Comment devrais-je aborder l'extraction de la fonctionnalité email dans un service séparé ?Votre plan devrait inclure :
- Analyse de l'état actuel
- Changements proposés (étape par étape)
- Dépendances à mettre à jour
- Risques potentiels
- Stratégie de test
Critères de réussite :
- [ ] Plan de refactoring en plusieurs étapes reçu
- [ ] Le plan inclut une analyse des dépendances
- [ ] Les risques sont identifiés
Tâche 3 : Affiner le Plan
Durée : 10 minutes
Posez des questions de suivi pour améliorer le plan.
Prompts à essayer :
Qu'est-ce qui casserait si nous faisions l'étape 2 avant l'étape 1 ?Y a-t-il des cas limites que nous devrions gérer ?Quels tests devrions-nous écrire avant de commencer ce refactoring ?Peux-tu décomposer l'étape 3 en sous-étapes plus petites ?Critères de réussite :
- [ ] Le plan a été affiné avec plus de détails
- [ ] Cas limites identifiés
- [ ] La stratégie de test est claire
Exemple de Structure de Plan
Un bon plan de refactoring ressemble à ceci :
# Plan de Refactoring : Diviser UserController
## État Actuel
- UserController gère : auth, profil, paramètres, admin
- 450 lignes, 15 méthodes
- Fort couplage avec passport.js
## Changements Proposés
### Étape 1 : Extraire AuthController
1. Créer controllers/auth.js
2. Déplacer les méthodes login, logout, signup
3. Mettre à jour les imports dans routes/index.js
4. Vérifier que les tests passent
### Étape 2 : Extraire ProfileController
...
## Risques
- La gestion des sessions dépend de l'ordre d'authentification
- Certaines méthodes partagent des helpers privés
## Stratégie de Test
- Exécuter la suite de tests existante après chaque étape
- Ajouter des tests d'intégration pour le flux d'authentificationQuestions Courantes en Plan Mode
| Type de Question | Exemple |
|---|---|
| Portée | « Combien de fichiers cela affectera-t-il ? » |
| Risque | « Qu'est-ce qui pourrait mal tourner ? » |
| Ordre | « Quelle est la séquence la plus sûre ? » |
| Tests | « Quels tests dois-je faire en premier ? » |
| Rollback | « Comment annuler si ça échoue ? » |
Conseils pour Réussir
- Soyez spécifique sur l'objectif - « Améliorer la maintenabilité » est vague ; « Diviser en fichiers de <100 lignes » est spécifique
- Renseignez-vous sur les dépendances - Les changements se propagent ; comprenez le rayon d'impact
- Demandez des stratégies de test - Comment saurez-vous si vous avez cassé quelque chose ?
- Obtenez des estimations de temps - Demandez à Claude combien de temps chaque étape pourrait prendre
Astuce Pro : Les Listes To Do Persistent à Travers la Compaction
Lors de l'utilisation de Plan Mode, demandez explicitement à Claude de créer une liste To Do complète :
Crée une liste To Do complète pour ce plan de refactoring.Pourquoi c'est important :
- Les plans et les listes To Do persistent à travers la compaction du contexte
- Même dans des sessions très longues (50+ minutes), votre liste de tâches reste intacte
- Cela empêche Claude de perdre le fil des changements multi-étapes
TIP
Commencez avec Plan Mode + une liste To Do détaillée pour toute tâche qui prendra plus de 30 minutes.
Livrables
À la fin de ce lab, vous devriez avoir :
- Un plan de refactoring écrit (sauvegardé dans un fichier ou des notes)
- Une compréhension des dépendances et des risques
- Une stratégie de test avant l'implémentation
Prochaines Étapes
Après avoir terminé ce lab, passez au Lab 2.2 : Construction du Filet de Sécurité pour générer des tests avant le refactoring.