Aufgabe 07 - Jahresprojekt Sprint 2 - Design-Review mit SOLID

Lernziele

Du unterscheidest ein Entwurfsmuster von einer Bibliothek und von kopiertem Code.
Du ordnest Code-Review-Kommentare den fünf SOLID-Prinzipien zu und erkennst einen Kommentar, bei dem kein Prinzip passt.
Du planst Sprint 2 auf Basis der Velocity und der Retro-Maßnahme aus Sprint 1.
Du prüfst Teile deines Jahresprojekts gegen die fünf Prinzipien und begründest Befunde mit der Frage, welche Änderung Kreise zieht.

Ausgangslage

Erste Woche von Sprint 2. Ab jetzt geht es um die Struktur eures Codes. Kapitel 11 liefert dafür das Vokabular: Muster als Namen für bewährte Lösungen und die fünf SOLID-Prinzipien als Kompass. In den nächsten Wochen lernt ihr die Prinzipien und Muster einzeln kennen und setzt sie im Projekt ein. Damit das nicht in Einzelzetteln zerfällt, legt ihr heute ein Dokument an, das bis zum Projektende wächst: docs/design-review.md. Jede folgende Aufgabe ergänzt dort einen Abschnitt, und der Abschlussbericht zitiert es.

Die Kata: Review-Kommentare aus dem Team der Konzertkarten-App.

“Wir holen uns zod und validieren damit alle Formulare.”
“TicketPrinter druckt, berechnet die Gebühren und schickt die Bestätigungsmail.”
“Für jede neue Zahlungsart hängen wir in PaymentService noch einen else if-Zweig an.”
“SeatMap erzeugt im Konstruktor selbst eine PostgresConnection. Im Test brauchen wir deshalb eine echte Datenbank.”
“VipTicket extends Ticket, wirft aber bei refund() immer eine Exception.”
“Das Interface Venue verlangt sellTickets(), rentStage() und cookCatering(); unser Open-Air-Gelände hat keine Küche.”
“Wir haben für jede Hilfsfunktion ein Interface mit genau einer Implementierung angelegt, obwohl sich daran nichts ändern wird.”
“Alle Exportformate bekommen dasselbe Interface, eine zentrale Stelle wählt anhand der Dateiendung das passende aus.”

Dafür brauchst du:

Kapitel 11 Entwurfsmuster I – Muster-Idee und SOLID im Überblick (Muster als Vokabular, Muster gegen Bibliothek, drei Musterkategorien, die fünf Prinzipien mit Kerngedanke, SOLID als Kompass).
Kapitel 05 bis 07 für das Planning von Sprint 2.
Euren Code aus Sprint 1.

Allgemein

Projektordner anlegen siehe https://qiz.at/projektordner

Lies vorher kurz https://qiz.at/assignmentsabgabe durch.
Nur vollständige Abgaben (siehe https://qiz.at/rules) können positiv bewertet werden.
Abgabe- und Testdetails siehe https://qiz.at/assignmentsabgabe
Abgegeben wird dein Projektordner mit einer README.md: darin die Kata und die Links auf Issues, Merge Requests und Dateien dieser Woche im Jahresprojekt-Repository. Das Design-Review liegt im Repository des Teams unter docs/design-review.md.
Wer was beigetragen hat, zeigen Board, Merge Requests und /spend-Einträge (Kapitel 07). Im Design-Review steht bei jedem Abschnitt, wer ihn geschrieben hat.

Wesentlich_überwiegend

Aufgabe

Kata: Ordne die Kommentare 1 und 8 jeweils zu: Entwurfsmuster, Bibliothek oder kopierter Code, mit einem Satz Begründung. Ordne die Kommentare 2 bis 7 einem SOLID-Buchstaben zu, formuliere den Kerngedanken des Prinzips in einem eigenen Satz und nenne die Stelle im Kommentar, an der du es erkannt hast. Bei einem dieser Kommentare passt kein Buchstabe: Begründe, warum.
Planning von Sprint 2: Prüft zuerst die Retro-Maßnahme aus Sprint 1 (umgesetzt oder nicht, mit Beleg). Legt den Milestone Sprint 2 an, plant mit der Velocity aus Sprint 1, formuliert das Sprint-Ziel als einen Satz und zieht die Stories in den Milestone. Wechselt die Prozessrolle (Kapitel 06).

Tipp: Bei den Kommentaren hilft die Frage: Welche Änderung würde hier Kreise ziehen? Bei 1 und 8 hilft die Frage: Bekomme ich fertigen Code oder eine Beschreibung, wie ich ein Problem strukturiere?

Bewertungskriterien

Vollständig, wenn:

beide Aussagen richtig als Bibliothek bzw. Muster eingeordnet und begründet sind,
fünf Kommentare dem richtigen Buchstaben zugeordnet sind, der Kerngedanke jeweils in eigenen Worten steht und der Kommentar ohne passenden Buchstaben mit dem Kompass-Gedanken begründet ist,
die Retro-Maßnahme überprüft, der Milestone Sprint 2 angelegt, das Sprint-Ziel ein Satz über einen Zustand des Produkts ist und die Auswahl zur Velocity passt.

Abgabe

Wie unter Allgemein.

Wesentlich_vollständig

Für alle, die in der Einheit mit den Schritten oben fertig sind bzw. optional (= freiwillig), wenn du in der Einheit nicht fertig wirst.

Aufgabe

Erweitere (siehe Erweitern in https://qiz.at/rules) den vollständigen Teil der vorherigen Stufe dieser Datei (ändere oder lösche nur, was für diese Aufgabe unbedingt notwendig ist):

Legt docs/design-review.md mit einem ersten Abschnitt SOLID-Befund Sprint 1 an. Jede Person im Team wählt ein Modul, eine Klasse oder eine Komponente aus eurem Code und prüft sie in einer Tabelle mit den Spalten Prinzip, berührt? und Beleg (Datei und Zeile) gegen alle fünf Prinzipien.
Benenne für dein Modul das drängendste Problem mit der Frage „Welche Änderung zieht hier Kreise?“: eine konkrete, absehbare Änderung aus eurem Backlog und die Stellen, die sie treffen würde.
Schreibe einen echten Review-Kommentar an einem offenen oder kürzlich gemergten Merge Request eines Teammitglieds im Stil der Kata: eine Stelle, ein Prinzip, ein Vorschlag, sachlich formuliert. Verlinke ihn im Design-Review.
Ergänze im Design-Review eine Liste Musterkandidaten: Stellen im Projekt, an denen ein Erzeugungs-, Verhaltens- oder Strukturproblem steckt, je mit einem Satz und der Kategorie. Die folgenden Aufgaben greifen darauf zurück.

Tipp: Wenn kein Prinzip berührt ist, ist das ein gutes Ergebnis, aber prüfe, ob du zu wohlwollend gelesen hast. Ein Kandidat ist ein Problem, kein Muster: „Je nach Dateityp erzeugen wir einen anderen Upload-Handler“, nicht „hier eine Factory“.

Bewertungskriterien

Vollständig, wenn:

docs/design-review.md existiert und pro Person eine Tabelle mit fünf Zeilen enthält, deren Belege auf echte Stellen im Code verweisen,
das drängendste Problem über eine konkrete Änderung aus dem Backlog begründet ist,
der Review-Kommentar am Merge Request steht, Stelle, Prinzip und Vorschlag nennt und verlinkt ist,
mindestens zwei Musterkandidaten mit Problem und Kategorie notiert sind.

Abgabe

Wie unter Allgemein.

PlusPlus Aufgabe

Für alle, die in der Einheit mit den Schritten oben fertig sind bzw. optional (= freiwillig), wenn du in der Einheit nicht fertig wirst.

Aufgabe

Erweitere (siehe Erweitern in https://qiz.at/rules) den vollständigen Teil der vorherigen Stufe dieser Datei (ändere oder lösche nur, was für diese Aufgabe unbedingt notwendig ist):

Formuliere für euer Team eine Abstraktionsregel in höchstens drei Sätzen: Wann wird ein neues Interface oder eine neue Klasse eingezogen und wann nicht? Nenne ein Beispiel aus eurem Code, bei dem die Regel eine Abstraktion verlangt, und eines, bei dem sie sie verbietet.
Stimmt die Regel im Team ab und haltet sie im Design-Review fest. Ab jetzt prüft jedes Code-Review neue Interfaces gegen diese Regel.

Tipp: Erst wenn eine zweite Variante dazukommt oder eine Abhängigkeit im Test ersetzt werden soll, zahlt sich eine Abstraktion aus. Vorsorge ohne Anlass ist kein Prinzip, sondern Aufwand.

Bewertungskriterien

Vollständig, wenn:

die Regel höchstens drei Sätze hat und prüfbar formuliert ist,
zwei Beispiele aus dem eigenen Code zeigen, dass die Regel einmal eine Abstraktion verlangt und einmal verbietet,
die Regel im Design-Review steht und als Team-Entscheidung gekennzeichnet ist.

Abgabe

Wie unter Allgemein.

MandalorianPlus Aufgabe

Für alle, die in der Einheit mit den Schritten oben fertig sind bzw. optional (= freiwillig), wenn du in der Einheit nicht fertig wirst.

Aufgabe

Erweitere (siehe Erweitern in https://qiz.at/rules) den vollständigen Teil der vorherigen Stufe dieser Datei (ändere oder lösche nur, was für diese Aufgabe unbedingt notwendig ist):

Wende die Abstraktionsregel auf zwei Merge Requests der letzten Wochen an (aus Sprint 1 oder, sobald vorhanden, aus Sprint 2) und dokumentiere je Merge Request: Welche Abstraktion wurde eingeführt oder weggelassen, verlangt die Regel sie, und war die Entscheidung richtig?
Beurteile in drei bis vier Sätzen, an welcher Stelle eures Projekts konsequent angewendetes SOLID heute Überaufwand wäre und an welcher es sich in den nächsten zwei Sprints voraussichtlich auszahlt. Stütze dich auf das Backlog, nicht auf Vermutungen.

Tipp: Der Kasten „SOLID ist ein Kompass, keine Checkliste“ in Kapitel 11 liefert die Reihenfolge: zuerst das Problem benennen, dann das passende Prinzip wählen.

Bewertungskriterien

Vollständig, wenn:

beide Merge Requests verlinkt und gegen die Regel beurteilt sind,
die Beurteilung je eine konkrete Stelle für Überaufwand und für absehbaren Nutzen nennt und sich auf Stories im Backlog stützt.

Abgabe

Wie unter Allgemein.

Zeit dafür

Durchschnittlich bis Wesentlich_vollständig: ca. 70 min (5 min Board-Check, 15 min Kata, 20 min Planning, 30 min Design-Review im Projekt)

Autoren

GAM

Lizenz

CC-BY-SA

Regeln

https://qiz.at/rules