React-Projektstruktur und Best Practices

React-Projektstruktur und Best Practices

0:00 Bis hierhin ging es darum, wie React funktioniert. Jetzt geht es um etwas anderes: wie man damit ein Projekt baut, das auch in einem Jahr noch angenehm zu ändern ist. Das ist eine andere Sorte Wissen — weniger Technik, mehr Erfahrung. Und es ist die Sorte, die man normalerweise schmerzhaft erwirbt, wenn eine Anwendung langsam unübersichtlich wird und niemand mehr weiß, wo etwas hingehört.

0:23 Heute nehmen wir uns diese Erfahrung vor, bevor sie Sie einholt: Struktur, Wiederverwendbarkeit und sauberer Code.

Projektstruktur und Best Practices

0:30 Vier Blöcke liegen vor uns. Zuerst geht es um Komponenten — wie man sie schneidet und wiederverwendbar macht. Dann um die Ebene darüber: Ordnerstruktur und die Trennung von Darstellung und Logik. Der dritte Block ist der handwerkliche — Fehlerbehandlung, Fehlersuche und Performance. Und zum Schluss Clean Code und die typischen Fallstricke. Ein Hinweis vorab: Das meiste davon sind Leitplanken, keine Gesetze.

0:55 Wer Best Practices dogmatisch anwendet, richtet oft mehr Schaden an als wer sie gar nicht kennt. Drei Fragen, und die mittlere ist die interessanteste. Wie groß war Ihr bisher größtes React-Projekt? Woran ist Code für Sie schwer wartbar geworden — was war der Moment, an dem Sie gemerkt haben, dass es zäh wird? Und was möchten Sie heute konkret mitnehmen?

1:16 Wenn Sie zu Frage zwei eine Geschichte haben, erzählen Sie sie gern. Solche Erfahrungen sind für den ganzen Kurs wertvoller als jede Folie, weil sie zeigen, dass diese Themen keine akademischen Fragen sind.

Komponenten sinnvoll strukturieren

1:29 Beginnen wir bei der kleinsten Einheit. Die Frage, wie groß eine Komponente sein darf und wo man sie teilt, klingt banal — und ist tatsächlich die Entscheidung, die sich am häufigsten wiederholt. Eine gut strukturierte Komponente hat genau eine klar umrissene Aufgabe. Wird sie zu groß oder vermischt sie mehrere Belange, teilt man sie auf.

1:49 Das ist im Kern das altbekannte Prinzip der einen Verantwortung, nur auf Oberflächen angewendet. Die praktische Frage lautet: Kann ich in einem Satz sagen, was diese Komponente tut — ohne ein „und" darin? Sobald das „und" auftaucht, stecken meist zwei Komponenten drin. Das ist eine erstaunlich verlässliche Prüfung, und sie kostet Sie fünf Sekunden.

2:11 Vier Effekte. Kleine Komponenten sind leichter zu lesen und zu testen — man hält sie im Kopf, ohne zu scrollen. Eine klare Verantwortung erleichtert Änderungen, weil man weiß, wo man anfassen muss und wo nicht. Wiederverwendung wird überhaupt erst durch Fokus möglich: Eine Komponente, die vier Dinge tut, passt nirgendwo sonst hin.

2:31 Und Fehler lassen sich schneller eingrenzen — wenn eine Komponente eine Aufgabe hat, ist die Frage „wer ist schuld" meist mit einem Blick beantwortet. Das sind keine ästhetischen Argumente, das sind Zeitersparnisse. Vier Schritte, wobei der zweite der wichtigste ist: Trennen Sie reine Darstellung von der Datenbeschaffung.

2:50 Diese Grenze verläuft in fast jeder Anwendung an derselben Stelle und ist der ergiebigste einzelne Schnitt. Ansonsten: an Verantwortlichkeiten entlang aufteilen, wiederkehrendes Markup herausziehen und allem einen sprechenden Namen geben. Und dazu die Fußzeile mit einer sehr brauchbaren Faustregel: Passt eine Komponente nicht auf einen Bildschirm, ist sie zu groß.

3:11 Das ist grob, aber es funktioniert erstaunlich gut als erstes Signal. Was Sie hier sehen, ist das Ergebnis, nicht der Weg. Die äußere Komponente arrangiert nur noch — sie sagt, was zusammengehört, und überlässt das Wie den Teilen. Diese Form nennt man gelegentlich eine Kompositionskomponente, und sie ist ein gutes Ziel: Wenn Ihre oberste Komponente nur noch aus Zusammensetzung besteht, haben Sie sauber geschnitten.

3:35 Worauf es ankommt: Die Aufteilung folgt der Bedeutung, nicht der Zeilenzahl. Ein Ausschnitt, der eine eigene Sache darstellt, wird eine eigene Komponente — auch wenn er nur drei Zeilen hat. Nehmen Sie eine überladene Komponente — gern eine aus Ihrem eigenen Projekt, sonst eine aus den Übungen — und zerlegen Sie sie. Mindestens zwei fokussierte Komponenten mit klaren Namen sollen entstehen.

3:59 Das eigentliche Lernziel steckt in der Vorarbeit: Schreiben Sie sich vorher auf, welche Aufgaben die Komponente derzeit erfüllt. Diese Liste ist Ihr Schnittmuster. Wenn Sie beim Aufschreiben merken, dass drei Punkte dastehen, wissen Sie bereits, dass es keine Komponente war, sondern drei. Und hier die Gegenrichtung, die genauso wichtig ist. Zu früh zu zerlegen erzeugt unnötige Abstraktion — man hat dann fünf Dateien für etwas, das in einer übersichtlich war.

4:26 Der beste Zeitpunkt ist meist der zweite oder dritte Verwendungsfall, nicht der erste. Zweitens: Teilkomponenten ohne klaren Namen verschleiern die Absicht; etwas „Container" oder „Wrapper" zu nennen, verschiebt das Problem nur. Und drittens ein sehr nützliches Signal: Zu viele Props deuten auf einen falschen Schnitt hin. Wenn eine Komponente zehn Eigenschaften braucht, stimmt meist die Grenze nicht.

Wiederverwendbare Komponenten entwickeln

4:51 Aus dem richtigen Schnitt folgt die Wiederverwendbarkeit fast von selbst. Fast — denn dazwischen liegt noch eine Entscheidung, die viele Teams falsch treffen. Eine wiederverwendbare Komponente kapselt Aussehen und Verhalten so, dass sie über Eigenschaften an verschiedene Fälle angepasst werden kann. Varianten steuert man über Parameter — nicht über Kopien.

5:12 Das klingt selbstverständlich und ist es in der Praxis überhaupt nicht: Der schnellste Weg zu einem zweiten Knopf ist immer noch, den ersten zu kopieren und anzupassen. Es dauert zwei Minuten statt zwanzig. Der Preis kommt später, wenn das Erscheinungsbild sich ändert und niemand mehr weiß, wie viele Kopien es gibt. Vier zusammenhängende Punkte. Eine Quelle der Wahrheit statt vieler Kopien — daraus folgt alles Weitere.

5:36 Änderungen wirken überall gleichzeitig, was die gefürchtete Suche nach vergessenen Stellen erübrigt. Das Aussehen bleibt über die ganze Anwendung konsistent, und zwar ohne Disziplin, sondern durch Konstruktion. Und weniger Code heißt schlicht weniger Fehlerquellen. Genau deshalb hat sich in größeren Organisationen das Konzept der Komponentenbibliothek etabliert: Es ist dieselbe Idee, nur eine Ebene höher.

6:01 Ein sehr einfaches, aber vollständiges Beispiel. Die Variante kommt als Eigenschaft herein und steuert die Darstellung. Der Inhalt kommt über die Kinder, die Komponente muss also nichts über den Text wissen. Und beachten Sie den Standardwert: Man kann diesen Knopf verwenden, ohne irgendetwas zu konfigurieren. Genau das steht auch in der Fußzeile, und es ist ein unterschätztes Qualitätsmerkmal.

6:24 Eine gute Komponente funktioniert im Normalfall ohne Zutun und lässt sich für den Sonderfall anpassen — nicht umgekehrt. Bauen Sie einen solchen Knopf und setzen Sie ihn in zwei Varianten ein. Und dann, das ist der eigentlich lehrreiche Teil, versuchen Sie, eine dritte Sondervariante unterzubringen — irgendetwas, das strukturell anders ist, ein Knopf mit Symbol etwa oder mit Ladeanzeige.

6:47 Beobachten Sie, ab wann sich die Komponente dagegen sträubt. Genau dieser Punkt ist die Grenze zwischen sinnvoller Konfiguration und Überladung. Und wenn Sie ihn spüren, haben Sie das Wichtigste aus diesem Kapitel mitgenommen. Der erste Punkt ist genau die eben erlebte Grenze: Zu viele Eigenschaften machen eine Komponente schwerer nutzbar, als sie hilft.

7:08 Wenn man erst die Dokumentation lesen muss, um einen Knopf zu setzen, hat man nichts gewonnen. Zweitens der umgekehrte Fehler: fehlende Standardwerte, die jede Verwendung zur Vollkonfiguration zwingen. Und drittens die Konsequenz aus beidem: Spezialfälle nicht in eine generische Komponente hineinzwängen. Manchmal ist eine zweite Komponente die richtige Antwort — Wiederverwendung ist ein Mittel, kein Ziel.

Ordnerstrukturen

7:33 Von der einzelnen Komponente eine Ebene höher: Wie ordnet man hunderte Dateien so an, dass man findet, was man sucht? Es gibt darauf keine einzig richtige Antwort, aber es gibt eine, die mit dem Projekt mitwächst. Die Ordnerstruktur organisiert Dateien so, dass Zusammengehöriges beieinanderliegt. Zwei Ansätze sind verbreitet.

7:53 Der typbasierte sortiert nach Art — alle Komponenten hier, alle Hooks dort. Der featurebasierte sortiert nach Zweck: alles, was zu einem Bereich gehört, in einem Ordner. Das ist der Unterschied zwischen einer Werkstatt, in der alle Schrauben in einer Kiste liegen, und einer, in der pro Projekt eine Kiste bereitsteht. Bei zwanzig Teilen ist das erste besser. Bei zweitausend ganz sicher das zweite.

8:18 Vier Punkte. Zusammengehöriges schnell wiederzufinden ist der offensichtliche — und im Alltag rechnet sich das in Minuten pro Tag. Neue Teammitglieder finden sich schneller zurecht, weil die Struktur die Fachlichkeit widerspiegelt statt der Technik. Feature-Ordner skalieren besser mit wachsender Anwendung, weil neue Bereiche einfach danebengelegt werden, statt vier bestehende Ordner anwachsen zu lassen.

8:41 Und klare Grenzen verhindern ungewollte Abhängigkeiten: Wenn ein Bereich in den anderen hineingreift, sieht man es am Importpfad. Hier sehen Sie eine typische Aufteilung. Im Feature-Ordner liegt alles zusammen, was zu einem Bereich gehört — die Komponenten, die Logik, der Zugriff auf die Schnittstelle. Daneben zwei geteilte Bereiche: die allgemeine Oberfläche und die Hilfsfunktionen. Worauf es ankommt: Diese beiden geteilten Ordner sind bewusst klein zu halten.

9:08 Sie sind der Ort für das, was wirklich überall gebraucht wird, nicht der Sammelplatz für alles, was gerade nirgendwo hinpasst. Und die Fußzeile ist ehrlich: Bei kleinen Projekten reicht typbasiert völlig. Nehmen Sie ein bestehendes Projekt und bündeln Sie die Dateien eines Features in einem gemeinsamen Ordner. Die App soll danach unverändert laufen.

9:29 Das klingt nach Fleißarbeit und hat einen konkreten Erkenntniswert: Beim Verschieben merken Sie, wo Abhängigkeiten quer durch das Projekt laufen, die Sie nicht erwartet hätten. Notieren Sie diese Stellen. Genau dort liegen später die Probleme — nicht in der Ordnerstruktur selbst, sondern in den Verbindungen, die sie sichtbar macht.

9:48 Drei Punkte. Zu tiefe Verschachtelung erschwert die Navigation — ab der vierten Ebene sucht man wieder. Zweitens: Geteiltes und Feature-Spezifisches nicht vermischen; sobald etwas Feature-Eigenes im geteilten Ordner landet, verliert die Trennung ihren Wert. Und der dritte Punkt ist mir der wichtigste: Struktur nicht dogmatisch erzwingen, sondern mitwachsen lassen.

10:09 Ein Projekt am ersten Tag mit zwölf Ordnern anzulegen, ist Planwirtschaft. Fangen Sie flach an und teilen Sie, wenn es unübersichtlich wird — das ist ein deutlich verlässlicherer Indikator als jede Vorabplanung.

Trennung von UI und Logik

10:22 Jetzt zu einem Schnitt, der quer zu den bisherigen liegt — und der aus meiner Sicht den größten einzelnen Unterschied in der Wartbarkeit macht. Darstellung und Logik zu trennen heißt: Zustands- und Datenlogik aus der Komponente herauslösen, typischerweise in eigene Hooks. Die Komponente kümmert sich dann nur noch ums Rendern. Denken Sie an ein Restaurant: Im Gastraum sieht man das Anrichten und Servieren, die Küche liegt dahinter.

10:46 Beides muss zusammenspielen, aber niemand kocht zwischen den Tischen. Der praktische Gewinn ist, dass Sie die Küche umbauen können, ohne den Gastraum anzufassen — und dass Sie sie prüfen können, ohne den Gastraum überhaupt zu betreten. Vier Punkte, und der erste ist der stärkste: Logik lässt sich unabhängig von der Oberfläche testen.

11:06 Ein Test für einen Hook braucht kein Rendern, kein Klicken, kein Warten — er ruft eine Funktion auf. Zweitens: Dieselbe Logik ist in mehreren Komponenten wiederverwendbar, auch in ganz unterschiedlich aussehenden. Drittens bleiben Komponenten schlank und lesbar; wer eine Komponente öffnet, sieht auf einen Blick, was angezeigt wird.

11:26 Und viertens: Änderungen an der Logik berühren das Markup nicht — zwei Aufgaben, zwei Orte, weniger Konflikte im Team. Hier sehen Sie die Trennung im Kleinen. Oben der Hook mit dem gesamten Verhalten — Zustand und die Funktion, die ihn ändert. Unten die Komponente, die davon nur noch Gebrauch macht. Beachten Sie, dass die Komponente selbst kein einziges Mal weiß, wie gezählt wird.

11:50 Man könnte die Zählweise komplett umbauen, ohne diese Zeile anzufassen. Worauf es ankommt: Der Hook gibt ein Objekt zurück, keine Darstellung. Sobald in einem Hook Markup auftaucht, ist die Grenze verwischt — dann haben Sie in Wahrheit eine Komponente geschrieben. Nehmen Sie eine Komponente mit Zustandslogik und ziehen Sie diese in einen eigenen Hook.

12:11 Das Erfolgskriterium ist schön überprüfbar: In der Komponente darf danach kein Zustands-Hook mehr direkt vorkommen. Wenn Sie fertig sind, machen Sie die Probe aufs Exempel — bauen Sie eine zweite Komponente, die völlig anders aussieht und denselben Hook nutzt. Wenn das ohne Anpassung funktioniert, war die Trennung sauber. Wenn nicht, steckt noch ein Rest Darstellung in der Logik, und den zu finden ist die eigentliche Übung.

12:36 Der Namenspräfix steht wieder oben, weil ohne ihn die Hook-Regeln und die Werkzeugunterstützung nicht greifen. Zweitens ein Maßhinweis: Nicht jede Zeile Logik braucht einen eigenen Hook. Drei Zeilen Zustand in einer Komponente sind völlig in Ordnung; das Auslagern lohnt sich, wenn die Logik eigenständig ist oder mehrfach gebraucht wird.

12:55 Und drittens der Punkt von eben: Oberflächendetails gehören nicht in den Logik-Hook. Ein Hook, der Klassennamen oder Texte zurückgibt, hat die Grenze bereits überschritten.

Fehlerbehandlung

13:06 Kommen wir zu dem Teil, den man in Demos nie sieht und in Produktion immer braucht. Was passiert eigentlich, wenn etwas schiefgeht? Fehlerbehandlung in React sorgt dafür, dass ein Fehler nicht die ganze Anwendung mitreißt. Dabei gibt es zwei getrennte Welten, und das ist der wichtigste Punkt des Kapitels: Fehler beim Rendern fängt eine sogenannte Error Boundary ab — eine Komponente, die sich um ihre Kinder legt.

13:30 Fehler in asynchronem Code dagegen fängt sie nicht; die behandeln Sie klassisch und zeigen einen Fehlerzustand an. Diese Unterscheidung überrascht regelmäßig, weil man intuitiv annimmt, die Boundary sei ein Auffangnetz für alles. Ist sie nicht. Vier Punkte. Ein Fehler in einer Komponente reißt nicht die ganze Anwendung mit — ohne Behandlung zeigt React nämlich lieber gar nichts als etwas Kaputtes, und das heißt: weißer Bildschirm.

13:55 Nutzer sehen stattdessen eine verständliche Meldung. Fehlerzustände lassen sich gezielt gestalten, mit einer Möglichkeit zum erneuten Versuch etwa. Und der vierte Punkt richtet sich an Sie selbst: Probleme werden sichtbar, statt still verschluckt zu werden. Ein Fehler, den niemand meldet, existiert für die Fehlerstatistik nicht — und wird deshalb nie behoben.

14:16 Das Muster kennen Sie aus dem JavaScript-Modul, hier mit React-Bezug. Wichtig ist die Prüfung in der zweiten Zeile: Eine Antwort vom Server ist nicht automatisch eine erfolgreiche. Und dann das Entscheidende im Auffangzweig — der Fehler wird nicht nur protokolliert, sondern in den Zustand geschrieben. Genau das macht ihn für die Oberfläche sichtbar.

14:37 Worauf es ankommt, steht in der Fußzeile: Die Error Boundary greift hier nicht. Sie fängt nur, was beim Rendern schiefgeht — nicht, was in einem Ereignis oder einem asynchronen Ablauf passiert. Bauen Sie einen Datenabruf, der bei einem Fehlschlag eine verständliche Meldung zeigt statt abzustürzen. Provozieren Sie den Fehler bewusst — eine falsche Adresse genügt, oder Sie schalten in den Entwicklerwerkzeugen das Netzwerk ab.

15:02 Und dann gehen Sie einen Schritt weiter: Behandeln Sie die drei Zustände getrennt — lädt, Fehler, Daten da. Sie werden feststellen, dass sich diese drei nicht sauber mit einem einzigen Wahrheitswert abbilden lassen. Diese Erkenntnis ist der Grund, warum es dafür spezialisierte Bibliotheken gibt. Der erste Punkt ist der zentrale des Kapitels und deshalb hier noch einmal: Error Boundaries greifen nicht bei asynchronem Code und nicht in Ereignisbehandlungen.

15:28 Wer sich darauf verlässt, hat ein Netz mit einem großen Loch. Zweitens: Einen Fehler nur zu protokollieren hilft dem Nutzer nicht — auf dessen Bildschirm bleibt es leer, während in der Konsole alles steht. Und drittens der Punkt aus der Übung: Lade-, Fehler- und Erfolgszustand gehören getrennt behandelt. Sonst zeigt die Oberfläche im Fehlerfall eine ewig laufende Ladeanzeige.

Debugging

15:50 Wenn dann doch etwas nicht stimmt, beginnt die Suche. Und hier ist der Unterschied zwischen erfahrenen und unerfahrenen Entwicklern selten das Wissen — sondern die Methode. Fehlersuche in React heißt, den Zustand einer laufenden Anwendung gezielt zu untersuchen. Die React-Entwicklerwerkzeuge zeigen Ihnen den Komponentenbaum, die Eigenschaften und den Zustand jeder Komponente — live, während die Anwendung läuft.

16:15 Die Browser-Konsole meldet Warnungen und Fehler. Das ist der Unterschied zwischen einem Arzt, der abhört, und einem, der rät. Der wichtigste Satz dazu steht in der Tagline: systematisch statt raten. Die häufigste ineffiziente Fehlersuche besteht darin, Dinge zu ändern und zu schauen, ob es besser wird. Vier Punkte. Die Entwicklerwerkzeuge machen Eigenschaften und Zustand jeder Komponente sichtbar — Sie müssen nicht mehr raten, was ankommt.

16:42 Warnungen in der Konsole weisen früh auf Probleme hin, oft lange bevor sie sich als Fehler zeigen. Gezieltes Beobachten schlägt zufälliges Ändern, und zwar deutlich. Und mit dem Profiler werden Ursachen für Neu-Renderings nachvollziehbar — das ist die Brücke zum nächsten Kapitel, denn ohne Messung ist jede Performanceoptimierung Kaffeesatzleserei.

17:03 Vier Schritte in sinnvoller Reihenfolge: Werkzeuge installieren und den Baum öffnen, die verdächtige Komponente ansehen, die Konsole durchgehen und erst dann gezielt Ausgaben einbauen. Beachten Sie, dass die Ausgaben ganz am Ende stehen — sie sind das gröbste Werkzeug, nicht das erste. Und die Fußzeile ist eine Anweisung, die ich gern unterstreiche: Warnungen nicht ignorieren. React warnt sparsam, aber wenn es warnt, hat es fast immer recht.

17:29 Eine Konsole voller ignorierter Warnungen ist ein Frühwarnsystem, das jemand abgeschaltet hat. In dieser Übung geht es ums Untersuchen, nicht ums Reparieren. Öffnen Sie die Entwicklerwerkzeuge und benennen Sie anhand des Baums die Komponente und den Wert, die einen Fehler verursachen — und zwar bevor Sie eine Zeile Code ändern.

17:48 Diese Reihenfolge ist die eigentliche Übung. Klicken Sie sich durch den Baum, schauen Sie sich an, welche Eigenschaften wo ankommen, und formulieren Sie eine Hypothese. Erst dann greifen Sie ein. Wer sich das angewöhnt, ist bei der Fehlersuche deutlich schneller — und zwar dauerhaft. Drei Punkte. Eine Ausgabe im Rendervorgang zeigt Ihnen, dass neu gerendert wurde, aber nicht warum — dafür brauchen Sie den Profiler.

18:13 Zweitens noch einmal die Warnungen: Sie zu ignorieren rächt sich, weil sie fast immer auf ein echtes Problem zeigen, das später als schwer reproduzierbarer Fehler zurückkommt. Und drittens der wichtigste methodische Punkt: nicht blind Code ändern, bevor die Ursache bekannt ist. Jede Änderung ohne Hypothese kann den Fehler auch nur verschieben — und dann suchen Sie beim nächsten Mal an einer Stelle, die gar nicht schuld ist.

Performance-Grundlagen

18:37 Und damit zum Thema, bei dem der wichtigste Rat vor der ersten Technik kommt: erst messen, dann optimieren. Ich sage das vorweg, weil in diesem Kapitel Werkzeuge vorkommen, die man leicht überall hinschreibt. Optimierung in React zielt darauf, unnötige Neu-Renderings und teure Berechnungen zu vermeiden. Es gibt dafür im Wesentlichen drei Werkzeuge: eines für Komponenten, eines für berechnete Werte, eines für Funktionen.

19:03 Alle drei arbeiten nach demselben Prinzip — sich ein Ergebnis merken und nur bei geänderten Abhängigkeiten neu berechnen. Das kostet allerdings selbst etwas: Vergleichsaufwand und Speicher, und vor allem Lesbarkeit. Deshalb ist das kein Werkzeug, das man vorsorglich einsetzt, sondern eines, das man gezielt anwendet. Vier Punkte. Weniger Neu-Renderings halten die Oberfläche flüssig, besonders bei langen Listen und komplexen Formularen. Teure Berechnungen laufen nur bei Bedarf erneut.

19:33 Stabile Referenzen verhindern Folge-Renderings — ein Effekt, der in der Praxis oft wichtiger ist als die Rechenzeit selbst, weil eine neu erzeugte Funktion alle Kinder mitreißen kann. Und der vierte Punkt ist der Rahmen für alle anderen: Messen zeigt, wo Optimierung sich wirklich lohnt. Meine Erfahrung ist, dass die Stelle fast nie dort liegt, wo man sie vermutet.

19:55 Ein kurzes Beispiel. Die Filterung läuft nur, wenn sich die Eingabedaten tatsächlich geändert haben — sonst kommt das gemerkte Ergebnis zurück. Wichtig ist die Abhängigkeitsliste am Ende: Sie ist der Vertrag. Was dort fehlt, wird nicht bemerkt, und Sie arbeiten mit einem veralteten Ergebnis weiter. Worauf es ankommt, steht in der Fußzeile: Voreiliges Merken bringt oft gar nichts.

20:17 Bei einer Liste mit zwanzig Einträgen ist der Vergleichsaufwand womöglich höher als die Filterung selbst — man hat dann Komplexität eingekauft und nichts gewonnen. Binden Sie eine teure Berechnung an ihre Abhängigkeiten. Damit der Effekt sichtbar wird, brauchen Sie etwas, das wirklich dauert — erzeugen Sie ruhig eine Liste mit zehntausend Einträgen.

20:38 Bauen Sie dann einen unabhängigen Zustand daneben, ein Eingabefeld etwa, und beobachten Sie im Profiler, was beim Tippen passiert: erst ohne, dann mit dem Merken. Dieser direkte Vergleich ist der Punkt der Übung. Und er zeigt zugleich, wie man später in echten Projekten vorgeht — messen, ändern, wieder messen. Drei Punkte. Voreilige Optimierung verkompliziert den Code ohne Nutzen — sie erzeugt Abhängigkeitslisten, die gepflegt werden müssen, für einen Gewinn, den niemand gemessen hat.

21:07 Zweitens sind genau diese Listen fehleranfällig: Falsche Abhängigkeiten führen zu veralteten Werten, und das ist ein besonders unangenehmer Fehler, weil alles funktioniert — nur mit alten Daten. Und drittens ein technisches Detail mit großer Wirkung: Das Merken einer Komponente hilft nur, wenn ihre Eigenschaften stabil bleiben.

21:26 Ein bei jedem Durchlauf neu erzeugtes Objekt macht den ganzen Aufwand zunichte.

Clean Code in React

21:31 Zum Abschluss das Kapitel, das am wenigsten nach Technik klingt und am meisten über den Alltag entscheidet. Denn Code wird deutlich öfter gelesen als geschrieben — meist von jemand anderem, oft von einem selbst ein halbes Jahr später. Sauberer Code heißt: Code, der ohne Erklärung verständlich ist. Sprechende Namen, kleine Komponenten, konsistente Muster, keine unnötige Wiederholung.

21:54 Das sind keine React-spezifischen Regeln, aber sie wirken hier besonders, weil React so wenig vorgibt. In einem Framework mit strengen Konventionen sieht jedes Projekt ähnlich aus. Bei React entscheidet Ihr Team — und das ist Freiheit und Verantwortung zugleich. Der beste Maßstab: Kann jemand, der das Projekt nicht kennt, in einer Datei erkennen, was hier passiert, ohne fünf andere zu öffnen?

22:19 Vier Punkte, die alle in dieselbe Richtung zeigen. Lesbarer Code spart dem Team Zeit — und das ist der mit Abstand größte Kostenfaktor in der Softwareentwicklung. Konsistente Muster senken die Einarbeitungszeit, weil man ein Muster einmal versteht statt zwanzigmal. Weniger Wiederholung bedeutet weniger Fehlerquellen, weil eine Korrektur an einer Stelle genügt. Und guter Code lässt sich leichter ändern — was der eigentliche Zweck ist.

22:45 Software wird nicht fertig; sie wird geändert. Wartbarkeit ist deshalb kein Luxus, sondern die zentrale Eigenschaft. Vier Schritte, und keiner davon ist überraschend: sprechende Namen, kleine Komponenten, Wiederholung bündeln, Muster konsistent halten. Das Bemerkenswerte ist, wie selten das konsequent gemacht wird — nicht aus Unwissen, sondern weil jeder einzelne Fall für sich harmlos wirkt.

23:08 Deshalb finde ich die Fußzeile so treffend: Schreiben Sie für die nächste Person. Das ist ein Perspektivwechsel, der mehr bewirkt als jede Regelliste — und die nächste Person sind erstaunlich oft Sie selbst. Nehmen Sie einen Codeausschnitt und räumen Sie ihn auf: unklare Namen ersetzen, Wiederholung bündeln. Und dann die eigentliche Prüfung — lassen Sie jemanden aus der Gruppe darauf schauen, der ihn nicht kennt, und fragen Sie, was der Code tut.

23:35 Wenn eine Rückfrage kommt, ist genau dort noch etwas unklar. Das ist unbequem und sehr lehrreich. Vermutlich haben Sie mehr Kontext im Kopf, als im Code steht — und genau dieser unsichtbare Kontext ist es, der später fehlt. Drei Punkte, die alle vor Übertreibung warnen. Abkürzungen in Namen sparen beim Tippen Sekunden und kosten beim Lesen Minuten.

23:56 Vorzeitige Abstraktion schadet mehr als etwas Wiederholung — das ist eine der wichtigsten Erkenntnisse überhaupt: Drei ähnliche Stellen sind besser als eine falsche Verallgemeinerung, denn die falsche Abstraktion bekommt man nur schwer wieder los. Und drittens: Uneinheitliche Muster verwirren mehr als fehlende Perfektion. Ein durchgängig mittelmäßiges Muster ist besser als zwei gute nebeneinander.

24:19 Fassen wir die Leitplanken zusammen. Eine Komponente, eine Verantwortung — und sinnvoll geschnitten, also weder zu groß noch zu früh zerlegt. Logik gehört in Hooks, die Struktur folgt den Features. Fehler werden abgefangen, die Fehlersuche läuft systematisch, und optimiert wird erst nach dem Messen. Und dann die Fußzeile, die mir wichtig ist: Das sind Leitplanken, keine Dogmen.

24:42 Jede dieser Regeln hat Fälle, in denen das Gegenteil richtig ist — der Unterschied ist, ob man sie bewusst bricht oder aus Unkenntnis. Und die Gegenliste, sozusagen die vier häufigsten Wege, sich das Leben schwer zu machen. Zu früh abstrahieren, bevor das Muster klar ist. Logik und Darstellung in einer riesigen Komponente vermengen. Warnungen in der Konsole ignorieren. Und optimieren, ohne vorher zu messen.

25:08 Was diese vier verbindet: Alle fühlen sich im Moment produktiv an. Das ist das Tückische — sie sehen nicht wie Fehler aus, sondern wie Fortschritt. Deshalb lohnt es sich, diese Liste im Hinterkopf zu behalten, wenn man das nächste Mal besonders schnell vorankommt.

Danke!

25:24 Damit sind wir am Ende dieses Moduls. Alle Materialien liegen in der Freigabe. Wenn Sie eine Sache mitnehmen, dann bitte das Prinzip hinter allem: Struktur ist kein Selbstzweck, sondern Vorbereitung auf Änderungen, die Sie noch nicht kennen. Bei Fragen erreichen Sie uns unter der angegebenen Adresse. Im nächsten und letzten Modul wird es konkret — wir bringen React in die Atlassian-Forge-Umgebung und bauen gemeinsam eine kleine App. Vielen Dank fürs Mitmachen.