review-duplication

Duplication des avis

Présentation

Cette compétence propose un workflow structuré permettant d’analyser une base de code lors d’une revue de code afin d’identifier les logiques dupliquées, les utilitaires réinventés et les occasions manquées de réutiliser des modèles établis. En exécutant ce workflow, vous vous assurez que le nouveau code s’intègre parfaitement à l’architecture existante du projet.

Workflow : recherche des doublons

Lors de la révision du code, effectuez les étapes suivantes avant de finaliser votre révision :

1. Extraire la logique métier

Analysez le nouveau code afin d’identifier les algorithmes de base, les fonctions utilitaires, les structures de données génériques ou les composants d’interface utilisateur qui y sont introduits. Ne vous limitez pas à la logique métier spécifique pour cerner les mécanismes sous-jacents.

2. Émettre des hypothèses sur les emplacements existants et tracer les dépendances

Réfléchissez à l’emplacement où ce type de code serait placé s’il existait déjà dans le projet. Indiquez les chemins d’accès absolus à partir de la racine du dépôt pour lever toute ambiguïté.

• Utilitaires : packages/core/src/utils/, packages/cli/src/utils/
• Composants d’interface utilisateur : packages/cli/src/ui/components/, packages/cli/src/ui/
• Services : packages/core/src/services/, packages/cli/src/services/
• Configuration : packages/core/src/config/, packages/cli/src/config/
• Logique centrale : indiquez packages/core/ si la fonctionnalité ne semble pas spécifique à l’interface utilisateur React.

Rechercher les dépendances tierces : si la pull request introduit une nouvelle importation pour une bibliothèque d’utilitaires (par exemple, lodash.merge, date-fns), vérifiez comment et où le projet utilise actuellement cette bibliothèque. Il existe probablement déjà un wrapper ou un utilitaire partagé.

Vérification des fichiers de package : avant de signaler une implémentation personnalisée d’un algorithme complexe, vérifiez le fichier package.json pour voir si une bibliothèque standard (comme lodash ou uuid) fournissant cette fonctionnalité est déjà installée.

3. Analyser la base de code (délégation à des sous-agents)

Confiez le gros du travail d’analyse de la base de code à des sous-agents spécialisés. Ceux-ci sont optimisés pour effectuer des recherches approfondies et des mappages sémantiques sans alourdir l’historique de votre session.

Pour garantir un examen exhaustif, vous DEVEZ formuler des objectifs très précis pour les sous-agents, en leur fournissant les « indices » que vous avez découverts à l’étape 1.

• Codebase Investigator : utilisez codebase_investigator comme chercheur principal. Lors de la délégation, formulez un objectif posant des questions d’investigation spécifiques sur la base de code, en incluant explicitement ces vecteurs de recherche :
  • Similitude structurelle : demandez si le code existant utilise les mêmes API sous-jacentes (par exemple : « Y a-t-il du code existant qui utilise Intl.DateTimeFormat ou setTimeout à des fins similaires ? »).
  • Conventions de nommage : demandez s’il existe des symboles présentant des schémas de nommage similaires (par exemple : « Existe-t-il des symboles dont le nom suit un schéma tel que *Format* ou *Debounce*? »).
  • Commentaires et documentation : demandez si des mots-clés issus des commentaires de la pull request ou du JSDoc existent pour décrire un comportement similaire ailleurs.
  • Adéquation architecturale : demandez où ce type de logique est actuellement centralisé (par exemple : « Où se trouve la logique centralisée de formatage de la date ? »).
  • Conseils de refactorisation : surtout, demandez au sous-agent d’expliquer comment le nouveau code pourrait être refactorisé pour utiliser toute logique existante qu’il identifie.
• Agent généraliste : utilisez l’agent généraliste pour les comparaisons détaillées nécessitant de nombreux itérations. Par exemple : « Examinez l’implémentation de MyNewComponent dans la PR et comparez-la sémantiquement à tous les composants du répertoire packages/ui/src. Existe-t-il des composants existants qui pourraient être étendus ou utilisés à la place ? »
• Conserver le chemin rapide pour les recherches simples : pour les vérifications extrêmement simples et sans ambiguïté (par exemple, « Le fichier package.json inclut-il lodash? »), effectuez une recherche directe pour gagner du temps. Privilégiez la délégation par défaut pour toute « enquête » ouverte.

4. Évaluer les bonnes pratiques

Vérifiez si le nouveau code respecte les conventions établies du projet.

• Gestion des erreurs : utilise-t-il les classes d’erreur ou les mécanismes de journalisation standard du projet ?
• Gestion de l’état : contourne-t-il les magasins ou contextes établis ?
• Style : les couleurs ou les espacements sont-ils codés en dur au lieu d’utiliser les variables de thème ? Si la pull request introduit un nouveau modèle, comparez-le aux normes documentées et vérifiez explicitement si un modèle existant du projet aurait dû être utilisé à la place.

5. Formuler des commentaires constructifs

Si vous constatez que la pull request fait double emploi avec une fonctionnalité existante ou ne respecte pas une bonne pratique :

• Fournissez un commentaire de révision clair.
• Identifiez la source : mentionnez explicitement le chemin d'accès absolu ou relatif au projet, ainsi que l'élément spécifique (fonction, composant, classe) qui devrait être réutilisé.
• Conseils de mise en œuvre : fournissez un bref extrait de code ou une explication claire montrant comment intégrer le code existant pour répondre aux exigences de la tâche.
• Expliquez l’intérêt : expliquez brièvement pourquoi la réutilisation du code existant est bénéfique (par exemple, maintenabilité, cohérence, gestion intégrée des cas limites).

Exemple de commentaire :

« Il semble que cette pull request introduise une nouvelle utilitaire formatDate. Nous disposons déjà d’une fonction formatDate robuste et testée dans src/utils/dateHelpers.ts.

Vous pouvez remplacer votre implémentation en l’important comme suit :

import { formatDate } from '../utils/dateHelpers';// Puis utilisez-la ici :
const displayDate = formatDate(userDate, 'MMM Jeu, AAAA');

La réutilisation de cette fonction garantit que le formatage de la date reste cohérent avec le reste de l’application et gère correctement les conversions de fuseau horaire. »