Problemlösung und Debugging

JavaScript — Problemlösung und Debugging

0:00 Dieses Modul ist anders als alle bisherigen: Es enthält kein einziges neues Sprachfeature. Es geht um Arbeitsweise. Denn Syntax zu kennen ist nur die halbe Miete — die andere Hälfte ist, ein Problem zu verstehen, bevor man es codiert, und einen Fehler zu finden, statt ihn zu erraten. Genau diese Fähigkeiten unterscheiden in der Praxis Menschen, die schnell vorankommen, von solchen, die stundenlang im Kreis suchen.

0:25 Und die gute Nachricht: Es sind erlernbare Techniken, keine Begabung. Wir gehen sie der Reihe nach durch.

Denken vor dem Tippen

0:32 Fünf Kapitel, und sie folgen dem natürlichen Ablauf. Zuerst ein Vorgehen, das aus einer Aufgabenstellung eine lösbare Struktur macht — inklusive der Sonderfälle, die man später am liebsten übersehen hätte. Dann die Übersetzung in Code, und zwar so, dass man sie gegen den Plan prüfen kann. Danach das Nachvollziehen von Programmläufen mit einer Gewohnheit, die ich Ihnen wirklich ans Herz lege.

0:55 Und schließlich zwei Werkzeuge: der Debugger im Editor und die Konsolenausgabe — mit einer klaren Regel, wann welches dran ist.

Ein Vorgehen zur Problemlösung

1:03 Fangen wir vor der ersten Zeile Code an. Der häufigste Fehler in Projekten passiert nämlich genau dort: Code entsteht, bevor die Frage geklärt ist. Was danach kommt, ist dann oft Reparatur an einem Fundament, das nie stimmte. Vier Tätigkeiten stecken in dieser Definition, und keine davon ist Programmieren. Verstehen, was gefordert ist. Benennen, was hineingeht und was herauskommen soll.

1:27 Festhalten, welche Randbedingungen und Sonderfälle gelten. Und erst dann zerlegen in kleine, einzeln lösbare Schritte. Das klingt nach Bürokratie und ist das Gegenteil — es ist die Abkürzung. Wer diese vier Punkte überspringt, schreibt Code, der dreimal umgebaut wird. Wer sie erledigt, schreibt Code einmal. Die Zeit, die Sie hier investieren, holen Sie beim Tippen mehrfach zurück, und beim Debuggen noch einmal.

1:54 Der rote Faden dieser fünf Schritte ist eine Bewegung von außen nach innen. Zuerst die Frage nach dem Ziel — und wichtig ist der Zusatz: Woran erkennt man Erfolg? Ohne diese Antwort wissen Sie später nicht, ob Sie fertig sind. Dann die Eingaben, samt Typ und der Frage, ob sie fehlen können; genau diese Frage rettet Sie vor der Hälfte aller Abstürze. Die Ausgaben kommen davor, nicht danach.

2:18 Dann die Sonderfälle. Und erst der fünfte Schritt zerlegt in kleine Einheiten, aus denen später Funktionen werden. Der Fußtext ist die Pointe: Erst wenn diese fünf Punkte stehen, lohnt sich die erste Zeile Code. Vier Fälle, die man ständig übersieht — und alle vier kennen Sie inzwischen. Die leere Liste ist der Klassiker: Der Code funktioniert mit drei Einträgen wunderbar und tut mit null Einträgen etwas Unerwartetes.

2:43 Fehlende Felder liefern undefined und verhalten sich stillschweigend anders, ohne Fehlermeldung. Der Wert null ist gültig und fällt trotzdem durch jede unwahr-Prüfung — unser Dauerbrenner seit Modul drei. Und der vierte Punkt ist eine Haltung: Ungültige Daten von außen sind der Normalfall, nicht die Ausnahme. Wer sie erst nachträglich behandelt, muss die Struktur umbauen.

3:05 Das hier ist bewusst kein JavaScript — es ist Klartext, nicht ausführbar. Und genau das ist der Punkt. Sie beschreiben den Ablauf in Ihrer eigenen Sprache, ohne über Syntax nachzudenken. Dabei fällt auf, ob die Schritte vollständig sind, ob die Reihenfolge stimmt, ob ein Fall fehlt. Solche Erkenntnisse hat man im Klartext in Sekunden; im Code kosten sie eine halbe Stunde Umbau.

3:28 Der Fußtext beschreibt den Gewinn: Steht der Klartext, ist die Übersetzung nach JavaScript fast mechanisch. Sie haben dann nämlich zwei getrennte Aufgaben erledigt — erst denken, dann tippen — statt beide gleichzeitig. Diese Aufgabe hat eine ungewöhnliche Auflage: keine einzige Zeile JavaScript. Was Sie abliefern, sind benannte Ein- und Ausgaben, mindestens drei Randbedingungen, zwei Sonderfälle und ein Pseudocode-Ablauf.

3:54 Für viele ist das ungewohnt und fühlt sich unproduktiv an. Halten Sie es trotzdem durch. Und beachten Sie den Hinweis, der ein sehr guter Prüfstein ist: Wenn Sie die erwartete Ausgabe nicht formulieren können, ist das Problem noch nicht verstanden. Dann helfen auch keine Codezeilen — dann brauchen Sie eine Rückfrage bei dem, der die Aufgabe gestellt hat.

4:16 Mit dem Tippen zu beginnen, bevor die erwartete Ausgabe feststeht, ist der Fehler, um den sich dieses ganze Kapitel dreht. Der zweite ist verwandt und teurer: Sonderfälle auf später zu verschieben, führt regelmäßig dazu, dass man die Struktur danach umbauen muss — weil sie für den Normalfall entworfen wurde. Der dritte ist eine Frage der Portionsgröße: Die Aufgabe als Ganzes lösen zu wollen, überfordert schneller, als man denkt.

4:41 Und der vierte klingt banal und ist es nicht: Randbedingungen im Kopf zu behalten funktioniert, bis das Telefon klingelt. Schreiben Sie sie auf.

Kleine Algorithmen entwickeln

4:50 Jetzt die Übersetzung vom Klartext in den Code. Und dabei gibt es ein Gütekriterium, das ich Ihnen mitgeben möchte — es ist überraschend einfach zu prüfen und sagt erstaunlich viel über die Qualität einer Lösung aus. Ein Algorithmus ist eine Folge von Schritten zur Lösung eines Problems — das Wort klingt größer, als es ist. Ein Rezept ist ein Algorithmus.

5:11 Der zweite Satz enthält den praktischen Gewinn: Liegt die Schrittfolge als Klartext vor, entsteht der Code Schritt für Schritt. Und — das ist der Teil, den man leicht überliest — er lässt sich danach gegen den Klartext prüfen. Sie haben also einen Maßstab, der unabhängig vom Code existiert. Ohne Pseudocode prüfen Sie den Code gegen Ihre Erinnerung daran, was er tun sollte. Das ist kein Maßstab.

5:36 Vergleichen Sie diese Fassung mit dem Klartext von vorhin — sie folgt exakt derselben Reihenfolge. Filtern, filtern, filtern, sortieren, zurückgeben. Jede Zeile Klartext hat ihre Entsprechung. Das ist kein Zufall, sondern das Ziel. Ein Detail verdient Beachtung, weil es aus Modul sechs stammt: die Sortierung in der nicht-mutierenden Variante. Die Eingabeliste bleibt damit unverändert.

5:59 Hätten Sie hier die klassische Sortiermethode genommen, würde diese Funktion nebenbei die Liste des Aufrufers umsortieren — eine Nebenwirkung, die niemand erwartet und die man in einer Auswertungsfunktion schon gar nicht sucht. Und hier dieselbe Funktion noch einmal, mit dem Kniff aus dem letzten Modul: Die Bedingungen bekommen Namen. Lesen Sie die Kette laut — sie klingt jetzt fast wie der Pseudocode.

6:24 Genau das ist das angekündigte Gütekriterium, und es steht im Fußtext: Liest sich der Code fast wie der Pseudocode, ist das ein gutes Zeichen. Der zweite Gewinn ist praktisch: Jede dieser Prüfungen lässt sich einzeln aufrufen und einzeln testen. Im nächsten Modul werden wir genau das tun. Eine inline geschriebene Bedingung dagegen können Sie nur zusammen mit der ganzen Kette prüfen.

6:46 Prüfen Sie Ihre eigene Lösung gegen zwei Randfälle: eine leere Liste und ein Eintrag ohne Jahresangabe. Und dann — das ist der interessante Teil — entscheiden Sie begründet, ob das Verhalten so bleiben soll. Nicht jeder Randfall muss abgefangen werden; manchmal ist das Durchreichen genau richtig. Wichtig ist, dass Sie es wissen und entschieden haben.

7:07 Der Hinweis nennt die Falle: Ein fehlendes Feld ergibt undefined, und der Vergleich von undefined mit einer Zahl ergibt falsch — ohne Fehlermeldung. Der Eintrag verschwindet also stillschweigend aus dem Ergebnis. Das kann richtig sein oder eine Katastrophe. Die alte Sortiermethode zu verwenden und die übergebene Liste unbemerkt umzusortieren, ist der Fehler aus dem ersten Codebeispiel — und in echten Projekten eine ergiebige Quelle für rätselhafte Effekte.

7:33 Der zweite Punkt ist der Sonderfall aus der Aufgabe: Fehlende Felder rutschen durch, weil der Vergleich schlicht falsch liefert. Der dritte ist die Testbarkeit, die mit inline geschriebenen Bedingungen verloren geht. Und der vierte ist ein handfestes Detail: Bei der Sortierung die Reihenfolge der Operanden zu vertauschen, dreht die Sortierrichtung um. Das merkt man sofort — wenn man hinschaut.

Programmläufe nachvollziehen

7:56 Jetzt kommt eine Gewohnheit, die ich für die wertvollste dieses ganzen Moduls halte. Sie kostet zehn Sekunden, sie ist unspektakulär, und sie beschleunigt das Lernen dramatisch. Sie lautet: erst vorhersagen, dann ausführen. Nachvollziehen heißt, den Code Zeile für Zeile mitzulesen und festzuhalten, welche Werte sich wann ändern — im Kopf oder auf Papier.

8:18 Der zweite Satz beschreibt den eigentlichen Trick: Die Vorhersage vor dem Ausführen macht Missverständnisse sichtbar, bevor sie zu Fehlern werden. Denn wenn Sie einfach nur ausführen, sehen Sie ein Ergebnis und nicken. Wenn Sie vorher raten, dann entweder bestätigt sich Ihr Verständnis — oder Sie stoßen genau auf die Stelle, an der es lückenhaft ist. Dieser zweite Fall ist der wertvolle.

8:41 Machen Sie es jetzt einmal: Was gibt der obere Block aus? Nehmen Sie sich die Sekunden, bevor Sie weiterlesen. Der Punkt ist, dass beide Bedingungen nacheinander geprüft werden — es gibt kein else, also greift die zweite unabhängig von der ersten. Der untere Block zeigt den berüchtigten Grenzfehler: Bei genau zehn greift die Bedingung mit dem einfachen Größerzeichen nicht, obwohl gemeint war, dass sie greift.

9:04 Solche Fehler um eins finden Sie nicht durch Hinsehen und selten durch Zufallstests. Sie finden sie, indem Sie den Grenzwert bewusst durchspielen. Beide Ausgänge sind wertvoll, und das macht diese Technik so angenehm. Stimmt die Vorhersage, sitzt das Verständnis — Sie können weitergehen. Weicht sie ab, liegt genau dort die Lücke, und das ist der eigentliche Lernmoment.

9:26 Die typischen Ursachen sind überschaubar: falsche Vergleichsrichtung, ein früher Rücksprung, den Sie übersehen haben, oder ein Grenzfehler. Und der letzte Punkt ist die Brücke zum nächsten Modul: Nachvollziehen ist die Vorstufe zum automatisierten Test. Ein Test ist im Grunde nichts anderes als eine aufgeschriebene Vorhersage, die der Computer für Sie prüft.

9:48 Halten Sie für drei Codeabschnitte je eine Vorhersage schriftlich fest — schriftlich, nicht im Kopf. Der Unterschied ist erheblich, denn im Kopf passt man die Erwartung nachträglich an das Ergebnis an, ohne es zu merken. Und bei jeder Abweichung benennen Sie die konkrete Fehlannahme. Nicht „hab mich vertan", sondern „ich dachte, das else greife auch hier".

10:09 Der Hinweis nennt die lohnendsten Kandidaten: genau fünf, genau zehn, leere Liste. Grenzwerte sind dort, wo die Fehler wohnen. Auszuführen, bevor eine Vorhersage steht, verschenkt den ganzen Lerneffekt — das Ergebnis wirkt dann immer plausibel. Der zweite Punkt ist der teuerste Reflex überhaupt: Bei einer Abweichung sofort den Code zu ändern, statt die Ursache zu suchen.

10:32 Man ändert dann so lange, bis es zufällig stimmt, und hat nichts verstanden. Grenzwerte auszulassen und nur den bequemen Fall zu prüfen, ist der dritte. Und der vierte ist erstaunlich häufig: anzunehmen, eine Schleife laufe so oft wie erwartet, ohne es je gezählt zu haben. Ein Zähler und eine Ausgabe klären das in zwanzig Sekunden.

Debugging im Editor

10:53 Jetzt zurück zum Debugger, den wir im ersten Modul kurz gestreift haben — diesmal mit dem Beispiel, das seinen Wert wirklich zeigt. Es ist ein Fehler, bei dem Ausgaben Sie in die Irre führen und nur der Blick auf den Zustand die Wahrheit sagt. Der Debugger hält die Ausführung an einem Haltepunkt an und macht den Zustand sichtbar — das kennen wir.

11:13 Neu sind die Schrittbefehle, und sie bestimmen, wie es weitergeht: über eine Zeile hinweg, in eine Funktion hinein oder aus ihr heraus. Diese drei Richtungen sind das eigentliche Werkzeug. Denn selten wollen Sie durch alles hindurchsteppen; meistens wollen Sie an einer bestimmten Ebene bleiben und an einer anderen genauer hinschauen.

11:31 Wer die Befehle beherrscht, bewegt sich durch ein Programm wie durch ein Gebäude — Stockwerk für Stockwerk statt Zimmer für Zimmer. Das ist der Aha-Moment dieses Moduls. In der Bedingung steht ein einzelnes Gleichheitszeichen — eine Zuweisung statt eines Vergleichs. Und jetzt kommt das Fiese: Eine Zuweisung liefert den zugewiesenen Wert zurück, und dieser Text ist nicht leer, also wahr.

11:54 Die Bedingung trifft folglich immer zu, jeder Eintrag landet im Ergebnis. Schlimmer noch: Nebenbei wird bei jedem Eintrag das Feld überschrieben. Ihre Daten sind danach kaputt. Mit Ausgaben finden Sie das schwer, weil ja alles plausibel aussieht. Im Debugger sehen Sie den Wert sich ändern, während Sie die Bedingung auswerten.

12:14 Die Logik dahinter ist die Frage nach der Ebene. Der erste Befehl bleibt auf Ihrer Ebene und führt eine Zeile aus, auch wenn dabei ganze Funktionen ablaufen. Der zweite steigt ab — und Vorsicht, das landet schnell in fremdem Bibliothekscode. Der dritte steigt auf, beendet also die aktuelle Funktion und bringt Sie zum Aufrufer zurück; das ist der Rettungsknopf, wenn Sie zu tief gerutscht sind.

12:38 Und der vierte läuft bis zum nächsten Haltepunkt. Der Fußtext verweist auf eine Ansicht, die viele ignorieren: Der Aufrufstapel zeigt den Weg bis zur aktuellen Zeile. Bei tief liegenden Fehlern ist er die wichtigste Ansicht überhaupt. Stellen Sie den Fehler aus dem Codebeispiel — und zwar durch Beobachtung, nicht durch Raten.

12:57 Zeigen Sie im angehaltenen Zustand, wie sich das Feld beim Auswerten der Bedingung verändert. Erst danach beheben Sie ihn mit striktem Vergleich. Diese Reihenfolge ist der Kern der Übung: erst sehen, dann ändern. Ein praktischer Tipp aus dem Hinweis: Setzen Sie einen Überwachungsausdruck auf das betroffene Feld. Der Editor zeigt Ihnen dann bei jedem Schritt den aktuellen Wert an, und die Veränderung springt Ihnen förmlich entgegen.

13:23 Der Haltepunkt hinter der interessanten Zeile ist der Fehler aus Modul eins, und er passiert weiterhin — setzen Sie ihn davor. In fremden Bibliothekscode zu geraten, kostet Nerven und Zeit; nutzen Sie dann den Befehl, der Sie wieder herausbringt. Der dritte Punkt betrifft eine verschenkte Möglichkeit: Nur die Variablenliste anzusehen und den Aufrufstapel zu ignorieren, ist wie eine Landkarte ohne Wegbeschreibung.

13:46 Und der letzte ist die Disziplin aus der Aufgabe, die ich für die wichtigste halte: Den Fehler nicht ändern, bevor man ihn im Zustand tatsächlich gesehen hat. Sonst behebt man vielleicht ein Symptom.

Konsolenausgaben und Zusicherungen

13:58 Zum Abschluss das Werkzeug, das jeder benutzt und viele überstrapazieren: die Konsolenausgabe. Sie ist völlig legitim — mit zwei Regeln. Eine sagt, wann man wechseln sollte, die andere, was danach zu tun ist. Konsolenausgaben machen Werte und Ablauf sichtbar — das ist der schnelle, direkte Weg, und daran ist nichts falsch. Interessanter ist der zweite Teil: die Zusicherung.

14:22 Sie prüft eine Annahme und verhält sich unauffällig, solange die Annahme stimmt. Erst wenn sie verletzt wird, meldet sie sich. Das ist ein anderes Prinzip als bei der Ausgabe: Sie sagen nicht „zeig mir den Wert", sondern „sag mir Bescheid, wenn meine Erwartung nicht stimmt". Bei langen Läufen mit vielen Durchgängen ist das erheblich angenehmer, als Hunderte Zeilen Ausgabe durchzusehen.

14:46 Vier Werkzeuge mit unterschiedlichen Aufgaben. Die erste Zeile ist der Alltag, mit einem nützlichen Detail: Sie können mehrere Werte durch Kommas trennen und eine Beschriftung voranstellen. Die zweite ist der unterschätzte Tipp — für Listen von Objekten liefert die Tabellenausgabe eine echte Tabelle statt einer unlesbaren Klammerwüste.

15:05 Die dritte schreibt auf den Fehlerkanal, und das ist in Kommandozeilenwerkzeugen wichtig, weil sich beide Kanäle getrennt weiterverarbeiten lassen. Und die vierte ist die Zusicherung: Bei wahr passiert nichts, bei falsch erscheint Ihre Meldung. Genau die Umkehrung des üblichen Vorgehens. Die Abgrenzung ist praktisch und klar. Die Konsole ist stark, wenn Sie einen Verlauf über die Zeit sehen wollen — wie sich ein Wert über zwanzig Durchläufe entwickelt.

15:31 Der Debugger ist stark, wenn Sie einen Moment genau untersuchen wollen: Gültigkeitsbereich prüfen, Schritt für Schritt gehen, Zustand betrachten. Und dann kommt die Faustregel, die ich Ihnen als Merksatz mitgebe: Zehn Ausgaben und immer noch ratlos — dann wechseln Sie zum Debugger. Der letzte Punkt ist Handwerksehre: Nach der Lösung fliegen die temporären Ausgaben wieder raus.

15:53 Grenzen Sie ein Filterproblem mit höchstens zwei gezielten Ausgaben ein — die Beschränkung ist der Trainingseffekt. Sie zwingt Sie, vorher zu überlegen, wo die entscheidende Stelle liegt, statt zwanzig Ausgaben zu streuen und im Ergebnis zu wühlen. Und der zweite Teil des Erfolgskriteriums ist genauso wichtig: Danach enthält der Code keine Debug-Ausgabe mehr.

16:13 Für Listen von Objekten greifen Sie zur Tabellenausgabe — der Unterschied in der Lesbarkeit ist beträchtlich, und viele kennen die Funktion schlicht nicht. Vergessene Ausgaben in der Produktivausgabe sind peinlich und in Logdateien ein echtes Ärgernis — sie verstopfen genau die Information, die man im Ernstfall bräuchte.

16:32 Alles auf den Standardkanal zu schreiben, auch Fehler, macht die Trennung kaputt, die Kommandozeilenwerkzeuge nutzbar hält. Der dritte Punkt ist eine Erwartungskorrektur: Zusicherungen sind hilfreich, aber sie ersetzen keine Tests — dazu kommen wir im nächsten Modul. Und der vierte ist der Reflex, gegen den die Faustregel steht: immer mehr Ausgaben zu ergänzen, statt zum Debugger zu wechseln.

16:55 Ab einem gewissen Punkt wird die Ausgabe selbst zum Problem.

Fehler sind Arbeit, nicht Versagen

16:59 Der Titel dieser Folie ist die wichtigste Botschaft des Moduls: Fehler sind Arbeit, nicht Versagen. Sie gehören zum Handwerk wie Späne zum Hobeln. Drei Techniken nehmen Sie mit. Erstens: Erst Eingaben, Ausgaben und Sonderfälle klären — dann tippen. Zweitens das Gütekriterium: Liest sich der Code wie der Pseudocode, stimmt meist die Struktur.

17:20 Und drittens die Gewohnheit, die ich Ihnen besonders ans Herz lege: Vorhersage vor der Ausführung, und die Abweichung ist der Lernmoment. Im nächsten Modul lassen wir diese Vorhersagen automatisch prüfen — es geht ums Testen.