Coding-Praxis

Angular — Coding-Praxis

0:00 Das letzte Modul enthält nichts, was spezifisch für Angular wäre. Und trotzdem halte ich es für eines der wichtigsten, denn es beantwortet eine Frage, die im Alltag ständig auftaucht: Wo gehört dieser Code eigentlich hin? Es geht um das Single-Responsibility-Prinzip, um kleine Funktionen und um die Trennung zwischen Darstellung und Fachlichkeit.

0:19 Diese Themen erklären nebenbei, warum Services in Angular eine so zentrale Rolle spielen — sie sind nämlich keine Beigabe des Frameworks, sondern die Antwort auf genau diese Frage.

Allgemeine Coding-Praxis

0:30 Vier Kapitel, die aufeinander aufbauen. Zuerst das Prinzip: eine Verantwortung je Einheit. Dann die kleinste praktische Anwendung davon — Funktionen, die man auf einen Blick versteht. Und danach zweimal dieselbe Frage auf verschiedenen Ebenen: Wie hält man Logik aus dem Template heraus, und wie hält man Fachlogik aus der Komponentenklasse heraus.

0:51 Das Leitmotiv steht in dem Satz auf der Folie: Code wird einmal geschrieben und ein Dutzend Mal gelesen. Alles, worüber wir hier sprechen, optimiert für das Lesen — nicht für das Schreiben.

Das Single-Responsibility-Prinzip

1:03 Fangen wir mit dem Prinzip an, aus dem der Rest folgt. Es ist so alt, dass man es fast überhört, und es beschreibt trotzdem präzise, warum manche Codebasen sich leicht ändern lassen und andere nicht. Für Angular ist es außerdem die Begründung für eine Entwurfsentscheidung, die man sonst einfach hinnimmt. Und es beantwortet nebenbei die Frage, die man sich beim Programmieren am häufigsten stellt, ohne sie auszusprechen: Wohin damit?

1:28 Jede Einheit trägt genau eine Verantwortung. Für eine Komponente heißt das: Darstellung und Nutzerinteraktion — sonst nichts. Das Bild, das ich dazu brauchbar finde, ist eine Theaterbühne. Die Schauspieler zeigen, was zu sehen ist, und reagieren auf das Publikum. Sie schreiben nicht nebenbei das Stück und verkaufen keine Karten.

1:47 Sobald eine Komponente anfängt zu wissen, unter welcher Adresse Daten liegen und wie ein Warenkorbrabatt gerechnet wird, tut sie mehr als ihre Aufgabe — und wird dadurch schwerer zu ändern, zu testen und zu verstehen. Der erste Punkt macht es konkret: Eine Komponente, die Daten selbst holt, kennt plötzlich Adressen und Datenformate.

2:07 Das sind Dinge, die sich ändern werden — und zwar aus Gründen, die mit der Darstellung nichts zu tun haben. Der zweite Punkt beschreibt die Rechnung, die man dafür bezahlt: Wer nur eine Farbe ändern will, muss trotzdem verstehen, wie geladen wird. Der dritte ist der Gewinn — was ausgelagert ist, können andere mitbenutzen. Und der vierte ist der, den man beim Testen merkt: Kleine Einheiten prüft man einzeln, große gar nicht.

2:33 Achten Sie auf das, was in der unteren Hälfte fehlt. Keine Adresse, kein Abonnieren, keine Umwandlung. Die Komponente sagt nur noch, was passieren soll — und überlässt das Wie zwei Services. Der Satz in der Fußzeile bringt es auf den Punkt: Sie weiß danach, dass es geht, aber nicht mehr, wie. Das ist kein Verlust, sondern der Zweck.

2:53 Denn wenn sich morgen die Adresse ändert oder die Rabattlogik, betrifft das genau eine Stelle — und nicht jede Komponente, die zufällig auch Teile anzeigt. Der erste Punkt beschreibt den typischen Zustand einer gewachsenen Komponente — sie weiß über die Zeit einfach zu viel. Der zweite erklärt, wie es dazu kommt: „nur schnell hier rein", weil es gerade dringend war. Das Problem ist nicht die Entscheidung, sondern dass niemand sie je zurücknimmt.

3:20 Der dritte ist die Alibi-Variante — man legt Services an und lässt die Logik trotzdem, wo sie war. Und der vierte ist die notwendige Gegenrede: Für jede Kleinigkeit einen Service zu bauen, ist auch keine Tugend. Das Prinzip fragt nach Verantwortung, nicht nach Zeilenzahl. Diese Aufgabe hat einen Trick, den ich empfehle: Fangen Sie mit Papier an. Listen Sie auf, was die Komponente alles weiß — jede Adresse, jede Rechenregel, jedes Format.

3:47 Diese Liste ist fast immer länger als erwartet, und sie ist zugleich Ihr Arbeitsplan. Geschafft haben Sie es, wenn nur noch Darstellung und Interaktionsbehandlung übrig sind. Nebenbei lernen Sie etwas über Ihre eigene Codebasis: Die Punkte, bei denen Sie zögern, wo sie hingehören, sind meistens genau die, die schon länger Ärger machen.

Kleine, gut benannte Funktionen

4:07 Vom Prinzip zur kleinsten praktischen Anwendung. Es geht um Funktionen, und um eine Frage, die man sich beim Lesen fremden Codes ständig stellt: Was tut das hier eigentlich? Wenn man dafür jede Zeile lesen muss, ist die Antwort teuer. Es geht um eine Eigenschaft, die man beim Schreiben nie vermisst und beim Lesen ständig: dass man den Ablauf erkennt, ohne die Details zu kennen.

4:29 Das ist billiger zu haben, als man denkt. Eine Funktion soll auf einen Blick lesbar sein. Tut sie mehrere Dinge, bekommen diese Dinge eigene Namen — und die äußere Funktion liest sich dann wie eine Inhaltsangabe. Der Vergleich, der mir dazu einfällt, ist ein Rezept. „Teig zubereiten, Ofen vorheizen, backen" versteht man sofort.

4:50 Dieselben Angaben als ein durchlaufender Absatz von dreißig Zeilen sind zwar vollständiger, aber man weiß erst am Ende, worum es ging. Beim Code ist es genauso, nur dass man ihn öfter liest als ein Rezept. Vier Zeilen, und Sie wissen, was hier passiert: Bestellung bauen, Bestand prüfen, absenden, Warenkorb leeren. Ohne eine einzige der eigentlichen Zeilen gelesen zu haben.

5:13 Das ist der ganze Gewinn. Und beachten Sie: Es ist nicht weniger Code geworden — die Arbeit steckt weiterhin irgendwo, nur eben hinter Namen. Der Unterschied ist, dass Sie jetzt entscheiden können, wie tief Sie lesen wollen. Wer nur wissen will, ob hier der Bestand geprüft wird, ist nach vier Zeilen fertig. Der zweite Punkt ist der, den ich am wichtigsten finde: Gute Namen ersetzen Kommentare.

5:37 Ein Kommentar, der erklärt, was die nächsten zehn Zeilen tun, ist meistens ein Hinweis darauf, dass diese zehn Zeilen eine eigene Funktion sein sollten — mit genau diesem Kommentar als Namen. Der Vorteil: Ein Name kann nicht veralten, ohne dass es auffällt, ein Kommentar schon. Der dritte Punkt ist der praktische — Teilschritte lassen sich einzeln testen.

5:57 Und der vierte betrifft die Änderungssicherheit: Was klein ist, ändert man ohne Nebenwirkungen. Der erste Punkt ist der, der die ganze Übung entwertet: aufteilen und dann „handleData" nennen. Dann hat man mehr Funktionen und genauso wenig Information. Der zweite ist die Übertreibung — wer bis auf Einzeiler herunterbricht, versteckt den Ablauf wieder, diesmal hinter zwanzig Sprüngen.

6:20 Der dritte ist eine Frage der Schnittstelle: Hilfsfunktionen sollten nicht öffentlich werden, nur weil man sie extrahiert hat. Und der vierte ist der technische — beim Zerlegen fallen manchmal Reihenfolgeabhängigkeiten auf, die vorher unsichtbar im Ablauf steckten. Auch hier lohnt der Umweg über Papier. Schreiben Sie zuerst auf, welche Aufgaben die Funktion erledigt — und genau diese Stichworte werden dann Ihre Funktionsnamen.

6:45 Wer so vorgeht, bekommt fast von selbst gute Namen, weil sie aus der Beschreibung stammen und nicht aus der Implementierung. Geschafft haben Sie es, wenn die äußere Funktion die Schritte nennt und die Tests unverändert durchlaufen. Dieses „unverändert" ist wichtig: Es ist ein Refactoring, keine Verbesserung des Verhaltens.

7:04 Beides gleichzeitig zu machen, ist der schnellste Weg zu einem schwer auffindbaren Fehler.

Logik aus dem Template heraushalten

7:10 Jetzt wird es wieder Angular-spezifischer, auch wenn das Prinzip dasselbe bleibt. Es geht um das Template — und um die Frage, warum Verzweigungen dort teurer sind, als sie aussehen. Eine Verzweigung im Template ist schnell geschrieben und kostet beim Lesen jedes Mal wieder Aufmerksamkeit. Warum das so ist und was man stattdessen tut, schauen wir uns an — mit zwei gangbaren Wegen, von denen einer der bessere ist.

7:34 Ein Template hat eine Aufgabe: die Struktur zu zeigen. Wer beim Überfliegen erkennen will, wie eine Seite aufgebaut ist, will Elemente sehen — und keine verschachtelten Bedingungen. Jede Entscheidung, die im Template getroffen wird, verdeckt diese Struktur ein Stück weit. Das Gegenmittel ist unspektakulär: Die Entscheidung wandert in die Klasse, bekommt einen Namen, und das Template liest nur noch das Ergebnis.

7:59 Aus einer Bedingung wird ein Wert — und Werte lassen sich lesen, ohne dass man sie nachrechnet. Die beiden Fassungen tun dasselbe, und der Unterschied ist trotzdem groß. Oben müssen Sie den Ausdruck von innen nach außen durchgehen, um zu wissen, was in dem Element steht. Unten steht ein Name, der die Frage beantwortet. Und der Name bringt noch etwas mit, das in der oberen Fassung fehlt: Er ist testbar.

8:23 Sie können prüfen, ob bei null Stück tatsächlich „ausverkauft" herauskommt — ohne eine Komponente zu rendern. Das ist der eigentliche Gewinn, und er fällt fast nebenbei ab. Der erste Punkt ist der offensichtliche. Der zweite und dritte gehören zusammen: Eine benannte Entscheidung ist testbar und wiederverwendbar — eine im Template eingebaute ist beides nicht.

8:45 Der vierte ist der, den man im Editor merkt: In der Klasse greifen Typprüfung und Editorunterstützung deutlich besser als in einem Template-Ausdruck. Auch mit den strengen Template-Prüfungen aus dem ersten Modul bleibt das so. Kurz gesagt: Dieselbe Logik ist in der Klasse an fast jeder Front besser aufgehoben. Der erste Punkt betrifft einen Ausweg, den es tatsächlich gibt: Template- Variablen.

9:09 Sie sind legitim und in Maßen nützlich — nur werden sie gerne zum Einfallstor, über das die Logik durch die Hintertür zurückkommt. Der zweite ist der Zustand, den man in älteren Projekten findet: Bedingungen, die so tief verschachtelt sind, dass niemand mehr die HTML-Struktur erkennt. Der dritte hat mit Performance zu tun — Methodenaufrufe im Template laufen bei jedem Rendern erneut.

9:32 Und der vierte ist eine Abgrenzung: Formatierung ist Aufgabe von Pipes, Fachlogik nicht.

Fachlogik aus der Komponentenklasse heraushalten

9:37 Das letzte Kapitel schließt den Kreis zum Anfang des Moduls. Wir haben die Logik aus dem Template in die Klasse geholt — und jetzt kommt die unbequeme Nachfrage: Ist die Klasse denn der richtige Ort? Für einen Teil davon nämlich nicht. Denn eine Rechenregel, die vorher im Template stand, ist in der Klasse zwar besser aufgehoben — aber noch nicht am richtigen Ort. Die letzte Etappe führt in die Service-Schicht.

10:02 Auch in der Komponentenklasse gehört nur, was mit Darstellung und Interaktion zu tun hat. Rabatte, Steuersätze, Gültigkeitsregeln — das sind Aussagen über das Geschäft, nicht über die Ansicht. Die Prüffrage ist einfach und erstaunlich zuverlässig: Würde diese Regel auch dann gelten, wenn es diese Seite gar nicht gäbe? Ein Mengenrabatt ab zehn Stück gilt auch am Telefon und in der Rechnungsstellung.

10:25 Er hat also mit dem Warenkorb-Bildschirm nichts zu tun — und gehört deshalb dorthin, wo die Fachlichkeit wohnt. In der oberen Fassung stecken zwei Geschäftsentscheidungen als nackte Zahlen mitten im Komponentencode: fünf Prozent Rabatt ab zehn Stück, neunzehn Prozent Steuer. Beides wird sich irgendwann ändern — Steuersätze tun das bekanntermaßen. Und dann sucht jemand in Komponenten nach Zahlen. Unten steht ein Wert, der aus dem Service kommt.

10:51 Die Regel liegt damit an einer Stelle, an der man sie vermutet, und die Komponente tut wieder nur das, wofür sie da ist: anzeigen, was ihr gesagt wird. Der erste Punkt ist der praktische: Dieselbe Regel wird an mehreren Stellen gebraucht — im Warenkorb, in der Kasse, in einer Bestellübersicht. Der zweite ist der, der die Arbeit erleichtert: Fachregeln lassen sich ohne Rendern testen, und Tests, die kein Rendering brauchen, laufen schnell und brechen selten aus falschen Gründen.

11:19 Der vierte Punkt ist der, der am Ende zählt: Wenn sich ein Steuersatz ändert, betrifft das eine Stelle. Ohne diese Trennung sind es mehrere — und man findet nie ganz sicher alle. Der Hinweis auf dieser Folie ist der eigentliche Inhalt: Würde die Regel auch außerhalb dieser Ansicht gelten? Wenn ja, gehört sie in einen Service.

11:38 Diese Frage brauchen Sie im Alltag ständig, und sie ist zuverlässiger als jedes Bauchgefühl. Geschafft haben Sie es, wenn die Regel im Service liegt und Sie sie ohne Komponente testen können. Probieren Sie das wirklich aus — der Moment, in dem ein Fachtest ohne jedes Rendering durchläuft, ist ein guter Beleg dafür, dass die Trennung gelungen ist.

11:59 Der erste Punkt ist ein Muster, das man in vielen Projekten findet: Lebenszyklus-Methoden als Sammelstelle. Was beim Start passieren soll, landet dort — und irgendwann steht die halbe Fachlogik darin. Der zweite ist der teuerste: dieselbe Regel an drei Stellen, leicht unterschiedlich. Solche Fehler findet man erst, wenn ein Kunde sich beschwert. Der dritte sind die nackten Zahlen im Code.

12:22 Und der vierte ist eine Mahnung zur Sorgfalt: Auslagern heißt nicht verschieben. Wenn der Name und der Schnitt nicht stimmen, haben Sie das Problem nur umgezogen. Vier Sätze für das ganze Modul. Eine Verantwortung je Einheit — und genau das ist der Grund, warum Services in Angular eine eigene Schicht sind und nicht bloß eine Ablage.

12:42 Kleine, benannte Funktionen machen Abläufe lesbar, ohne dass man in die Details muss. Templates zeigen Struktur, Entscheidungen über die Darstellung trifft die Klasse. Und Fachlogik gehört in Services, wo sie testbar und wiederverwendbar ist. Nichts davon ist neu, nichts davon ist Angular-spezifisch — und trotzdem entscheidet es darüber, ob eine Codebasis nach zwei Jahren noch angenehm zu ändern ist.

Danke!

13:07 Damit ist das Seminar durch. Wir sind einen weiten Weg gegangen: von den Voreinstellungen des Frameworks über Standalone Components und den Style Guide, durch die Architekturstufen von der Feature-Shell bis zu den Micro-Frontends, über State Management und Performance bis zu diesen Grundlagen. Ein Gedanke zieht sich durch alles: mit der einfachsten Lösung anfangen und erst wechseln, wenn ein benennbarer Schmerz das rechtfertigt.

13:30 Der Angular Style Guide lohnt eine Wiedervorlage — einmal im Jahr durchblättern, es ändert sich mehr, als man denkt. Vielen Dank fürs Mitmachen.