|
O dobrych praktykach wiemy sporo. Ale czy wiemy czego unikać w JS?
Korzystanie z type coercion
JS jest dynamicznie typowany o czym wszyscy wiemy. I czasami te dynamiczne typowanie powoduje problemy jeśli nie znamy reguł np.: co będzie rezultatem wyrażenia '1'+1 lub [] + 2? Korzystanie z mechanizmu type coercion może powodować niespodziewane problemy. Dlatego też nigdy nie korzystaj z operatora == tylko z ===.
Korzystanie z var w 2021
Tutaj nie trzeba wiele pisać. Jeśli nie piszesz na bardzo stary silnik JS to nie ma żadnego powodu, by korzystać z var. Najlepiej zapomnij, że istniało.
Brak rozumienia różnicy między normalną funkcją a arrow function
To nie jest tylko syntax sugar. Są znaczące różnice.
- arrow functions nie mają własnego kontekstu (this wskazuje na rodzica)
- arrow functions nie mają ukrytej zmiennej arguments
- nie można wywołać arrow function z operatorem new
Brak zrozumienia czym jest THIS
Do zrozumienia this trzeba pamiętać o dwóch rzeczach - wszystko w JS jest obiektem i this jest wszędzie. Więcej szczegółów w artykule.
Złe korzystanie z clousures co powoduje wycieki pamięci
Tutaj zachęcam do zerknięca do artykułu - przykład kodu, który wyjaśnia wszystko.
MEGA artykuł. Otwiera oczy na niektóre problemy i braki w wiedzy.
Co trzeba wiedzieć o funkcyjnym JS?
Niezmienność stałych
Niestety w JS wszystko możemy mutować. Nawet const nie zapewnia niemutowalności mimo, że niektórzy tak sądzą. Mamy za to biblioteki, które to umożliwią.
Czyste funkcje
Funkcja jest czysta jeśli:
- zwraca zawsze tą samą wartość jeśli daliśmy identyczne wejście
- nie powoduje efektów ubocznych np.: zmienia coś w globalnym stanie
Higher Order Functions
HOF jest funkcją, która:
- przyjmuje funkcję jako argument, albo
- zwraca funkcję jako rezultat, albo
- oba powyższe punkty
Fajny artykuł, który tłumaczy podstawowe koncepty programowania funkcyjnego w JS. Jeśli nigdy tak nie pisałaś/pisałeś to koniecznie zerknij.
Testy E2E są świetne. Pozwalają przetestować całą aplikację albo przynajmniej najbardziej krytyczne ścieżki. Dzięki temu możemy mieć większą pewność, że nie doszło do regresji.
Ale są też minusy:
- E2E są potwornie wolne
- ciężkie do utrzymania i drogie
- może dochodzić do tzw.: flaky-test czyli sytuacji gdy test raz zwraca success a raz fail
Ale i tak warto je pisać. Przynajmniej dla najbardziej krytycznych ścieżek w aplikacji, by mieć pewność, że wszystko działa.
Artykuł stanowi świetne wprowadzenie do testów e2e więc polecam zerknąć.
Na jakie błędy możemy się natknąć w Node (lub sami takie zrobić)?
Blokowanie event loopa
Pamiętajmy - Node.js jest jednowątkowy więc blokowanie wątku ciężkim kodem synchronicznym powoduje, że cierpią wszyscy.
Wywoływanie funkcji callback więcej niż raz
Przed wprowadzeniem Promise'ów callbacki były standardem na radzenie sobie z kodem asynchronicznym. Przy tworzeniu funkcji, które z tego korzystają trzeba pamiętać o słowie return, by nie doprowadzić do kilkukrotnemu wywołaniu
Callback hell
Wszyscy co pracowali z JS sprzed czasów Promise'ów to pamiętają. I nie chcemy do tego wracać.
Oczekiwanie, że callbacki działają synchronicznie
W sumie dotyczy też Promise'ów. Musimy pamiętać, że jest to kod asynchroniczny i trzeba go specjalnie obsłużyć.
Korzystanie z exports zamiast module.exports
Rzucanie wyjątkami w callbackach
Pamiętamy, że jest to kod asynchroniczny więc możemy ominąć blok try-catch i błąd poleci w świat.
Zakładanie, że liczba jest typu Integer
Ignorowanie Streaming API
Korzystanie z console.log do debugowania
Są biblioteki specjalnie do tego przeznaczone, które działają lepiej.
Tworzysz mikroserwisy czy miniserwisy?
Mikroserwis jest serwisem, który jest odpowiedzialny za jeden element(funkcjonalność) i jest niezależny od klienta. Jeżeli jest zależny od czegoś to możemy mówić o miniserwisie.
Taką niezależność można uzyskać mając Message Bus. Co nam to daje?
- architektura jest reaktywna
- łatwiejsze skalowanie horyzontalne
- dodawanie nowych serwisów nie ma wpływu na klienta
- odporniejsza architektura
Ciekawy artykuł jeśli chodzi o mikroserwisy. Do przeczytania przy kawie.
|
