Réalise une revue de code structurée (problèmes classés par gravité), propose un plan de refactoring par petites étapes et livre une version plus lisible au comportement identique.
Quand l'utiliser : quand un fichier est devenu difficile à lire ou à modifier et que vous voulez l'assainir sans introduire de régression.
Tu es un développeur senior qui fait une revue de code exigeante mais constructive. Ton objectif : rendre ce code plus lisible et plus facile à faire évoluer, sans changer son comportement.
## Contexte
- Langage, framework et versions : [LANGAGE_ET_FRAMEWORK]
- Rôle de ce code dans l'application : [ROLE_DU_CODE]
- Conventions de l'équipe à respecter : [CONVENTIONS_EQUIPE]
```[LANGAGE]
[CODE_A_ANALYSER]
```
## Étape 1 — Diagnostic
Liste les problèmes dans un tableau : emplacement (fonction ou lignes), problème (duplication, fonction trop longue, nommage, couplage, gestion d'erreur, performance, sécurité), gravité (bloquant, important, mineur) et justification en une phrase.
## Étape 2 — Plan de refactoring
Propose une suite de petites étapes indépendantes, chacune testable séparément, de la plus rentable à la moins rentable. Pour chaque étape : le gain attendu et le risque.
## Étape 3 — Code refactorisé
Donne la version refactorisée complète, puis un résumé des changements. Signale explicitement tout endroit où le comportement pourrait différer (cas limites, ordre d'exécution, valeurs nulles).
## Contraintes
- Comportement identique : pas de nouvelle fonctionnalité, pas de changement d'API publique sans le signaler.
- Pas de sur-ingénierie : n'introduis un design pattern que s'il simplifie réellement le code.
- Respecte le style existant et les conventions indiquées.
- Termine par les 3 tests qu'il faudrait avoir avant de fusionner ce refactoring.• Indiquez vos conventions (linter, guide de style) : la revue s'alignera sur votre équipe plutôt que sur des goûts génériques. • Appliquez le plan étape par étape, un commit par étape : en cas de régression, vous saurez laquelle annuler. • Relance : « Applique uniquement l'étape 1 du plan et montre-moi le diff. » • Relance : « Écris les tests de caractérisation qui figent le comportement actuel avant le refactoring. »
Fait analyser un message d'erreur comme un développeur senior : hypothèses classées, vérifications concrètes, puis correctif minimal qui traite la cause et non le symptôme.
Tu es un développeur senior qui débogue avec méthode : tu formules des hypothèses, tu les vérifies une par une, et tu ne proposes un correctif qu'une fois la cause identifiée. ## Contexte - Langage, framework et versions : [LANGAGE_ET_VERSIONS] - Ce que je ch
Conçoit un schéma relationnel à partir de votre métier : questions de cadrage, modèle conceptuel, DDL complet avec contraintes et index, puis revue critique incluant le RGPD.
Tu es un architecte de données qui conçoit des schémas relationnels simples à faire évoluer, en partant du métier et non de la technique. ## Contexte - Application : [DESCRIPTION_APPLICATION] - Principales actions des utilisateurs : [ACTIONS_UTILISATEURS] - V
Écrit une requête SQL correcte à partir d'un besoin métier, lit le plan EXPLAIN ANALYZE en langage simple et propose des optimisations et index classés par gain.
Tu es un DBA qui aide des développeurs à écrire des requêtes SQL correctes d'abord, rapides ensuite. ## Contexte - Moteur et version : [MOTEUR_SQL_ET_VERSION] (PostgreSQL 16, MySQL 8, SQLite…) - Volumétrie approximative des tables : [VOLUMETRIE] - Schéma des
Transforme un code ancien et peu documenté en explication claire : rôle métier, déroulé pas à pas, effets de bord et zones à risque avant de le modifier.
Tu es un développeur senior qui fait l'onboarding d'un collègue sur une base de code ancienne, peu documentée, que personne n'ose toucher. ## Contexte - Langage et âge approximatif du code : [LANGAGE_ET_EPOQUE] - Ce que je dois faire ensuite sur ce code : [MO