Software Development

Co to jest closure w 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 działa raz, zwraca funkcję i na tym koniec: jej stack frame już nie istnieje. Mimo to każde wywołanie counter() wciąż odczytuje i aktualizuje count — zmienną zadeklarowaną wewnątrz funkcji, która już się zakończyła. count nie wraca do 0 i nie jest kopiowana. To wciąż ta sama zmienna, żywa, trzy wywołania później. ...

Test napisany po kodzie zwykle sprawdza to, co kod robi, a nie to, co miał robić. Programowanie sterowane testami (TDD) naprawia to, odwracając kolejność: piszesz test, patrzysz, jak nie przechodzi, a potem piszesz najmniejszy możliwy kod, który sprawia, że test przechodzi. Ponieważ test istnieje przed kodem, który sprawdza, nie może po cichu uznać za poprawne tego, co akurat zwróci kod. Kent Beck sformalizował ten cykl jako red, green, refactor w swojej książce z 2002 roku Test-Driven Development: By Example. Nazwa się przyjęła. ...

Wyloguj użytkownika z aplikacji opartej na sesjach, a serwer zapomni o nim przy następnym żądaniu. Wyloguj go z aplikacji opartej na JWT i, jeśli nie zbudowałeś dodatkowego mechanizmu, token, który trzyma, zostaje ważny aż do wygaśnięcia. Ta różnica jest prawdziwą decyzją stojącą za “JWT vs sesja”. Reszta z niej wynika. Co faktycznie przechowuje sesja Sesja trzyma stan użytkownika na serwerze, a przeglądarce przekazuje tylko klucz do wyszukania. Użytkownik loguje się hasłem. Serwer tworzy rekord sesji (ID użytkownika, role, co tylko potrzebne) i zapisuje go w pamięci, w bazie danych albo w Redis, indeksowany losowym ID sesji. Serwer wysyła ten ID do przeglądarki jako cookie, oznaczone HttpOnly, żeby JavaScript po stronie klienta nie mógł go odczytać. Przy każdym żądaniu przeglądarka automatycznie odsyła cookie. Serwer szuka ID w store i pobiera dane sesji. Cookie nie niesie żadnej informacji o użytkowniku, tylko nieprzejrzysty ciąg, który serwer rozwiązuje przy każdym żądaniu. Usuń rekord w store i sesja znika przy następnym żądaniu, na każdym urządzeniu. ...

Owiń wywołanie fetch() w try/catch, trafiasz na endpoint, który odpowiada 404, a blok catch nigdy się nie uruchamia. Promise się rozwiązuje. res.json() parsuje to, co serwer odesłał, często payload błędu w stylu {"error": "user not found"}, a reszta funkcji traktuje to jak żądany rekord. Żadnego wyjątku, żadnego ostrzeżenia w konsoli. Złe dane płyną dalej, aż coś inne się na nich wywala. 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; // przy 404 to jest { error: "user not found" } } catch (err) { console.error('Failed to load user:', err); } } Ten catch odpala się tylko dla żądania, które nigdy się nie kończy. Wszystko inne wymaga sprawdzenia, które musisz napisać samodzielnie. ...

Funkcja, która wywołuje sama siebie, ma maksymalną głębokość, i jest ona mniejsza niż większość się spodziewa: 1000 wywołań w CPython domyślnie, w okolicach 10 000-15 000 w Node i silnikach przeglądarek, zależnie od tego, jak dużo zajmuje każda ramka. Przekroczenie tego limitu nie zwalnia programu. Program się wysypuje. Python zgłasza RecursionError: maximum recursion depth exceeded; JavaScript zgłasza RangeError: Maximum call stack size exceeded. Oba błędy mają tę samą przyczynę, a gdy już ją zobaczysz, będziesz wiedzieć, kiedy rekurencja jest właściwym narzędziem, a kiedy staje się ryzykiem. ...

Budujesz dashboard: header, sidebar, główna treść, footer. Sięgasz po Flexbox, bo to narzędzie layoutowe, które znasz, a dwadzieścia minut później masz trzy zagnieżdżone kontenery display: flex, sidebar, który nie utrzyma swojej szerokości bez magicznej liczby, i footer, który unosi się w połowie strony, gdy treści jest mało. To nie jest błąd Flexbox — to Ty używasz narzędzia jednowymiarowego do problemu dwuwymiarowego. Flexbox rozkłada przestrzeń wzdłuż jednej linii: wiersza albo kolumny. Grid ustawia elementy w wierszach i kolumnach naraz, a te wiersze i kolumny odnoszą się do siebie. Większość zamieszania wokół Grid kontra Flexbox wynika z przeskoczenia tej różnicy. ...

Postaw go przed wywołaniem funkcji i ta funkcja zacznie działać współbieżnie z resztą programu, zarządzana przez runtime Go, a nie przez system operacyjny. Uruchomienie jej to łatwa część. Trudna część to przekazanie wyniku między dwoma goroutines bez wchodzenia sobie w drogę przy współdzielonym stanie, a tym właśnie zajmują się channels. Co to jest goroutine? Goroutine to funkcja działająca niezależnie od tej, która ją uruchomiła. Wątek systemu operacyjnego rezerwuje megabajt lub więcej stosu i kosztuje jądro realny czas na szeregowanie. Goroutine startuje ze stosem około 2KB, który rośnie w razie potrzeby, a runtime multiplexuje wiele goroutines na garstkę wątków systemowych. Uruchamianie ich tysięcy naraz jest normalne. ...

Klasa, która zapisuje użytkownika w bazie danych, wysyła mu powitalny email i formatuje rachunek, jest jedną zmianą od zepsucia dwóch funkcji, z którymi nie ma nic wspólnego. Zmieniasz szablon emaila i ryzykujesz zapis do bazy. Zmieniasz układ rachunku i ryzykujesz email. SOLID to pięć zasad, które atakują ten rodzaj splątania z różnych stron, i łączy je jedna idea: klasa powinna mieć jeden powód do zmiany, a reszta kodu powinna zależeć od tego, co element obiecuje robić, nie od tego, jak to robi. ...

Dwa requesty trafiają na ten sam endpoint “wypłać 100€” z różnicą pół milisekundy. Konto ma 150€. Oba requesty czytają ten sam stan konta, oba widzą wystarczające środki, oba zostają zatwierdzone, oba odejmują 100€. Konto kończy na -50€, a żadna ścieżka w kodzie nie powinna do tego doprowadzić. To jest race condition: wynik zależy od tego, która operacja skończy się pierwsza, a to, co było “pierwsze”, nigdy nie zależało od kodu. ...

Pole wyszukiwania, które wysyła zapytanie przy każdym naciśnięciu klawisza, wysyła pięć zapytań dla “redis”, a cztery z nich są już nieaktualne, zanim wróci odpowiedź. Handler scroll, który przelicza layout, odpala się setki razy na sekundę i powoduje szarpanie strony. W obu przypadkach ten sam problem: zdarzenie DOM odpala się dużo częściej, niż handler musi się wykonać. Debounce i throttle rozwiązują to na dwa różne sposoby. Co robi debounce, a co robi throttle Debounce czeka, aż zdarzenie przestanie się odpalać na ustalony czas, i wtedy wykonuje się raz. Każde nowe wywołanie resetuje zegar. Jeśli zdarzenie nigdy się nie zatrzymuje, funkcja nigdy się nie wykonuje. Pole wyszukiwania to typowy przypadek: czekaj, aż użytkownik zrobi przerwę w pisaniu, a potem wyślij zapytanie z tym, co wpisał na końcu. ...