Sauberer Code und fremden Code lesen

JavaScript — Sauberer Code

0:00 Wir sind beim letzten Modul angekommen, und es enthält kein neues Sprachfeature mehr. Es geht um das, was aus funktionierendem Code guten Code macht. Der Leitsatz dazu ist einfach und wird trotzdem täglich ignoriert: Code wird einmal geschrieben und viele Male gelesen. Und der wichtigste Leser sind Sie selbst, in drei Monaten, wenn Sie nicht mehr wissen, was Sie sich dabei gedacht haben.

0:22 In diesem Modul geht es um Wartbarkeit, um das Lesen fremden Codes, um Werkzeuge — und am Ende um die Frage, wie es für Sie weitergeht.

Für die nächsten Leser schreiben

0:30 Sieben Kapitel zum Abschluss. Zuerst die vier Hebel, die Code wartbar machen. Dann das vielleicht praktischste Kapitel des ganzen Kurses: ein systematischer Weg durch fremden Code. Danach eine Ehrenrettung und zugleich Warnung zum Thema Abdeckung. Linter und Formatierer klären zwei Werkzeuge, die oft verwechselt werden.

0:50 Refactoring mit Sicherheitsnetz führt Tests und Umbau zusammen. Die Kompatibilitäts-Checkliste schließt den Bogen zum ersten Modul. Und zum Schluss der Ausblick — welche Wege sich jetzt öffnen.

Was Code wartbar macht

1:02 Beginnen wir mit dem Grundsatz, der über allem steht: Klarheit schlägt Kürze. Am Ende dieses Kapitels steht ein Prüfsatz, der eigentlich das ganze Modul zusammenfasst — eine einzige Frage, die man sich vor jedem Absenden stellen kann. Wartbarer Code lässt sich lesen, ändern, testen und erweitern — von anderen, nicht nur von Ihnen.

1:22 Vier Zutaten nennt die Definition: sprechende Namen, kleine Funktionen mit einer Aufgabe, klare Modulgrenzen und der Verzicht auf unnötige Findigkeit. Der letzte Punkt verdient ein Wort. Findigkeit ist beim Programmieren verlockend — man löst etwas besonders raffiniert und ist zu Recht stolz. Aber raffiniert heißt oft: Man muss den Kniff kennen, um es zu verstehen. Und der nächste Leser kennt ihn nicht. Was Sie an Zeilen sparen, zahlt er in Minuten.

1:51 Vier Hebel, und jeder lässt sich in einem Satz prüfen. Namen: Variablen beschreiben Werte, Funktionen beschreiben Verhalten — deshalb das Verb am Anfang von Funktionsnamen. Größe: Eine Funktion tut eine Sache, sonst ist sie zwei Funktionen. Der Prüftest ist das Wörtchen „und" in ihrer Beschreibung. Grenzen: Formatierung formatiert, Prüfung prüft, Datenzugriff greift zu — genau die Aufteilung aus dem letzten Modul.

2:17 Und Dopplung: Dieselbe Regel an fünf Stellen wird irgendwann viermal geändert. Nicht aus Nachlässigkeit, sondern weil niemand die fünfte Stelle kannte. Der Vergleich ist kurz und deutlich. Oben eine Funktion, deren Kommentar schon das Problem beschreibt: Sie prüft, formatiert, schreibt und protokolliert. Vier Aufgaben, ein Name — und dieser Name kann unmöglich alle vier beschreiben, weshalb er so vage ausfällt.

2:44 Unten dieselbe Arbeit, verteilt auf drei Funktionen, deren Namen jeweils genau sagen, was passiert. Der Fußtext liefert den Prüftest in Form einer Aufzählung. Wenn Sie beim Erklären einer Funktion eine Aufzählung brauchen, ist sie zu groß. Und der Nebeneffekt: Jede der drei Funktionen ist jetzt einzeln testbar. Machen Sie aus einer Funktion mit mehreren Aufgaben drei benannte Funktionen — bei identischem Verhalten, und jede einzeln aufrufbar.

3:11 Diese Auflage kennen Sie inzwischen aus jedem Umbau-Auftrag dieses Kurses. Der Hinweis enthält den angekündigten Prüfsatz, und ich möchte ihn Ihnen wirklich mitgeben: Wird das für jemanden verständlich sein, der es später liest? Diese eine Frage ersetzt eine ganze Stilfibel. Stellen Sie sie sich, bevor Sie Code abgeben — und beantworten Sie sie ehrlich, nicht wohlwollend.

3:34 Kürze mit Klarheit zu verwechseln, ist der Grundfehler dieses Kapitels — weniger Zeichen heißt nicht weniger Denkarbeit für den Leser. Verschachtelte ternäre Ausdrücke sind das Paradebeispiel dafür: Sie passen in eine Zeile und brauchen drei Minuten Entzifferung. Dieselbe Regel mehrfach umzusetzen, ist die Dopplung aus den vier Hebeln — sie rächt sich immer erst später.

3:55 Und der vierte Punkt betrifft eine Angewohnheit aus Zeiten schmaler Bildschirme: Namen zu kürzen, bis der Leser raten muss. Tippen ist billig, Raten ist teuer.

Fremden Code lesen

4:05 Jetzt kommt das aus meiner Sicht praktischste Kapitel dieses Moduls. Denn im Berufsalltag lesen Sie deutlich mehr fremden Code, als Sie eigenen schreiben. Und ein systematischer Einstieg spart dabei buchstäblich Stunden — beginnend mit einer Datei, die viele überblättern. Fremden Code zu lesen ist Alltagsarbeit — bei einem Fehler, in einem Review, beim Einstieg in ein neues Projekt.

4:28 Der zweite Satz enthält den Rat, der den Unterschied macht: systematisch vorgehen statt sich in Details zu verlieren. Der typische Fehler ist nämlich, irgendeine Datei zu öffnen und von dort aus in die Tiefe zu wandern. Nach zwanzig Minuten hat man fünf Dateien offen, versteht drei Funktionen im Detail und immer noch nicht, worum es geht.

4:47 Das folgende Vorgehen dreht die Richtung um: von außen nach innen. Fünf Schritte, und Schritt eins ist der, den fast alle überspringen: die Projektdatei lesen. Dort stehen die Skripte — also wie man das Ding überhaupt startet —, das Modulsystem und die Abhängigkeiten. Aus dem Startskript ergibt sich der Einstiegspunkt, und den lesen Sie ganz. Dann folgen Sie den Importen einzeln, nicht alles gleichzeitig.

5:11 Schritt vier ist ein guter Kniff: Was ein Modul exportiert, ist seine Schnittstelle — das genügt fürs Erste. Und Schritt fünf verfolgt den Datenfluss. Der Fußtext entlastet Sie: Nicht exportierte Funktionen sind Interna und müssen beim ersten Lesen nicht verstanden werden. Vier Fundorte, die man leicht übersieht. Tests zeigen, welches Verhalten beabsichtigt ist — sie sind oft die ehrlichste Dokumentation eines Projekts, weil sie nicht veralten können.

5:39 Kommentare erklären Absichten; das ist die Regel aus Modul zwei, jetzt aus Lesersicht. Die Linter-Konfiguration verrät die Konventionen des Teams, bevor Sie sie durch Kritik im Review lernen. Und der vierte Punkt ist eine Haltungsfrage, die im Team viel ausmacht: Alte Muster sind Bestand, kein Fehler. Wer als Neuer ankommt und alles modernisieren will, macht sich selten Freunde — und übersieht oft den Grund.

6:05 Benennen Sie für ein fremdes Projekt Einstiegspunkt, Modulsystem, drei Zuständigkeiten und den Weg der Daten von der Quelle bis zur Ausgabe. Das ist ein realistischer erster Arbeitstag in einem neuen Projekt, komprimiert auf eine Übung. Der Hinweis ist wichtig: Nehmen Sie ein kleines Projekt aus dem Netz. Die eigenen Kursdateien sind zu vertraut — Sie wissen ja schon alles über sie und würden den Effekt nicht erleben. Suchen Sie sich etwas Überschaubares, keine große Bibliothek.

6:33 Das ganze Projekt auf einmal verstehen zu wollen, ist der Weg in die Frustration — niemand tut das, auch die erfahrenen Kollegen nicht. Bei der Projektdatei anzufangen und die Skripte zu überspringen, verschenkt genau die Information, die man zuerst braucht. Alte Muster für Fehler zu halten und ungefragt umzuschreiben, ist die Haltungsfrage von eben, jetzt als Warnung.

6:54 Und der vierte Punkt ist Bequemlichkeit mit Folgen: den Datenfluss zu raten, statt ihn Datei für Datei zu verfolgen. Geraten wird meistens plausibel und manchmal falsch.

Tests und Abdeckung

7:05 Jetzt zurück zum Testen, mit einer Kennzahl, die wir im elften Modul kurz eingeordnet haben. Hier sehen wir das Gegenbeispiel, das den Kern trifft: ein Test, der eine Zeile grün färbt und dabei nichts beweist. Abdeckung misst, welcher Code während der Tests ausgeführt wurde. Das ist eine wertvolle Information — sie zeigt Lücken.

7:25 Aber sie sagt nichts darüber, ob die Tests das Verhalten tatsächlich geprüft haben. Der Unterschied ist der zwischen „jemand war da" und „jemand hat kontrolliert". Ein Wachmann, der jede Tür passiert, ohne hinzusehen, hat hundert Prozent Abdeckung. Genau deshalb ist die Zahl als Ziel gefährlich: Sie lässt sich erfüllen, ohne dass irgendetwas besser wird — und schafft dabei ein trügerisches Sicherheitsgefühl.

7:49 Hier ist der Beweis. Beide Tests führen dieselbe Zeile aus, beide färben sie im Bericht grün. Der obere prüft aber nichts — er ruft die Funktion auf und schaut nicht hin. Er schlägt niemals fehl, egal was die Funktion zurückgibt. Der untere prüft das Ergebnis. Und der Fußtext nennt den entscheidenden Unterschied: Nur die untere Fassung schlägt fehl, wenn jemand den Rückgabewert ändert.

8:13 Genau darin besteht der Wert eines Tests — er merkt, wenn sich etwas ändert, das sich nicht ändern sollte. Ein Test ohne Zusicherung ist Beschäftigung, kein Schutz. Damit wir fair bleiben: Abdeckung hat einen echten Nutzen. Sie zeigt zuverlässig, welche Zweige nie ausgeführt wurden — und ungetestete Zweige sind genau die Stellen, an denen sich Fehler verstecken.

8:36 Der Bericht markiert ungenutzte Zeilen und macht diese Lücken sichtbar. Als Landkarte ist sie also hervorragend. Als Zielgröße verleitet sie zu leeren Tests, weil man dann optimiert, was gemessen wird, statt was zählt. Der letzte Punkt bringt es auf den Punkt: Was schützt, sind die Zusicherungen — nicht die Prozentzahl. Finden Sie einen ungetesteten Zweig und schließen Sie ihn mit einem aussagekräftigen Test.

9:01 Und dann kommt die Gegenprobe, die den ganzen Punkt dieses Kapitels ausmacht: Ändern Sie den Rückgabewert dieses Zweigs, und der neue Test muss fehlschlagen. Der Hinweis sagt es klar — die Gegenprobe ist der Beweis. Ohne sie wissen Sie nicht, ob Ihr Test etwas prüft. Es ist dieselbe Logik wie beim roten Test vor der Korrektur aus Modul elf: Ein Test, den Sie nie haben scheitern sehen, ist ein Versprechen ohne Deckung.

9:26 Eine Abdeckungszahl als Qualitätsziel vorzugeben, ist der klassische Managementfehler — und die Folge ist der zweite Punkt: Tests ohne Zusicherung, geschrieben, um eine Zahl zu heben. Der dritte Punkt ist technischer: Nur Zeilen zu betrachten und Zweige zu übersehen. Eine Zeile mit einer Bedingung kann als ausgeführt gelten, obwohl nur einer der beiden Wege je genommen wurde.

9:47 Und der vierte ist die verschenkte Chance: den Bericht erzeugen, aber nie hineinschauen. Dann haben Sie die Landkarte gedruckt und nicht aufgeschlagen.

Linter und Formatierer

9:57 Jetzt zwei Werkzeuge, die im Alltag oft in einem Atemzug genannt und dabei verwechselt werden. Sie haben ganz verschiedene Aufgaben: Der eine findet mögliche Fehler, der andere beendet Stildebatten. Beides ist wertvoll, und beides ist nicht dasselbe. Ein Linter liest den Quelltext und meldet Auffälligkeiten anhand von Regeln — und wichtig: Der Code bleibt lauffähig.

10:20 Er sagt nicht „das ist falsch", sondern „das sieht verdächtig aus". Eine ungenutzte Variable etwa ist völlig legal und trotzdem meistens ein Hinweis auf etwas Unfertiges. Ein Formatierer dagegen schreibt den Quelltext neu, in einem einheitlichen Stil, ohne die Bedeutung zu ändern. Er sucht nichts, er ordnet. Diese Trennung sollte man sauber halten — wer vom Formatierer erwartet, dass er Fehler findet, wird enttäuscht.

10:46 Drei Zeilen, drei Zuständigkeiten. Der Linter meldet mögliche Fehler und Projektregeln. Der Formatierer vereinheitlicht Einrückung, Umbrüche, Anführungszeichen — alles, worüber Teams sonst in Reviews diskutieren. Und die dritte Zeile ist die Erinnerung daran, wie wenig die Engine eigentlich prüft: Sie akzeptiert oder verwirft, mehr nicht.

11:07 Alles zwischen „läuft" und „ist gut" liegt in Ihrer Verantwortung — und dafür gibt es diese Werkzeuge. Der Fußtext fasst die Rollen in einem Satz: Der Linter sagt „das sieht nach einem Fehler aus", der Formatierer beendet die Stildiskussion. Zwei Skripteinträge, mehr braucht es nicht für den Einstieg. Beachten Sie den Unterschied in den Befehlen: Der Linter prüft und meldet, der Formatierer schreibt tatsächlich um — dafür steht der Schalter.

11:34 Das ist auch der Grund, warum man den Formatierer erst laufen lässt, wenn der Stand in der Versionsverwaltung liegt. Der Fußtext beschreibt die Praxis: In echten Projekten laufen beide zusätzlich im Editor — der Formatierer beim Speichern, der Linter beim Tippen. Dann korrigiert sich die Formatierung von selbst, und Sie denken nie wieder darüber nach.

11:54 Lassen Sie den Linter eine ungenutzte Variable melden, entfernen Sie sie — und lassen Sie den Formatierer eine unsauber eingerückte Datei aufräumen, ohne dass sich das Verhalten ändert. Damit erleben Sie beide Rollen einmal getrennt. Der Hinweis enthält einen Punkt, der in Reviews immer wieder auftaucht: Eine ungenutzte Variable ist toter Code, und die richtige Behebung ist Löschen, nicht Verwenden.

12:16 Sie irgendwo einzubauen, damit die Meldung verschwindet, ist eine Symptombehandlung — und macht den Code schlechter statt besser. Linter-Meldungen pauschal abzuschalten, ist die verbreitetste Form, ein Werkzeug wirkungslos zu machen — einzelne begründete Ausnahmen sind in Ordnung, ganze Regelgruppen abzuschalten selten.

12:35 Den Formatierer für einen Fehlerfinder zu halten, ist die Verwechslung aus der Definition. Formatierung von Hand zu pflegen und in Reviews darüber zu diskutieren, ist verschwendete Zeit — genau dafür gibt es das Werkzeug. Und der vierte Punkt ist die Symptombehandlung aus der Aufgabe: eine ungenutzte Variable künstlich zu verwenden, nur damit die Meldung weggeht.

Refactoring mit Sicherheitsnetz

12:56 Jetzt führen wir zwei Themen zusammen, die Sie einzeln schon kennen: Umbauen und Testen. Der Begriff Refactoring ist dabei präziser, als er im Alltag verwendet wird — und die Reihenfolge der Schritte ist nicht verhandelbar. Refactoring ändert die Struktur des Codes, ohne sein Verhalten zu ändern. Der zweite Satz nennt den Nachweis, und der ist entscheidend: Tests, die vorher grün waren und hinterher unverändert grün sind.

13:21 Ohne diesen Nachweis ist es kein Refactoring — es ist ein Umbau mit Hoffnung. Der Unterschied ist nicht akademisch. Im Alltag heißt „ich refactore mal eben" oft: Ich ändere Struktur und Verhalten gleichzeitig und merke es nicht. Und wenn dann etwas kaputt ist, weiß niemand, welche der zwanzig Änderungen es war. Fünf Schritte, und Schritt eins ist die Eintrittskarte: grüner Ausgangsstand.

13:46 Schritt zwei behandelt den Normalfall in echten Projekten — es gibt kein Netz, also spannt man erst eines. Tests für das aktuelle Verhalten zu schreiben, bevor man es ändert, fühlt sich zäh an und ist die einzige seriöse Vorgehensweise. Dann eine Änderung, Tests, nächste Änderung. Betonung auf eine. Der Fußtext nennt den Grund: Wird der Umbau groß, ist der Fehler beim Fehlschlag schwer zu lokalisieren. Bei einer Änderung wissen Sie sofort, welche es war.

14:14 Ein hübsches kleines Beispiel für das Muster, das man am häufigsten findet. Oben eine verschachtelte Bedingung, die am Ende nur wahr oder falsch liefert. Der Fußtext trifft es genau: Die Verschachtelung diente allein dazu, einen Wahrheitswert zu erzeugen — und dafür gibt es das logische Und. Unten steht dieselbe Aussage als ein Ausdruck. Fünf Zeilen werden zu zwei, und die Lesbarkeit gewinnt sogar. Wichtig ist die Beschriftung: Die Tests bleiben grün.

14:42 Genau das unterscheidet diesen Umbau von einer Verschlimmbesserung, die man nur für eine hält. Drei Tests vor dem Umbau grün, die Funktion danach deutlich kürzer, dieselben drei Tests unverändert grün. Diese Reihenfolge ist die Aufgabe. Der Hinweis formuliert es so pointiert, dass ich es gern zitiere: Ohne grünen Ausgangsstand ist es kein Refactoring, sondern eine Hoffnung.

15:04 Und Hoffnung ist im Berufsalltag eine schlechte Grundlage für Änderungen an Code, den andere Menschen benutzen. Nehmen Sie sich die Zeit für die Tests — sie ist beim ersten Umbau schon wieder drin. Ohne Tests umzubauen und auf das eigene Gedächtnis zu vertrauen, ist die häufigste Ursache für Fehler, die nach einem Aufräumen auftauchen.

15:24 Umbau und Funktionsänderung in einem Schritt zu vermischen, macht jede Diagnose unmöglich — und übrigens auch jedes Review. Zu große Schritte zu machen, ist derselbe Fehler in anderer Form. Und der vierte Punkt ist der verräterischste: einen fehlschlagenden Test nach dem Umbau anzupassen, statt den Umbau zu prüfen. Der Test hat gerade seine Aufgabe erfüllt — ihn umzuschreiben, heißt, die Meldung abzuschalten statt das Problem zu lösen.

Kompatibilitäts-Checkliste

15:50 Jetzt schließen wir den Bogen zum allerersten Modul. Dieselbe Frage wie damals — läuft das in meiner Umgebung? —, aber jetzt mit dem Wissen des ganzen Kurses. Fünf Fragen, die vor jedem modernen Sprachfeature stehen sollten. Der Satz aus Modul eins, jetzt mit Erfahrung gelesen: Moderne Sprachfeatures stehen im Standard, aber nicht zwingend in jeder Laufzeitumgebung.

16:13 Sie haben das im Lauf des Kurses mehrfach erlebt — bei den Mengenoperationen, den Iterator-Helfern, den Import-Attributen. Jedes Mal stand der Hinweis dabei, die Zielumgebung zu prüfen. Das war kein Formalismus. Vor dem Einsatz gehört geklärt, wo der Code laufen soll und ob diese Umgebung das Feature kennt. Wer das überspringt, entdeckt das Problem beim Ausliefern — im ungünstigsten Fall beim Kunden.

16:38 Fünf Fragen. Wo läuft der Code? Kennt diese Umgebung das Feature — und wenn nicht, gibt es eine Alternative oder eine Nachrüstung? Ist es überhaupt Standard oder nur ein Vorschlag im Entwurfsstadium? Gehört die Schnittstelle zur Sprache oder zur Umgebung? Und die fünfte, die alles zusammenhält: nachschlagen statt vermuten.

16:58 Der Fußtext gibt die Trennlinie für Frage vier, und sie ist dieselbe wie im ersten Modul: Array, Map, Promise und Set sind Sprache. Das Dateisystem-Modul und die Browser-Schnittstellen sind Umgebung. Wer das trennt, sucht nie wieder an der falschen Stelle. Vier Punkte zur Einordnung des Bestands. Alte Schlüsselwörter, die Ladefunktion, Callbacks, klassische Schleifenformen — die werden Ihnen weiterhin begegnen.

17:24 Und oft stehen sie da, weil eine ältere Umgebung unterstützt werden muss. Das ist keine Nachlässigkeit, sondern eine Anforderung. Fremden Code zu lesen heißt also, Altes und Neues nebeneinander zu verstehen, ohne moralisch zu werten. Der letzte Punkt bleibt trotzdem klar: Neues zu schreiben heißt, moderne Formen zuerst zu wählen.

17:44 Bestand respektieren und Neues zeitgemäß bauen — das ist kein Widerspruch, sondern professionelle Praxis. Nennen Sie für ein im Kurs verwendetes Feature dreierlei: Standardzugehörigkeit, Zielumgebung und einen Beleg für die Unterstützung — mit Quelle. Das ist inhaltlich dieselbe Aufgabe wie im ersten Modul, und genau darin liegt der Reiz. Vergleichen Sie einmal, wie viel leichter sie Ihnen jetzt fällt.

18:09 Der Hinweis nennt die spannendsten Kandidaten aus diesem Kurs: Mengenoperationen, Iterator-Helfer und Import-Attribute. Bei allen dreien stand der Verfügbarkeitshinweis auf der Folie — jetzt lösen Sie ihn ein. Von „steht im Standard" auf „läuft überall" zu schließen, ist der Trugschluss aus dem ersten Modul, hier zum letzten Mal.

18:29 Beispielcode mit Entwurfssyntax zu übernehmen, passiert leicht, weil im Netz vieles kursiert, was noch nirgends läuft. Sprachfeature und Umgebungs-Schnittstelle zu verwechseln, führt zur Suche in der falschen Dokumentation — MDN kennt das Dateisystem-Modul nicht. Und der vierte Punkt ist die Haltungsfrage aus dem Warum-Abschnitt: alte Muster im Bestand ungefragt zu modernisieren. Fragen Sie erst, warum sie da sind.

18:54 Manchmal gibt es einen guten Grund.

Wie es weitergeht

18:56 Und damit zum letzten Kapitel dieses Kurses. Das Fundament steht — jetzt entscheidet die Richtung. Ich nenne Ihnen mehrere Wege und dränge Ihnen keinen auf. Denn welcher passt, hängt davon ab, was Sie bauen wollen. Das Fundament dieses Kurses trägt in jede Richtung, in der JavaScript eingesetzt wird — und das sind erstaunlich viele.

19:17 Genau das war die Ausgangsbeobachtung im ersten Modul: eine Sprache, viele Umgebungen. Welcher Weg als nächstes sinnvoll ist, hängt davon ab, was gebaut werden soll. Und das ist die angenehme Nachricht: Sie müssen sich nicht sofort entscheiden, und Sie können die Richtung wechseln. Was Sie in diesen vier Tagen gelernt haben — die Sprache selbst — bleibt in jeder dieser Richtungen gültig. Frameworks kommen und gehen, der Sprachkern bleibt.

19:44 Fünf Wege, und lesen Sie die linke Spalte als Frage an sich selbst: Was wollen Sie bauen? Weboberflächen führen zu den Browser-Schnittstellen und zur Arbeit mit dem Dokumentmodell. Server und Dienste bedeuten Node vertiefen — HTTP, Routing, Datenbanken. Größere Projekte profitieren von statischen Typen, also TypeScript.

20:04 Teamarbeit bringt Architektur, Sicherheit und Teststrategie ins Spiel. Und Frameworks sind der Weg, den die meisten früher oder später gehen. Der Fußtext ist der Satz, mit dem ich Sie entlassen möchte: Jeder dieser Wege setzt genau das voraus, was dieser Kurs aufgebaut hat. Vier Punkte zum Weitermachen, und der wichtigste ist der dritte.

20:25 Fremden Code lesen: kleine Projekte öffnen, Importen folgen, Datenfluss verfolgen — genau die Technik aus Kapitel zwei. Kleine eigene Projekte bauen, nichts Großes, dafür regelmäßig. Und dann: Aus Syntaxkenntnis wird erst durch Wiederholung Können. Das ist kein Trostpflaster, sondern eine Tatsache über das Lernen. Der vierte Punkt schließt den Bogen zum allerersten Modul: Wer die Grundlagen beherrscht, kann generierten Code beurteilen statt ihn zu übernehmen.

20:53 Das war zu Beginn ein Versprechen — jetzt ist es Ihre Fähigkeit. Die letzte Aufgabe dieses Kurses ist zugleich die erste Ihres eigenen Weges. Beschreiben Sie ein kleines Projekt mit Eingaben, Ausgaben, Modulzuschnitt und mindestens einem Test — und benennen Sie, welche drei Kursmodule es einsetzt. Das ist die Zerlegung aus Modul zehn, angewandt auf Ihr eigenes Vorhaben.

21:17 Der Hinweis nennt die drei Zutaten, die ein erstes Projekt gelingen lassen: kleiner Umfang, echte Datenquelle, ein Sicherheitsnetz aus wenigen Tests. Vor allem der kleine Umfang. Fertigwerden ist wichtiger als Ambition. Ein zu großes erstes Projekt zu wählen und es nie zu beenden, ist der häufigste Grund, warum Lernen ins Stocken gerät — nichts entmutigt so sehr wie ein Halbfertiges.

21:40 Auf das nächste Tutorial zu warten, statt selbst zu bauen, fühlt sich produktiv an und ist es nicht. Alles wissen zu wollen, bevor etwas entsteht, ist derselbe Aufschub in anderer Verkleidung. Und der letzte Punkt ist der, der diesen Kurs von Anfang bis Ende begleitet hat: generierten Code zu übernehmen, ohne ihn lesen zu können.

21:58 Dagegen haben Sie jetzt etwas in der Hand.

Das Fundament steht

22:01 Vier Sätze zum Schluss. Wartbarer Code entsteht aus Namen, Größe, Grenzen und dem Verzicht auf Dopplung — vier Hebel, die Sie ab sofort bewusst bedienen können. Abdeckung zeigt Lücken, beweisen tun es die Zusicherungen. Refactoring braucht ein grünes Sicherheitsnetz, sonst ist es Hoffnung. Und der letzte Satz ist der Auftrag für die Zeit nach diesem Kurs: Weitermachen heißt, fremden Code lesen und kleine Projekte bauen. Vier Tage lang ging es um die Sprache.

22:30 Was daraus wird, entscheidet jetzt die Übung. Viel Erfolg dabei.