Aufgabe 21 - Review-Runde

Aufgabe 21 - Review-Runde

Worum geht es?

Code-Review als Handwerk: Sie stellen einen Merge Request nach den Regeln, reviewen fremden Code anhand der Klassen-Checkliste und arbeiten erhaltenes Feedback professionell ein. Die Übung läuft in Dreiergruppen im Ringtausch (A reviewt B, B reviewt C, C reviewt A) und ist die unmittelbare Vorbereitung auf den Projekt-Workflow (siehe Kapitel Qualität im Team).

Was Sie dafür brauchen

• Kapitel Qualität im Team; Ihr Buffet-Repository am Schul-GitLab (geschützter main-Branch).
• Dreiergruppen; die gemeinsam erstellte Review-Checkliste der Klasse.

Welche Kompetenzen Sie erwerben und zeigen

• Sie erstellen kleine, beschriebene, reviewbare Merge Requests.
• Sie geben konkretes, begründetes und respektvolles Review-Feedback.
• Sie arbeiten Reviews ein und begründen Annahme oder Ablehnung jeder Anmerkung.

Pädagogische Einordnung

• Reproduktion: den MR-Ablauf (Branch, Push, Beschreibung) durchführen (Teil A).
• Reorganisation und Transfer: die Checkliste auf fremden Code anwenden und Befunde formulieren (Teil B).
• Reflexion, Problemlösung und Urteilsbildung: Feedback abwägen, Review-Kultur auswerten und Regeln ableiten (Teile C und D).

Arbeitsaufträge

Die Übung ist auf etwa zwei Stunden ausgelegt (der MR aus Teil A kann vorbereitet mitgebracht werden). Teil D ist der Expertenteil.

Teil A - Der Merge Request

1. Implementieren Sie auf einem Feature-Branch ein kleines neues Feature Ihrer Wahl (Kandidaten: Tagesumsatz-Anzeige für das Buffet, “Bestellung wiederholen” für Schüler, Artikelbild). Bewusst klein: unter 200 geänderte Zeilen; was größer würde, wird beschnitten.
2. Für das Feature gelten die Standards der bisherigen Übungen: Regeln im Service, Validierung an der Grenze, mindestens ein Test.
3. Stellen Sie den MR mit vollständiger Beschreibung: was, warum, wie getestet, Screenshot. Hausregel der Klasse: Ein MR ohne Beschreibung wird ungelesen zurückgewiesen.

Teil B - Das Review

Reviewen Sie den zugeteilten MR anhand der Checkliste (Basis: Läuft es? Tests vorhanden und sinnvoll benannt? Schichtenregeln eingehalten? Validierung an der Grenze? Vertrag und Doku angepasst? Namen verständlich?). Verbindliche Regeln:

1. Mindestens vier inhaltliche Anmerkungen, davon mindestens eine positive; gute Lösungen zu benennen ist Teil des Handwerks.
2. Jede kritische Anmerkung nennt Problem, Begründung (welches Kriterium) und einen Vorschlag; “gefällt mir nicht” zählt nicht.
3. Anmerkungen als Inline-Kommentare an der betroffenen Zeile; zusammenfassendes Urteil als MR-Kommentar.
4. Zeitrahmen ernst nehmen: 25 Minuten konzentriertes Review; was Sie in der Zeit nicht prüfen konnten, benennen Sie ehrlich.

Teil C - Einarbeiten und Mergen

1. Beantworten Sie jede erhaltene Anmerkung: umgesetzt (mit Commit-Verweis) oder begründet abgelehnt; stilles Ignorieren ist keine Option.
2. Nach dem Re-Review des Reviewers: Merge über die Plattform; der Review-Verlauf bleibt dokumentiert.

Teil D - Expertenteil: Die Kulturauswertung

1. Abschlussrunde in der Dreiergruppe: Welche Anmerkung hat den Code am meisten verbessert? Welche Formulierung kam gut an, welche schlecht, und warum? Notieren Sie je ein konkretes Beispiel (anonymisiert).
2. Formulieren Sie drei Merksätze für die Review-Kultur der Klasse, die im Projekt gelten sollen; keine Allgemeinplätze, sondern Regeln mit Prüfkriterium (“Jede kritische Anmerkung enthält einen Vorschlag” statt “Seid nett”).
3. Prüfen Sie Ihre eigene Review-Leistung gegen die Checkliste: Welche Kriterienkategorie haben Sie am schwächsten geprüft (Architektur? Tests? Vertrag?), und was nehmen Sie sich fürs Projekt vor?
4. Zusatz: Reviewen Sie den Review Ihres Reviewers: Waren die Anmerkungen konkret, begründet, respektvoll? Ein Satz Feedback zum Feedback an die betreffende Person; auch das gehört zur Kultur.

Wissenscheck

1. Warum sind kleine MRs besser reviewbar, und wo liegt die Richtgröße?
2. Welche drei Bestandteile braucht jede kritische Review-Anmerkung?
3. Was muss ein Autor mit jeder Anmerkung tun?
4. Warum gehört mindestens eine positive Anmerkung in jedes Review?
5. Was dokumentiert der MR-Verlauf für das Team über den Merge hinaus?

Abgabe

Links zu Ihrem gemergten MR (mit Review-Verlauf) und zu dem von Ihnen geschriebenen Review; die drei Merksätze und Ihre Selbstauswertung aus Teil D.