danielsegg/code-review-checklist

Code-Review

Führen Sie evidenzbasierte Reviews im Kontext des Projekts durch. Priorisieren Sie falsches Verhalten, tatsächliche Risiken und Regressionen; generieren Sie keine Beobachtungen nur zum Ausfüllen einer Checkliste.

Umfang und Sicherheit respektieren

• Behandeln Sie das Review als reine Leseaktion. Kein Code bearbeiten, keine Branches wechseln, keine Abhängigkeiten installieren oder aktualisieren, keine Korrekturen anwenden, keine Commits durchführen, keine Kommentare veröffentlichen oder Bereitstellungen vornehmen, ohne explizite Aufforderung.
• Sie dürfen lokale, nicht verändernde Prüfungen durchführen, wenn diese sicher und relevant sind. Vor der Ausführung von Code aus einer nicht vertrauenswürdigen Änderung den Befehl und seine Auswirkungen bewerten.
• Keinen Code, Geheimnisse oder Metadaten ohne Autorisierung an externe Dienste senden.
• Review von Implementierung unterscheiden: Wenn die Anfrage nur ein Review ist, die Ergebnisse melden, ohne sie zu korrigieren.
• Vorhandene Benutzeränderungen bewahren und destruktive Befehle vermeiden.

Kontext aufbauen

1. Lesen Sie AGENTS.md und die für das überprüfte Verzeichnis geltenden Anweisungen vollständig.
2. Identifizieren Sie Ziel, Anforderungen und Umfang der Änderung anhand der Anfrage, des Issues, der PR-Beschreibung, des Diffs und des relevanten Verlaufs.
3. Untersuchen Sie alle geänderten Dateien und den direkt verwandten Code, bevor Sie etwas als Fehler beurteilen.
4. Überprüfen Sie die tatsächlichen Konfigurationen, Versionen, Architektur und Konventionen des Projekts. Wenden Sie keine Muster aus einer anderen Sprache oder Framework analog an.
5. Recherchieren Sie lokal verfügbare Informationen, bevor Sie um Klärung bitten. Fragen Sie nur, wenn eine Lücke eine verantwortungsvolle Schlussfolgerung verhindert.
6. Dokumentieren Sie die Einschränkungen der Analyse, wie nicht ausgeführte Tests, nicht verfügbare Abhängigkeiten oder fehlende Anforderungen.

Das Review durchführen

Bewerten Sie jede Änderung in den zutreffenden Dimensionen:

Funktionalität und Regressionen

• Bestätigen Sie, dass die Implementierung das angeforderte Verhalten erfüllt und bestehende Abläufe beibehält.
• Untersuchen Sie Grenzfälle, leere oder Null-Werte, Teilausfälle, Wiederholung der Operation, Nebenläufigkeit und Zustandsübergänge.
• Prüfen Sie Fehlerbehandlung, Rollback, Idempotenz und Seiteneffekte.
• Überprüfen Sie öffentliche Verträge, Abwärtskompatibilität, Migrationen und Auswirkungen auf Konsumenten.

Sicherheit und Privatsphäre

• Überprüfen Sie Eingabevalidierung und Ausgabekodierung an den richtigen Grenzen.
• Suchen Sie nach Autorisierungs-, Authentifizierungs-, CSRF-, XSS-, Injection-, Path-Traversal-, SSRF-, unsicheren Upload- und Mass-Assignment-Fehlern.
• Prüfen Sie die Offenlegung von Geheimnissen oder personenbezogenen Daten in Code, Antworten, URLs und Logs.
• Bewerten Sie Berechtigungen nach Anwendungsfall und Ressource; isolierte Authentifizierung ersetzt keine Autorisierung.
• Behandeln Sie Abhängigkeitswarnungen als zu bestätigende Beweise unter Berücksichtigung der Ausnutzbarkeit und Kompatibilität der Korrektur.

Daten, Leistung und Zuverlässigkeit

• Identifizieren Sie N+1-Probleme, wiederholte Abfragen, übermäßiges Laden, aufwändige Schleifen und Algorithmen, die für das erwartete Volumen ungeeignet sind.
• Prüfen Sie Transaktionen, Sperren, Constraints, Indizes und referenzielle Integrität, wenn die Änderung die Persistenz betrifft.
• Überprüfen Sie Paginierung, Limits, Timeouts, Wiederholungsversuche und Speichernutzung in relevanten Pfaden.
• Empfehlen Sie Optimierung oder Caching nur, wenn ein plausibler Engpass vorliegt; berücksichtigen Sie Invalidierung und Konsistenz.
• Bei monetären Berechnungen dezimale Genauigkeit, Rundung und Atomizität prüfen.

Design und Wartbarkeit

• Bewerten Sie Kohäsion, Trennung der Verantwortlichkeiten, Abhängigkeitsrichtung und Domänensprache.
• Bevorzugen Sie einfachen und expliziten Code. Verlangen Sie keine willkürlich kleinen Funktionen noch vorzeitige Abstraktionen, um jede Wiederholung zu eliminieren.
• Überprüfen Sie Namen, Verträge, Typbehandlung und Kommentare, die nicht offensichtliche Entscheidungen erklären.
• Überlassen Sie mechanische Stilfragen den Formatierern und Linter des Projekts, es sei denn, sie beeinträchtigen Korrektheit oder Verständnis.

Tests und Dokumentation

• Überprüfen Sie Tests, die proportional zum Risiko sind und das Hauptverhalten, Grenzfälle, Fehler und relevante Regressionen abdecken.
• Bewerten Sie die Qualität der Assertions, die Isolation und die Fähigkeit des Tests, bei dem beabsichtigten Fehler zu scheitern; verwenden Sie nicht nur die prozentuale Abdeckung.
• Prüfen Sie Dokumentation, API-Verträge und Betriebsanweisungen, wenn sich das öffentliche Verhalten ändert.
• Befolgen Sie vor der Ausführung von Prüfungen die vom Repository vorgeschriebenen Befehle und die Umgebung. Berichten Sie genau, was ausgeführt wurde oder nicht.

Prüfungen für PHP und CakePHP anwenden

Wenn der Stack PHP oder CakePHP umfasst, zusätzlich:

• Prüfen Sie die Kompatibilität mit der PHP-Version und verwenden Sie die vom Projekt konfigurierten Tools wie PHPUnit, PHPCS, PHPStan, Psalm und composer audit.
• Halten Sie Controller fokussiert auf HTTP-Eingabe und Orchestrierung; lokalisieren Sie Geschäftslogik in der vom Projekt verwendeten Schicht, normalerweise Services.
• Untersuchen Sie Policies und Autorisierungsprüfungen für jede Aktion und Ressource.
• Bewerten Sie Validators, RulesChecker, patchEntity(), zugängliche Felder der Entity und Schutz vor Mass Assignment.
• Bevorzugen Sie ORM, Query Builder und gebundene Parameter gegenüber konkateniertem SQL; überprüfen Sie Associations, contain(), Feldauswahl und N+1-Risiko.
• Überprüfen Sie Transaktionen bei Operationen mit mehreren Schreibvorgängen und unterscheiden Sie Persistenzfehler von unerwarteten Ausnahmen.
• Prüfen Sie Escaping in Templates, explizit nicht maskierte Felder, CSRF und Antworten, die interne Details preisgeben könnten.
• Überprüfen Sie Migrationen auf praktische Umkehrbarkeit, vorhandene Werte, Sperren, Indizes, Fremdschlüssel und Kompatibilität mit der unterstützten Datenbank.
• Respektieren Sie composer.lock; empfehlen Sie keine pauschale Aktualisierung von Abhängigkeiten.

Für CakePHP im Núcleo Lavanderias beachten Sie besonders den Fluss Controller → Service → Table/Entity, den Vertrag von AbstractService::run(), die Policies pro Profil, MariaDB, PHPUnit und die Ausführung von Befehlen innerhalb der Container, immer ohne -u root bei Tests.

Prüfungen für das Web-Frontend anwenden

• Prüfen Sie kontextbezogenes Escaping, sicheres DOM-Manipulation, CSRF, serverseitige Validierung und Datenoffenlegung.
• Überprüfen Sie Lade-, Fehler-, Nebenläufigkeits-, Abbruch- und außerhalb der Reihenfolge liegende Antwortzustände.
• Respektieren Sie den lokalen Stack und die Konventionen; in neuem Code für Núcleo Lavanderias bevorzugen Sie StimulusJS und Axios und beschränken Sie jQuery auf die Wartung des Legacy-Codes.
• Bewerten Sie Barrierefreiheit und responsives Verhalten, wenn die Änderung die Benutzeroberfläche betrifft.

Ergebnisse validieren

Bevor Sie ein Problem melden:

1. Bestätigen Sie, dass es durch den überprüften Umfang eingeführt oder beeinflusst wurde.
2. Lokalisieren Sie die kleinste Code-Region, die das Problem demonstriert.
3. Beschreiben Sie ein konkretes Szenario, in dem das Verhalten auftritt.
4. Überprüfen Sie, ob eine andere Schicht, Konfiguration oder der Test das Risiko bereits mindert.
5. Passen Sie den Schweregrad anhand der Wahrscheinlichkeit und der Auswirkung an, nicht nach der abstrakten Regelart.

Abwesenheit im Diff beweist nicht Abwesenheit im System. Wenn das Repository verfügbar ist, untersuchen Sie die verwandten Schichten, bevor Sie fehlende Autorisierung, Validierung, Transaktion oder gleichwertigen Schutz melden. Wenn nur ein isoliertes Fragment vorliegt, stellen Sie den Punkt als bedingtes Risiko oder Frage dar, nicht als bestätigten Fehler.

Stellen Sie keine entfernte Hypothese als bestätigten Fehler dar. Wenn eine relevante Unsicherheit bestehen bleibt, identifizieren Sie diese explizit und sagen Sie, welche Beweise die Frage klären würden.

Den Bericht erstellen

Präsentieren Sie zuerst die Ergebnisse, geordnet nach Schweregrad:

• Blockierend: Datenkorruption, ausnutzbare Schwachstelle, schwere Nichtverfügbarkeit oder unbrauchbares Kernverhalten.
• Hoch: Wahrscheinlicher Fehler mit relevanter Auswirkung oder wichtige Regression.
• Mittel: Reales Problem mit begrenzter Auswirkung, abhängig von einer bestimmten Bedingung.
• Niedrig: Konkrete und lokalisierte Verbesserung ohne unmittelbares signifikantes Risiko.

Fügen Sie für jedes Ergebnis hinzu:

### [Schweregrad] Objektiver Titel

- Ort: `pfad/datei.erweiterung:zeile`
- Beweis: Nachweisbares Verhalten im Code.
- Auswirkung: Betroffenes Szenario und Konsequenz.
- Empfehlung: Richtung einer angemessenen Korrektur, ohne die gesamte Lösung neu zu schreiben.

Verwenden Sie immer die lokale Zeile der Datei, niemals die globale Position des Abschnitts in einer Diff-Datei. Wenn der Diff keine ausreichende Hunk-Nummerierung liefert, zitieren Sie das Symbol oder die Methode und geben Sie an, dass die Zeile nicht verfügbar ist. Halten Sie den Bereich kurz und direkt auf den Befund bezogen. Gruppieren Sie äquivalente Vorkommen, anstatt Kommentare zu wiederholen.

Nach den Ergebnissen notieren Sie kurz:

• Fragen oder Annahmen, die die Schlussfolgerung beeinflussen;
• durchgeführte Prüfungen und ihre Ergebnisse;
• verbleibende Risiken oder Testlücken.

Wenn es keine Befunde gibt, erklären Sie dies deutlich und informieren Sie dennoch über Einschränkungen und durchgeführte Prüfungen. Ersetzen Sie Befunde nicht durch eine generische Zusammenfassung der Änderung, es sei denn, der Benutzer fordert auch die Zusammenfassung an.