Senior Java · Fachbereich

Code Review Center

Risikobasierte Reviews für Fachlichkeit, Architektur, Sicherheit, Performance und Betrieb. Nutze die Seite vor Review oder Freigabe: Wähle Prüfungen nach Risiko, dokumentiere Befunde und liefere nachvollziehbare Evidence statt einer pauschalen Bewertung.

Zur Übersicht

Arbeitsauftrag

Wann verwenden?

Vor dem Merge risikoreicher Änderungen oder bei fachlich und technisch schwer lesbarem Code.

Nicht dafür verwenden

Nicht für Geschmacksdiskussionen ohne Auswirkung oder automatisierbare Formatfragen.

Definition of Done

Befunde enthalten Evidenz, Risiko und konkrete Empfehlung; kritische Punkte sind behoben oder bewusst akzeptiert.

Reviewtiefe an Risiko anpassen

Kommentare konkret und lösungsorientiert formulieren

Automatisierbare Diskussionen aus Reviews entfernen

Alle Kapitel

Review-Reihenfolge

Zuerst wird die fachliche Absicht geprüft, dann Architektur und Datenfluss, danach Detailcode. Wer bei Formatierung startet, übersieht leicht die eigentliche Wirkung.

Automatisierbare Regeln gehören in Formatter, Linter oder Tests.

TEXT

1. Problem und Akzeptanzkriterien
2. Änderungsschnitt und Seiteneffekte
3. Domänenregeln und Transaktionen
4. API, Daten und Events
5. Security und Observability
6. Tests und Fehlerszenarien
7. Lesbarkeit und Wartbarkeit

Gute Kommentare

Ein guter Review-Kommentar nennt Beobachtung, Risiko und mögliche Richtung. Er unterscheidet Blocker, Vorschlag und Frage.

Persönliche Formulierungen und unbegründete Geschmacksurteile werden vermieden.

TEXT

Blocker: Der externe HTTP-Aufruf läuft innerhalb der Datenbanktransaktion.
Bei einem Timeout bleiben Locks länger aktiv. Können wir den Versand über eine Outbox nach der lokalen Zustandsänderung entkoppeln?

Review-Nachweise

Bei risikoreichen Änderungen gehören relevante Testausgaben, Migrationsnachweise, Beispieltelemetrie oder Lastmessungen zum Pull Request.

Praxisartefakt · Review-Befund

Beobachtung: Der Controller schreibt Datenbank und Kafka nacheinander ohne gemeinsame Konsistenzstrategie.
Risiko: Bei Brokerfehler bleibt die Bestellung gespeichert, aber das fachliche Ereignis fehlt.
Evidence: OrderController.java:84 und fehlender Recovery-Test.
Empfehlung: Transactional Outbox verwenden und Publisher separat retryfähig ausführen.
Abschlusskriterium: Integrationstest reproduziert Brokerfehler und weist spätere Zustellung ohne Duplikat nach.