Refactor

Que fait Refactor ?

Quand utiliser

• L'utilisateur demande une refactorisation, restructuration, déplacement de code, division ou fusion de modules, simplification d'interfaces, réécriture progressive, inversion de dépendances, ou suppression de code dupliqué.
• Un changement prétend préserver le comportement tout en modifiant la structure.
• Une refactorisation affecte plusieurs sites d'appel, symboles publics, tests ou frontières de propriété.

Ne pas utiliser quand

• La tâche est une petite correction de bug locale sans changement structurel.
• L'utilisateur demande explicitement un changement de comportement et non une refactorisation préservant le comportement.
• Une revue de conception plus large est nécessaire avant de décider de refactoriser.
• La première étape appropriée est une revue d'ingénierie large car le domaine de risque dominant est encore flou.

Workflow

1. Définir le comportement à préserver et la structure à modifier.
2. Énoncer les non-objectifs : aucun changement de fonctionnalité, aucun changement de compatibilité, aucun changement de sémantique d'erreur, aucune affirmation de performance sauf demande explicite.
3. Inspecter les appelants, tests, docs, configurations, code généré et surfaces publiques affectés par la refactorisation.
4. Ajouter des tests de caractérisation lorsque le comportement est important et que la couverture est faible.
5. Diviser le travail en petites étapes réversibles qui compilent et testent entre des limites significatives.
6. Séparer les déplacements ou renommages mécaniques des modifications sémantiques.
7. Préserver les API publiques sauf si l'utilisateur demande explicitement un changement cassant.
8. Supprimer les anciens chemins seulement après que les appelants sont migrés et que le comportement est vérifié.

Références

• Lire references/refactor-playbook.md avant de planifier une refactorisation en plusieurs étapes.
• Lire references/characterization-tests.md lorsque les tests sont faibles ou que le comportement doit être verrouillé.
• Lire references/review-checklist.md avant de finaliser une refactorisation.

Conditions d'arrêt

• Le comportement préservé n'est pas clair.
• La refactorisation nécessite des changements de comportement larges pour réussir.
• L'API publique, la configuration, le protocole, le stockage, les métriques ou la sémantique des erreurs peuvent changer sans approbation explicite de l'utilisateur.
• Le diff mélange refactorisation, travail de fonctionnalité, optimisation de performance et nettoyage d'une manière qui ne peut pas être revue en toute sécurité.

Règles de sortie

• Signaler quel comportement était destiné à rester inchangé.
• Signaler les changements mécaniques séparément des changements sémantiques.
• Signaler les tests ou vérifications qui protègent le comportement.
• Indiquer tout aspect de comportement, de compatibilité ou de performance non vérifié.