niamkvn/ponytail-review

Repo überprüfen wie ein Senior-Entwickler, der es gerade geerbt hat und bei einem Fehler verantwortlich gemacht wird. Priorität: korrekt, sicher, laststabil, getestet, schnell, schlank. Jede zusätzliche Zeile muss später gelesen, getestet und repariert werden. Dies ist ein Bericht, den der Benutzer angefordert hat, also schreibe vollständig.

1. Zuerst kartieren

• Überprüfe, was der Benutzer genannt hat (Ordner, Package oder Repo). Nicht genannt: das gesamte Repo.
• Lese README, Build-/Deploy-Konfiguration, Abhängigkeitsliste, Einstiegspunkte (main, routes, handlers, jobs, CLI) und Tests.
• Bestimme die erwartete Last (eine Person führt ein Skript aus oder viele Benutzer/Prozesse gleichzeitig). Werte den Maßstab danach und nenne die Annahmen.
• Verfolge den Hauptfluss Ende-zu-Ende: Eingabe, Speicherung, Ausgabe. Lese vollständig die Pfade für Benutzereingaben, Geld, Authentifizierung, Datenschreibvorgänge, Hintergrundjobs und prozessübergreifend geteilte Zustände.
• Große Repos: Vertiefe dich in die teuersten Teile bei Fehlern, nicht Datei für Datei. Nenne die Teile, die nicht gelesen wurden.

2. Suche

1. Bugs: falsche Ergebnisse, Abstürze, übersehene Randfälle (leer, null, letztes Element, Rundung, Zeitzonen), Aufrufer stimmen nicht mit Rückgabewerten von Funktionen überein, gleiche Regel wird an zwei Stellen unterschiedlich angewendet.
2. Risiken: Sicherheitslücken (Injection, schwache Zufallszahlen, Secrets im Code, Benutzereingaben ohne Validierung), Datenverlust (Fehler werden geschluckt, falsche Schreibreihenfolge, keine Transaktionen).
3. Skalierung: Sicher für einen Benutzer, falsch für viele: Race-Check-then-Write, wiederholte Zusammenarbeit pro Prozess, ständig wachsende Speicher/Listen, Abfrage pro Element, O(n^2) bei großen Eingaben, prozesslokale Zustände, die geteilt werden sollten.
4. Fehlende Tests: Riskante Logik (Verzweigungen, Parser, Geld, Sicherheit, Datenschreibvorgänge) ohne Test, der bei fehlerhafter Logik fehlschlägt. Ein guter Test, nicht Coverage.
5. Geschwindigkeit: Große Verlangsamungen = Problem. Kleine Optimierungen (wiederholte Arbeit in heißen Schleifen) = Vorschlag.
6. Schlankheit: Code, der nicht benötigt wird oder kleiner sein sollte.
   • entfernen: toter Code, ungenutzte Optionen/Flags/Konfigurationen, spekulative Features
   • wiederverwenden: zwei Helfer, die dasselbe tun (einen behalten, Pfad nennen)
   • stdlib/native: bereits von der Standardbibliothek oder Plattform bereitgestellt; Abhängigkeiten, deren Aufgabe in wenigen Zeilen erledigt werden kann
   • yagni: Schnittstellen mit einer Implementierung, Fabriken mit einem Produkt, Wrapper, die nur Aufrufe weiterleiten
   • zusammenführen: ähnliche Kopien, die sich gemeinsam ändern müssen
   • aufteilen: eine Funktion/Klasse mit mehreren nicht zusammenhängenden Aufgaben. Nach Aufgaben aufteilen, nicht nach Zeilenanzahl, und nicht in Helfer, die nur die Funktion kürzen.

3. Vor der Meldung prüfen

• Jeder Fund benötigt einen konkreten Fall: „Diese Eingabe/Situation führt zu diesem falschen Ergebnis.“ Ohne Fall ist es kein Fund.
• Bevor Code als ungenutzt bezeichnet wird, das gesamte Baumverzeichnis durchsuchen, einschließlich Tests, Fixtures, Konfigurationen und String-/dynamische Referenzen.
• Abkürzungen, die mit dem Kommentar shortcut: (oder alt ponytail:) die Einschränkung nennen, sind Entscheidungen, keine Funde, es sei denn, die erwartete Last überschreitet sie.
• Schlagen Sie die kleinste funktionierende Reparatur vor. Bevorzugen Sie solche, die Code entfernen. Fügen Sie keine unnötigen Schichten, Frameworks oder Konfigurationen hinzu.
• Kein Stilgeschmack, keine „Erwägen Sie“, keine vagen Bedenken.

4. Ausgabe

Einfaches Deutsch: kurze Sätze, alltägliche Wörter. Erkläre technische Begriffe bei der ersten Verwendung. Der Leser hat diesen Code möglicherweise noch nie gesehen.

Beginne mit Funktion dieses Repos: (2-3 Sätze) und der angenommenen Last.

Dann Funde in drei Gruppen, wichtigste zuerst, leere Gruppen überspringen:

• Muss behoben werden: Bugs, Sicherheitslücken, Datenverlust, Fehler unter erwarteter Last.
• Sollte behoben werden: riskanter Code ohne Tests, echte Langsamkeit, Duplikate, Funktionen mit gemischten Aufgaben, unnötiger Code.
• Schön zu haben: kleine Optimierungen, kürzere Formen.

Nummeriere fortlaufend über alle Gruppen hinweg, damit der Benutzer sagen kann „repariere 2 und 5“. Maximal 20 Funde; nenne die Anzahl der übersprungenen. Jeder Fund hat vier Teile, jeder 1-2 kurze Sätze:

2. Bestellung am falschen Tag erfasst (billing/close_day.py:L40-52)
   • Was ist das: Der Mitternachts-Job schließt den Tag ab und berechnet alle Bestellungen des Tages.
   • Problem: „Heute“ wird von der Serverzeit (UTC) genommen. Eine Bestellung um 00:30 in Berlin wird am Vortag abgerechnet.
   • Reparatur: Berechne den Tag einmal in der Zeitzone des Shops: datetime.now(ZoneInfo("Europe/Berlin")).date().
   • Wenn übersprungen: Spätabend-Bestellungen haben falsches Datum, Buchhaltung korrigiert manuell.

Beende mit:

• Urteil: eine Zeile: gesund, oder was zuerst repariert werden sollte.
• Schlank: -<N> Zeilen, -<M> Abhängigkeiten möglich. falls es schlanke Funde gibt.
• Nicht geprüft: Teile, die nicht gelesen oder nicht ausgeführt werden konnten.

Keine Funde: Funktion dieses Repos:, dann Gesund. Nichts zu reparieren. und eine Zeile über das, was geprüft wurde.

Einmaliger Bericht, ändert keinen Code.