Review Code

Code Review

Systematisches Code-Review mit Fokus auf das Wesentliche.

Kernprinzip

Nur relevante Anmerkungen. Wenn der Code gut ist, sag das - und fertig. Keine kuenstlichen Findings erfinden.

• Kein Review um des Reviews willen
• Keine Stilkritik ohne Substanz
• Keine theoretischen Verbesserungen die praktisch nichts aendern
• Lob wo Lob angebracht ist

Philosophie

Keine Coverage-Jagd - Relevante Tests statt Prozentzahlen. DDD wo sinnvoll - Ubiquitous Language, aussagekraeftige Namen, klare Domaengrenzen. Pragmatische Architektur - Clean Architecture als Leitfaden, nicht als Dogma.

Wann dieser Skill aktiviert wird

Automatisch bei:

• "Review den Code fuer Ticket ios-025"
• "Pruefe die Implementierung von shared-007"
• "Code Review fuer die neuen Timer-Features"
• "Ist die Architektur von AudioService gut?"

Workflow

Schritt 1: Scope ermitteln

Mit Ticket-Referenz:

1. Ticket lesen: dev-docs/tickets/{platform}/{ticket-id}.md
2. Akzeptanzkriterien extrahieren
3. Zugehoerige Dateien identifizieren

Ohne Ticket-Referenz:

1. User nach Scope fragen (Dateien, Feature, Modul)
2. Relevante Dateien mit Glob/Grep finden

Schritt 2: Code lesen

Alle relevanten Dateien lesen:

• Implementierung (Models, Services, ViewModels, Views)
• Zugehoerige Tests
• Abhaengigkeiten (Protocols, Interfaces)

Kontext beachten:

• Wie passt der Code in die bestehende Architektur?
• Welche Patterns werden im Projekt verwendet?

Schritt 3: Ehrliche Bewertung

Bewerte nach 5 Kategorien - aber nur wenn es etwas zu sagen gibt:

1. Wartbarkeit - checklists/wartbarkeit.md
2. Architektur - checklists/architektur.md
3. Lesbarkeit (DDD) - checklists/lesbarkeit.md
4. Testabdeckung - checklists/tests.md
5. Dokumentation - checklists/doku.md

Wichtig: Nicht jede Kategorie muss Findings haben. Guter Code ist gut.

Schritt 4: Ticket-Akzeptanzkriterien pruefen

Falls Ticket vorhanden:

• Jedes Akzeptanzkriterium einzeln pruefen
• Nur dokumentieren was fehlt oder falsch ist

Schritt 5: Statische Pruefungen ausfuehren

Plattform-spezifisch ausfuehren:

• iOS: cd ios && make check
• Android: cd android && ./gradlew lint

Fehler im Report dokumentieren. Kein Finding wenn alles gruen ist.

Schritt 6: Dokumentation pruefen

Pruefen nach checklists/doku.md:

• GLOSSARY.md: Neue Domain-Begriffe dokumentiert?
• Relevante dev-docs: Bei Architektur-/Pattern-Aenderungen aktualisiert?

Nur dokumentieren was fehlt.

Schritt 7: Report generieren

Report nach templates/report.md:

• Kurze Zusammenfassung
• Nur echte Findings (wenn vorhanden)
• Positives nur wenn wirklich bemerkenswert

Wenn alles gut ist:

Der Code erfuellt die Anforderungen und ist gut strukturiert.
Keine Anmerkungen.

Das ist ein valides Review-Ergebnis.

Schritt 8: Interaktive Nachfrage

Nach dem Report dem User die Wahl geben:

Wenn Findings vorhanden:

Mit AskUserQuestion nachfragen:

• "Soll ich die Findings beheben?"
• Optionen:
  • Ja, alle fixen - Alle fixbaren Findings umsetzen
  • Auswahl fixen - User waehlt welche Findings
  • Nein, nur Report - Keine Aenderungen vornehmen

Wenn keine Findings:

Keine Nachfrage noetig, Review ist abgeschlossen.

Beim Fixen:

1. TDD-Workflow einhalten (erst Test rot, dann gruen, dann refactor)
2. Nach jedem Fix make check ausfuehren
3. Aenderungen dokumentieren

Was ECHTE Findings sind

Was NICHT wichtig ist

• 100% Coverage
• Kommentare ueberall
• Maximale Abstraktion
• Perfekte Patterns
• Jede Methode unter 10 Zeilen

Anti-Patterns (nur wenn sie WIRKLICH problematisch sind)

Nur melden wenn es schadet:

• Funktionen die wirklich unverstaendlich sind (nicht: "etwas lang")
• Tests die tatsaechlich nutzlos sind (nicht: "koennten besser sein")
• Architektur die das Projekt behindert (nicht: "nicht ganz lehrbuchmaessig")

Referenzen

• CLAUDE.md - Projekt-Standards
• dev-docs/tickets/INDEX.md - Ticket-System

Converted and distributed by TomeVault — claim your Tome and manage your conversions.