Simplifier : Revue de code et nettoyage
Passez en revue tous les fichiers modifiés pour la réutilisabilité, la qualité et l'efficacité. Corrigez les problèmes trouvés.
Phase 1 : Identifier les modifications
Exécutez git diff (ou git diff HEAD s'il y a des modifications staged) pour voir ce qui a changé. S'il n'y a pas de modifications git, passez en revue les fichiers les plus récemment modifiés que l'utilisateur a mentionnés ou que vous avez modifiés plus tôt dans cette conversation.
Phase 2 : Lancer trois agents de revue en parallèle
Utilisez l'outil Task pour lancer tous les trois agents simultanément dans un seul message. Passez à chaque agent le diff complet pour qu'il dispose du contexte complet.
Agent 1 : Revue de la réutilisabilité du code
Pour chaque modification :
- Recherchez les utilitaires et assistants existants qui pourraient remplacer le code nouvellement écrit. Cherchez des patterns similaires ailleurs dans la base de code — les emplacements courants sont les répertoires d'utilitaires, les modules partagés et les fichiers adjacents aux fichiers modifiés.
- Signalez toute nouvelle fonction qui duplique une fonctionnalité existante. Suggérez la fonction existante à utiliser à la place.
- Signalez toute logique inline qui pourrait utiliser un utilitaire existant — la manipulation de chaînes de caractères artisanale, la gestion manuelle des chemins, les vérifications d'environnement personnalisées, les gardes de type ad-hoc et les patterns similaires sont des candidats courants.
Agent 2 : Revue de la qualité du code
Passez en revue les mêmes modifications pour les patterns hacky :
- État redondant : état qui duplique un état existant, valeurs en cache qui pourraient être dérivées, observateurs/effets qui pourraient être des appels directs
- Prolifération des paramètres : ajouter de nouveaux paramètres à une fonction au lieu de généraliser ou restructurer les paramètres existants
- Copier-coller avec légère variation : blocs de code quasi-dupliqués qui devraient être unifiés avec une abstraction partagée
- Abstractions qui fuient : exposer des détails internes qui devraient être encapsulés, ou casser les limites d'abstraction existantes
- Code fortement chaîné : utiliser des chaînes brutes là où des constantes, enums (unions de chaînes) ou types marqués existent déjà dans la base de code
- Imbrication JSX inutile : wrapper Boxes/éléments qui n'ajoutent aucune valeur de layout — vérifiez si les props du composant interne (flexShrink, alignItems, etc.) fournissent déjà le comportement requis
Agent 3 : Revue de l'efficacité
Passez en revue les mêmes modifications pour l'efficacité :
- Travail inutile : computations redondantes, lectures de fichiers répétées, appels API/réseau dupliqués, patterns N+1
- Concurrence manquée : opérations indépendantes exécutées séquentiellement alors qu'elles pourraient s'exécuter en parallèle
- Obésité du chemin critique : nouveau travail bloquant ajouté au démarrage ou aux chemins critiques par requête/par rendu
- Mises à jour récurrentes sans effet : mises à jour d'état/store dans les boucles de polling, les intervalles ou les gestionnaires d'événements qui s'exécutent inconditionnellement — ajoutez une garde de détection de changement pour que les consommateurs en aval ne soient pas notifiés quand rien n'a changé. Également : si une fonction wrapper prend un callback updater/reducer, vérifiez qu'elle respecte les retours de même référence (ou quel que soit le signal « pas de changement ») — sinon les sorties anticipées des appelants sont silencieusement défaites
- Vérifications d'existence inutiles : pré-vérifier l'existence d'un fichier/ressource avant d'opérer (anti-pattern TOCTOU) — opérez directement et gérez l'erreur
- Mémoire : structures de données sans limite, nettoyage manquant, fuites d'écouteurs d'événements
- Opérations trop larges : lire des fichiers entiers alors que seule une portion est nécessaire, charger tous les éléments en voulant en filtrer un
Phase 3 : Corriger les problèmes
Attendez que les trois agents se terminent. Agrégez leurs conclusions et corrigez chaque problème directement. Si une conclusion est un faux positif ou ne vaut pas la peine d'être traitée, notez-le et passez — ne discutez pas de la conclusion, contentez-vous de la passer.
Une fois terminé, résumez brièvement ce qui a été corrigé (ou confirmez que le code était déjà propre).