review-duplication

Überprüfung auf Duplikate

Übersicht

Diese Funktion bietet einen strukturierten Workflow zur Untersuchung einer Codebasis während einer Codeüberprüfung, um doppelte Logik, neu entwickelte Hilfsfunktionen und verpasste Möglichkeiten zur Wiederverwendung etablierter Muster zu identifizieren. Durch die Ausführung dieses Workflows stellen Sie sicher, dass sich neuer Code nahtlos in die bestehende Projektarchitektur einfügt.

Workflow: Überprüfung auf Duplikate

Führen Sie bei der Codeüberprüfung die folgenden Schritte durch, bevor Sie Ihre Überprüfung abschließen:

1. Kernlogik extrahieren

Analysieren Sie den neuen Code, um die Kernalgorithmen, Hilfsfunktionen, generischen Datenstrukturen oder UI-Komponenten zu identifizieren, die eingeführt werden. Schauen Sie über die spezifische Geschäftslogik hinaus, um die zugrunde liegenden Mechanismen zu erkennen.

2. Hypothesen zu bestehenden Standorten aufstellen und Abhängigkeiten nachverfolgen

Überlegen Sie, wo diese Art von Code angesiedelt wäre, wenn er bereits im Projekt vorhanden wäre. Geben Sie zur eindeutigen Zuordnung absolute Pfade vom Repo-Stammverzeichnis an.

• Hilfsfunktionen: packages/core/src/utils/, packages/cli/src/utils/
• UI-Komponenten: packages/cli/src/ui/components/, packages/cli/src/ui/
• Dienste: packages/core/src/services/, packages/cli/src/services/
• Konfiguration: packages/core/src/config/, packages/cli/src/config/
• Kernlogik: Geben Sie „packages/core/“ an, wenn die Funktionalität nicht spezifisch für die React-Benutzeroberfläche zu sein scheint.

Abhängigkeiten von Drittanbietern nachverfolgen: Wenn der PR einen neuen Import für eine Hilfsbibliothek einführt (z. B. `lodash.merge`, `date-fns`), verfolgen Sie nach, wie und wo das Projekt diese Bibliothek derzeit verwendet. Wahrscheinlich gibt es bereits einen Wrapper oder eine gemeinsam genutzte Hilfsfunktion.

Paketdateien prüfen: Bevor Sie eine benutzerdefinierte Implementierung eines komplexen Algorithmus vorschlagen, prüfen Sie in „package.json“, ob bereits eine Standardbibliothek (wie „lodash“ oder „uuid“) installiert ist, die diese Funktionalität bereitstellt.

3. Untersuchung der Codebasis (Delegierung an Unteragenten)

Delegieren Sie die aufwendige Untersuchung der Codebasis an spezialisierte Unteragenten. Diese sind darauf optimiert, tiefgehende Suchen und semantische Zuordnungen durchzuführen, ohne Ihren Sitzungsverlauf zu überladen.

Um eine umfassende Überprüfung zu gewährleisten, MÜSSEN Sie hochspezifische Ziele für die Unteragenten formulieren und ihnen die „Hinweise“ zur Verfügung stellen, die Sie in Schritt 1 entdeckt haben.

• Codebase Investigator: Setzen Sie den „codebase_investigator“ als Ihren primären Ermittler ein. Formulieren Sie bei der Delegierung ein Ziel, das spezifische, ermittlungsorientierte Fragen zur Codebasis stellt und dabei ausdrücklich folgende Suchvektoren einbezieht:
  • Strukturelle Ähnlichkeit: Fragen Sie, ob bestehender Code dieselben zugrunde liegenden APIs verwendet (z. B. „Verwendet bestehender Code Intl.DateTimeFormat oder setTimeout für ähnliche Zwecke?“).
  • Namenskonventionen: Fragen Sie, ob es bereits Symbole mit ähnlichen Namensmustern gibt (z. B. „Gibt es bereits Symbole mit Namensmustern wie *Format* oder *Debounce*?“).
  • Kommentare und Dokumentation: Fragen Sie, ob Schlüsselwörter aus den Kommentaren des Pull-Requests oder aus JSDocs an anderer Stelle zur Beschreibung ähnlicher Verhaltensweisen vorkommen.
  • Architektonische Passung: Fragen Sie, wo diese Art von Logik derzeit zentralisiert ist (z. B. „Wo befindet sich die zentralisierte Logik zur Datumsformatierung?“).
  • Anleitung zur Refaktorisierung: Bitten Sie den Sub-Agenten vor allem darum, zu erläutern, wie der neue Code refaktorisiert werden könnte, um bereits vorhandene Logik zu nutzen, die er findet.
• Generalist-Agent: Setze den Generalisten für detaillierte, rundenintensive Vergleiche ein. Zum Beispiel: „Überprüfe die Implementierung von *MyNewComponent* im PR und vergleiche sie semantisch mit allen Komponenten in *packages/ui/src*. Gibt es bereits vorhandene Komponenten, die erweitert oder stattdessen verwendet werden könnten?“
• Schnellweg für einfache Suchen beibehalten: Bei extrem einfachen, eindeutigen Prüfungen (z. B. „Enthält package.json lodash?“) führe eine direkte Suche durch, um Zeit zu sparen. Bei offenen „Untersuchungen“ standardmäßig an den Sub-Agenten delegieren.

4. Best Practices bewerten

Prüfen Sie, ob der neue Code mit den etablierten Konventionen des Projekts übereinstimmt.

• Fehlerbehandlung: Werden die Standard-Fehlerklassen oder Protokollierungsmechanismen des Projekts verwendet?
• Zustandsverwaltung: Umgeht der Code etablierte Stores oder Kontexte?
• Styling: Werden Farben oder Abstände fest codiert, anstatt Themenvariablen zu verwenden? Wenn der PR ein neues Muster einführt, vergleichen Sie es mit den dokumentierten Standards und stellen Sie ausdrücklich fest, ob stattdessen ein bestehendes Projektmuster hätte verwendet werden sollen.

5. Formulieren Sie konstruktives Feedback

Wenn Sie feststellen, dass der PR bereits vorhandene Funktionalität dupliziert oder eine bewährte Vorgehensweise ignoriert:

• Geben Sie einen klaren Review-Kommentar ab.
• Geben Sie die Quelle an: Nennen Sie ausdrücklich den absoluten oder projektbezogenen Dateipfad sowie das spezifische Symbol (Funktion, Komponente, Klasse), das wiederverwendet werden sollte.
• Implementierungshinweis: Fügen Sie einen kurzen Codeausschnitt oder eine klare Erklärung bei, die zeigt, wie der vorhandene Code integriert werden kann, um die Anforderungen der Aufgabe zu erfüllen.
• Erläutern Sie den Nutzen: Erläutern Sie kurz, warum die Wiederverwendung des bestehenden Codes vorteilhaft ist (z. B. Wartbarkeit, Konsistenz, integrierte Behandlung von Randfällen).

Beispielkommentar:

„Es sieht so aus, als würde dieser PR ein neues `formatDate` -Dienstprogramm einführen. Wir haben bereits eine robuste, getestete `formatDate` -Funktion in ` src/utils/dateHelpers.ts`.

Du kannst deine Implementierung ersetzen, indem du sie wie folgt importierst:

import { formatDate } from '../utils/dateHelpers';// Verwende sie dann hier:
const displayDate = formatDate(userDate, 'MMM Do, YYYY');

Durch die Wiederverwendung wird sichergestellt, dass die Datumsformatierung mit dem Rest der Anwendung konsistent bleibt und Zeitzonenumrechnungen korrekt verarbeitet werden.“