Unity Refactor

Unity Refactor

Ce que fait cette skill

Cette skill analyse une codebase Unity C# pour detecter les code smells, propose un plan de refactoring priorise par niveau de risque, puis execute les changements un par un avec verification apres chaque modification. L'objectif est d'ameliorer la qualite du code sans jamais changer le comportement existant.

Prerequis

• Projet Unity avec du code C# existant dans Assets/Scripts/
• Pas de dependance MCP Unity : utilise uniquement Read, Write, Edit, Grep, Glob, Bash

Arbre de decision

Quel type de dette technique ?
|
+-- Code trop long / illisible ?
|   +-- Fichier > 500 lignes --> God class split (risque eleve)
|   +-- Methode > 50 lignes --> Extraction de methodes (risque faible)
|
+-- Couplage fort entre classes ?
|   +-- References directes cross-systeme --> Event Channel SO (risque moyen)
|   +-- Singleton partout --> SO / Service Locator (risque eleve)
|
+-- API obsolete ?
|   +-- Old Input --> New Input System (risque moyen, recette 6)
|   +-- Coroutines --> async Awaitable (risque moyen, recette 4)
|
+-- Code smells generaux ?
    +-- Magic strings --> Constantes / enum (risque faible)
    +-- Champs publics --> [SerializeField] private (risque faible)

Voir le catalogue de refactoring ci-dessous pour les recettes detaillees.

Demarrage rapide

1. Scanner la codebase pour detecter les code smells
2. Classer et prioriser les refactorings par risque
3. Presenter le plan a l'utilisateur
4. Executer UN refactoring a la fois
5. Verifier compilation + references apres chaque changement
6. Repeter jusqu'a completion du plan

Guide etape par etape

Etape 1 : Scanner la codebase pour les code smells

Lancer toutes les detections en parallele avec Grep, Glob et Bash :

Glob : Assets/Scripts/**/*.cs                                    # Tous les fichiers C#
Bash : find Assets/Scripts -name "*.cs" -exec wc -l {} + | sort -rn | head -20  # Fichiers volumineux
Grep : "static\s+\w+\s+Instance" dans Assets/Scripts/**/*.cs    # Singletons
Grep : "void\s+Update\s*\(\)" dans Assets/Scripts/**/*.cs       # Update polling
Grep : "Find\(\"" dans Assets/Scripts/**/*.cs                    # Magic strings (Find)
Grep : "CompareTag\(\"" dans Assets/Scripts/**/*.cs              # Magic strings (Tags)
Grep : "StartCoroutine" dans Assets/Scripts/**/*.cs              # Coroutine spaghetti
Grep : "public\s+(?!void|static|override|class)" dans *.cs      # Champs publics exposes
Grep : "class\s+\w+\s*:\s*\w+" dans Assets/Scripts/**/*.cs      # Heritage (tracer les chaines)

Etape 2 : Classer et prioriser

Utiliser le catalogue de refactoring ci-dessous pour classer chaque smell detecte.

Catalogue de refactoring Unity

Seuils de detection

Ordre de priorite : Faible (magic strings, champs publics, methodes longues) puis Moyen (Update polling, feature envy, God Update) puis Eleve (singletons, God classes, heritage).

Etape 3 : Presenter le plan a l'utilisateur

Avant toute modification, presenter un tableau : # | Fichier | Smell | Refactoring | Risque | Fichiers impactes. Proposer tout / selection / annuler. Attendre la validation avant de commencer.

Etape 4 : Executer UN refactoring a la fois

Pour chaque refactoring du plan valide :

1. Read : Lire le fichier cible completement
2. Grep : Identifier TOUTES les references au code qui va changer
         Grep : "NomClasse" dans Assets/Scripts/**/*.cs
         Grep : "NomMethode" dans Assets/Scripts/**/*.cs
3. Edit : Effectuer le changement (une seule modification atomique)
4. Edit : Mettre a jour toutes les references trouvees
5. Grep : Verifier qu'aucune reference orpheline ne subsiste
6. Passer au refactoring suivant

Etape 5 : Verifier apres chaque changement

Apres chaque refactoring individuel :

1. Grep pour les anciens noms de classes/methodes : doit retourner 0 resultats
2. Grep pour les references cassees : "using.*OldNamespace" absent
3. Verifier coherence : les nouveaux fichiers sont dans le bon dossier
4. Verifier que les [SerializeField] et references Inspector ne sont pas casses

Si un probleme est detecte, annuler le changement et notifier l'utilisateur avant de continuer.

Etape 6 : Repeter jusqu'a completion

Parcourir le plan dans l'ordre de priorite (risque faible en premier). Apres chaque refactoring termine, indiquer la progression :

[2/8] Termine : EnemyController.cs - Extraction de methodes
       Fichiers modifies : 1
       References mises a jour : 0
       Status : OK

Recettes de refactoring

6 recettes detaillees avec code avant/apres dans references/refactor-recipes.md :

Regles strictes

• JAMAIS faire 2 refactorings en meme temps sur le meme fichier
• JAMAIS changer le comportement observable (refactoring != nouvelle feature)
• JAMAIS renommer un champ [SerializeField] sans avertir que les references Inspector seront perdues
• JAMAIS supprimer du code sans verifier toutes les references (Grep dans tout le projet)
• JAMAIS refactorer un fichier sans l'avoir lu completement d'abord
• TOUJOURS verifier la compilation apres chaque changement individuel
• TOUJOURS verifier les references cassees avec Grep apres un renommage
• TOUJOURS presenter le plan complet avant la premiere modification
• TOUJOURS commencer par les refactorings a risque faible
• TOUJOURS preferer le plus petit changement possible
• TOUJOURS utiliser Edit (pas Write) pour les modifications de fichiers existants
• TOUJOURS preserver les attributs Unity ([SerializeField], [Header], [Tooltip], etc.)

Skills connexes

• Generer du nouveau code propre ? Utiliser /unity-code-gen (Unity Code Gen)
• Audit de performance (detection sans refactoring) ? Utiliser /perf-audit (Unity Perf Audit)
• Tester le code apres refactoring ? Utiliser /unity-test (Unity Test)
• Diagnostiquer un bug decouvert pendant le refactoring ? Utiliser /unity-debug (Unity Debug)

Troubleshooting