Software Development

Was ist eine Closure in JavaScript? 1 2 3 4 5 6 7 8 9 10 11 12 function makeCounter() { let count = 0; return function () { count += 1; return count; }; } const counter = makeCounter(); console.log(counter()); // 1 console.log(counter()); // 2 console.log(counter()); // 3 makeCounter läuft einmal, gibt eine Funktion zurück, und damit ist es erledigt: Der Stack-Frame existiert nicht mehr. Trotzdem liest und aktualisiert jeder Aufruf von counter() weiterhin count, eine Variable, die innerhalb einer bereits beendeten Funktion deklariert wurde. count wird nicht auf 0 zurückgesetzt und nicht kopiert. Es ist dieselbe Variable, immer noch lebendig, drei Aufrufe später. ...

Ein Test, der nach dem Code geschrieben wird, prüft meist, was der Code tut, nicht, was er tun sollte. Testgetriebene Entwicklung (TDD) behebt das, indem sie die Reihenfolge umdreht: Sie schreiben den Test, sehen ihn fehlschlagen und schreiben dann den kleinsten Code, der ihn bestehen lässt. Weil der Test existiert, bevor der Code existiert, den er prüft, kann er nicht stillschweigend bestätigen, was der Code gerade zufällig zurückgibt. Kent Beck hat diese Schleife in seinem Buch Test-Driven Development: By Example von 2002 als red, green, refactor formalisiert. Der Name ist geblieben. ...

Melden Sie einen Nutzer in einer session-basierten App ab, vergisst der Server ihn bei der nächsten Anfrage. Melden Sie ihn in einer JWT-basierten App ab, bleibt das Token, das er besitzt, gültig, bis es abläuft – es sei denn, Sie haben einen zusätzlichen Mechanismus dafür gebaut. Dieser Unterschied ist die eigentliche Entscheidung hinter „JWT vs. Session". Der Rest folgt daraus. Was eine Session tatsächlich speichert Eine Session hält den Zustand des Nutzers auf dem Server und gibt dem Browser nur einen Schlüssel zum Nachschlagen. ...

Packen Sie einen fetch()-Aufruf in ein try/catch, rufen Sie einen Endpunkt auf, der mit 404 antwortet, und der catch-Block läuft nie. Das Promise wird aufgelöst. res.json() parst, was auch immer der Server zurückgeschickt hat, oft ein Fehler-Payload wie {"error": "user not found"}, und der Rest der Funktion behandelt es als den angeforderten Datensatz. Keine Exception, keine Konsolenwarnung. Die falschen Daten wandern weiter, bis etwas anderes daran zerbricht. 1 2 3 4 5 6 7 8 9 async function getUser(id) { try { const res = await fetch(`/api/users/${id}`); const user = await res.json(); return user; // bei einem 404 ist das { error: "user not found" } } catch (err) { console.error('Failed to load user:', err); } } Dieses catch greift nur bei einer Anfrage, die nie abgeschlossen wird. Alles andere braucht eine Prüfung, die Sie selbst schreiben müssen. ...

Eine Funktion, die sich selbst aufruft, hat eine maximale Tiefe, und die ist kleiner, als die meisten erwarten: 1.000 Aufrufe in CPython standardmäßig, etwa 10.000 bis 15.000 in Node und in Browser-Engines, je nachdem, wie viel jeder Frame belegt. Wird dieses Limit überschritten, wird das Programm nicht einfach langsamer. Es stürzt ab. Python löst RecursionError: maximum recursion depth exceeded aus; JavaScript löst RangeError: Maximum call stack size exceeded aus. Beide Fehler haben die gleiche Ursache, und wenn Sie sie einmal verstanden haben, wissen Sie, wann Rekursion das richtige Werkzeug ist und wann sie zum Risiko wird. ...

Sie bauen ein Dashboard: Header, Sidebar, Hauptbereich, Footer. Sie greifen zu Flexbox, weil das nun mal das Layout-Werkzeug ist, das Sie kennen – und zwanzig Minuten später stapeln sich drei verschachtelte display: flex-Container, die Sidebar hält ihre Breite nur mit einer willkürlichen Pixelzahl, und der Footer schwebt mitten auf der Seite, sobald der Inhalt kurz ist. Das ist kein Flexbox-Bug. Sie wenden ein eindimensionales Werkzeug auf ein zweidimensionales Problem an. ...

Stellen Sie go vor einen Funktionsaufruf, und diese Funktion läuft nebenläufig zum Rest des Programms, verwaltet von der Go-Runtime statt vom Betriebssystem. Eine zu starten ist der einfache Teil. Der schwierige Teil ist, zwei Goroutinen ein Ergebnis übergeben zu lassen, ohne dass sie sich gegenseitig den Zustand kaputt machen, und genau das ist die Aufgabe von Channels. Was ist eine Goroutine? Eine Goroutine ist eine Funktion, die unabhängig von der Funktion läuft, die sie gestartet hat, verwaltet von der Go-Runtime und nicht vom Betriebssystem. Ein OS-Thread reserviert ein Megabyte oder mehr Stack und kostet den Kernel echte Zeit für die Planung. Eine Goroutine startet mit einem Stack von etwa 2 KB, der bei Bedarf wächst, und die Runtime multiplext viele Goroutinen auf eine Handvoll OS-Threads. Tausende davon zu starten ist normal. ...

Eine Klasse, die einen Nutzer in der Datenbank speichert, ihm eine Willkommens-E-Mail schickt und eine Quittung formatiert, ist eine Änderung davon entfernt, zwei Funktionen zu zerstören, mit denen sie nichts zu tun hat. Fassen Sie das E-Mail-Template an, riskieren Sie den Schreibzugriff auf die Datenbank. Fassen Sie das Quittungslayout an, riskieren Sie die E-Mail. SOLID ist der Sammelbegriff für fünf Regeln gegen genau diese Art von Verknotung, jede aus einem anderen Blickwinkel. Sie teilen eine Idee: Eine Klasse soll nur einen Grund haben, sich zu ändern, und der Rest des Codes soll davon abhängen, was etwas zu tun verspricht, nicht davon, wie es das tut. ...

Zwei Anfragen treffen im Abstand von einer halben Millisekunde auf denselben “100€ abheben”-Endpunkt. Das Konto hat 150€. Beide Anfragen lesen diesen Kontostand, beide sehen genug Guthaben, beide werden genehmigt, beide ziehen 100€ ab. Das Konto landet bei -50€, und kein Codepfad hätte das zulassen dürfen. Das ist eine Race Condition: Das Ergebnis hängt davon ab, welche Operation zufällig zuerst fertig wird, und “zuerst” war nie eine Entscheidung, die der Code getroffen hat. ...

Ein Suchfeld, das bei jedem Tastendruck eine Anfrage auslöst, schickt für “redis” fünf Anfragen, von denen vier veraltet sind, bevor die Antwort zurückkommt. Ein scroll-Handler, der das Layout neu berechnet, läuft hunderte Mal pro Sekunde und lässt die Seite stottern. Beide Fälle haben dasselbe Problem: Das DOM-Event feuert viel öfter, als der Handler laufen muss. Debounce und Throttle lösen das auf zwei unterschiedliche Arten. Was Debounce macht und was Throttle macht Debounce wartet, bis das Event für eine festgelegte Zeit nicht mehr feuert, und läuft dann einmal. Jeder neue Aufruf setzt die Uhr zurück. Hört das Event nie auf, läuft die Funktion nie. Ein Suchfeld ist der klassische Fall: warten, bis der Nutzer beim Tippen pausiert, und dann eine Anfrage für das zuletzt Eingegebene schicken. ...