Modèles de prompts pour refactoriser du code

Un prompt de refactorisation sûr indique à un assistant de programmation IA quel comportement préserver, où travailler, quels tests définissent le contrat et comment valider le résultat. « Nettoie ceci » n’est pas un plan de refactorisation. C’est une invitation à modifier des choses que vous n’avez pas examinées.

Utilisez ces modèles comme points de départ. Remplacez les détails entre crochets par des faits issus de votre base de code et demandez une analyse avant une modification étendue.

Modèle : refactorisation sûre

Refactorise [composant/module/fonction] afin d’améliorer [problème de
maintenabilité précis].

Préservation du comportement : conserve [API publique, comportement visible,
événements, gestion des erreurs, accessibilité, caractéristique de performance]
sans modification.

Périmètre : limite les modifications à [fichiers/limite]. Ne modifie pas
[éléments explicitement hors objectif].

Tests : identifie les tests existants qui prouvent le contrat actuel. Ajoute une
couverture de régression ciblée si un comportement protégé n’est pas couvert.

Critères d’acceptation : la duplication ou le couplage est réduit, le
comportement public reste inchangé et le diff ne contient aucun nettoyage sans
rapport.

Validation : exécute [commande de test ciblée], la vérification de types et
[flux manuel]. Avant de modifier, décris le contrat actuel et la plus petite
extraction sûre.

Utilisez ce modèle lorsque vous connaissez l’amélioration recherchée, mais souhaitez protéger une limite stable de la fonctionnalité.

Modèle : extraire un composant

Extrais la [région d’interface] répétée de [composants parents] dans le plus
petit composant réutilisable.

Préservation du comportement : conserve à l’identique les libellés visibles, le
focus clavier, les attributs aria, l’état de chargement, les événements
d’analytique et la mise en page mobile.

Périmètre : uniquement [composants parents], le nouveau composant et les tests
directs. Ne déplace pas la récupération de données ni la responsabilité des
mutations dans le composant extrait.

Tests : préserve ou ajoute des tests pour les états [vide, chargement, erreur,
rempli] et le comportement interactif dont les utilisateurs dépendent.

Critères d’acceptation : les parents utilisent le nouveau composant, le
comportement différent reste explicite et aucune prop publique ni aucun lien ne
change de manière inattendue.

Validation : exécute les tests ciblés du composant, inspecte les états rendus aux
largeurs de bureau et mobile et signale tout comportement qui n’a pas pu être
vérifié.

Analyse les différences existantes avant d’extraire quoi que ce soit.

La phrase sur la responsabilité évite l’erreur fréquente qui consiste à mélanger une extraction visuelle et une réécriture de la gestion de l’état.

Modèle : réduire la duplication

Trouve la logique dupliquée dans [liste de fichiers] et propose la plus petite
abstraction partagée.

Préservation du comportement : préserve le comportement public, les valeurs par
défaut, la gestion des erreurs, la télémétrie et le timing de chaque appelant.

Périmètre : ne généralise pas au-delà de ces appelants. Garde les différences
visibles lorsqu’elles représentent des règles produit plutôt qu’une duplication
accidentelle.

Tests : associe chaque test existant au comportement partagé qu’il protège.
Ajoute un test pour chaque divergence significative.

Critères d’acceptation : la logique répétée n’est centralisée que lorsque le
contrat est réellement le même ; les appelants restent lisibles et équivalents
du point de vue du comportement.

Validation : exécute les tests ciblés des appelants et compare leur sortie
observable avant et après.

Retourne une analyse des différences communes et intentionnelles avant le code.

Du code partagé n’est pas automatiquement meilleur. Un prompt doit amener l’assistant à prouver que le comportement est véritablement partagé.

Modèle : refactorisation des performances

Examine un problème de performance dans [écran/flux de travail].

Preuves : [mesure, trace, minutage, signalement utilisateur ou scénario
reproductible]. Ne suppose pas que [mémoïsation/mise en cache/découpage du code]
est la réponse.

Préservation du comportement : conserve le chargement visible pour l’utilisateur,
la fraîcheur, l’accessibilité, l’autorisation et le comportement des erreurs.

Périmètre : inspecte d’abord [chemins]. N’introduis pas de cache persistant, de
nouvelle bibliothèque d’état ni de dépendance serveur sans besoin mesuré.

Tests : conserve les tests de comportement existants. Ajoute une vérification de
régression ou de mesure uniquement si le projet possède une convention stable
pour cela.

Critères d’acceptation : nomme le goulot d’étranglement, montre une référence et
un résultat, et préserve le comportement protégé.

Validation : exécute les tests pertinents, capture la mesure convenue et
documente les compromis comme la fraîcheur ou la mémoire.

Ce modèle rend l’optimisation guidée par les preuves plutôt que par une technique.

Modèle : refactorisation de code historique

Refactorise [module historique] afin de réduire [risque précis ou coût de
maintenance] sans modifier son comportement observable de l’extérieur.

Préservation du comportement : liste les entrées, sorties, modes d’erreur, effets
de bord, formats de fichier et exigences de compatibilité historiques dont les
clients dépendent.

Périmètre : travaille dans [module/limite]. Ne mets pas à niveau des dépendances
sans rapport et ne réécris pas les appelants dans la même modification.

Tests : caractérise d’abord le comportement actuel avec des tests ou des fixtures
là où la couverture est absente. Inclue les cas limites connus et les entrées mal
formées.

Critères d’acceptation : la nouvelle structure est plus facile à raisonner, le
comportement caractérisé reste stable et les notes de compatibilité sont explicites.

Validation : exécute les tests de caractérisation, les tests d’intégration
existants, la vérification de types et un scénario manuel ou de ligne de commande
représentatif.

Explique le comportement inconnu et le risque avant de proposer une implémentation.

Pour le code historique, un test qui capture un comportement existant maladroit peut avoir plus de valeur qu’une réécriture plus propre en apparence.

Modèle : grande refactorisation

Planifie une refactorisation par étapes de [système] afin d’atteindre
[architecture cible].

Préservation du comportement : maintiens [API publiques, compatibilité des
données, autorisations, flux de travail utilisateur, comportement de déploiement
et chemin de retour arrière].

Périmètre : divise le travail en jalons testables indépendamment. Identifie les
fichiers qui ne doivent pas changer au premier jalon.

Tests : définis les tests ciblés, les tests de contrat, les vérifications de
migration et les flux de travail manuels que chaque jalon doit réussir avant que
le suivant ne commence.

Critères d’acceptation : chaque étape dispose d’une condition d’entrée claire,
d’un résultat observable, d’une stratégie de retour arrière et d’aucune dépendance
cachée envers une étape ultérieure.

Validation : examine le plan par rapport à l’architecture actuelle, exécute les
vérifications de chaque étape et arrête-toi si un jalon invalide l’hypothèse
initiale.

Ne modifie pas le code avant de présenter les étapes, les risques et les alternatives.

Il s’agit d’un prompt de planification, pas d’une demande pour un correctif géant. Il donne aux personnes qui examinent le travail des points de contrôle utiles.

La refactorisation reste du travail produit

Une refactorisation peut casser une interaction, perdre un événement, affaiblir une décision d’autorisation ou traduire incorrectement une chaîne visible par l’utilisateur. Protégez le comportement aussi délibérément que vous améliorez le code.

Utilisez comment écrire de meilleurs prompts d’IA pour la structure de base. Pour des exemples détaillés, lisez des exemples d’ingénierie des prompts pour les ingénieurs logiciels. Si une refactorisation débute à cause d’un incident de production, associez-la aux modèles de prompts pour déboguer des problèmes en production.

Lorsqu’une refactorisation modifie un script, vérifiez d’abord les commandes qu’elle préserve. Exercez-vous aux flux de travail de terminal dans le navigateur afin que la validation repose sur l’entrée et la sortie, et non sur la mémoire.