|
Nie ma nic gorszego niż błąd, który nic nie mówi.
Wyobraź sobie.
Piątkowe popołudnie.
Nagle telefon - aplikacja leży trzeba szybko naprawić.
Patrzysz w logi a tam jedynie - Something went wrong
I co teraz?
Na jakie pytania powinien odpowiadać błąd?
- Co się stało? np.: brak danej A z endpointa D
- Gdzie się to stało? plik, linia, przeglądarka, system - wszystko to może mieć znaczenie
- Co możemy zrobić, by się nie powtórzył
W artykule znajdziesz więcej przykładów jak opisywać błędy. Wykorzystują tam swoje narzędzie, ale można to przenieść do rozwiązania używanego przez ciebie.
Szybka powtórka z paradygmatów programowania.
Programowanie proceduralne
Od tego najczęściej zaczynamy. Programowanie oparte o funkcje (ale nie mylić z funkcyjnym) i proste struktury danych.
Programowanie funkcyjne
Tutaj funkcje są najważniejszym elementem. Najczęściej spotkasz się tu z określeniami pure functions, higher order functions.
Programowanie logiczne
Bardzo mocno związane z matematyką i logiką. Pozwala na podstawie podanych przesłanek wydedukować odpowiedź. Przykładem języka jest Prolog - ja go miałem na studiach i nawet było zabawne.
Object-Oriented Programming
Programowanie oparte o klasy i enkapsulację danych oraz zachowań w jednym obiekcie. Łatwo jest przenieść obiekty ze świata rzeczywistego do tego programowania i zamodelować
Dużo więcej wiedzy w artykule. Polecam przeczytać do kawy. A może trafi się takie pytanie na rozmowie kwalifikacyjnej. Albo sam zadam takie pytanie 🤔
Co to jest Passwordless Authentication?
W skrócie są to wszystkie metody, które rezygnują z uwierzytelnienia za pomocą hasła na rzecz innych metod.
Jakie są opcje?
- Biometryczne np.: odcisk palca czy twarz, skan oka itd.
- Magic LInks
- Jednorazowe kody i hasła
- Dodatkowe urządzenia uwierzytelniające
W artykule dodatkowo plusy i minusy oraz najpopularniejsi dostawcy takich rozwiązań.
If'y są fajne, ale ich nadmiar psuje czytelność całego kodu.
Bardzo często możemy się ich pozbyć, modyfikując delikatnie kod.
Guard and Early Return
Early return (lub early exit) jest bardzo fajną metodą na rozbijanie zagnieżdżonych if-else. Zamiast robić kolejne else'y tworzymy pojedyncze if'y i zwracamy wartość. Bardzo czytelne i upraszcza testowanie i dodawanie nowych przypadków w przyszłości
Table-Driven Method
Czyli sytuacja, gdy musimy przemapować jedną wartość w inną. Zamiast robić ścianę if'ów korzystamy z tablicy i wyliczamy wartość. Ja też lubię wykorzystywać do tego obiekty.
Inne zastosowanie tablic to konieczność sprawdzenia czy dana wartość jest jedną z obsługiwanych np.: rola. I zamiast if(role==='1' || role==='3' || ....) można zrobić if([1,3].includes(role))
Extract
Zaawansowane warunki warto wyciągnąć do osobnych funkcji i wtedy będzie można skorzystać np.: z early return. No i będziemy mogli osobno przetestować funkcję
Default Value and || operators
Czasami chcemy użyć if'a by obsłużyć brak jakieś danej. Możemy to obejść operatorem || i wartościami domyślnymi.
W artykule więcej przykładów i omówienie powyższych przypadków. A może ty masz jakiś specjalny sposób radzenia z if'ami. Chętnie przeczytam, co robisz, by ograniczyć ilość if'ów w kodzie.
Nie nadużywaj Try-Catch
Nie trzeba wszędzie wrzucać try-catch i oczekiwać błędów (w sumie to trochę źle świadczy o programiście, co nie?). Zabezpieczmy te najbardziej wrażliwe miejsce/najbardziej podatne na błąd a resztę zabezpieczmy jakimś top level try-catch
Nie wykorzystuj metod, które występują w jednej przeglądarce
Wiele nie trzeba wyjaśniać. Czasami są fajne funkcje, metody, ale działają tylko w jednej przeglądarce. Zawsze sprawdzaj, czy to z czego korzystasz jest standardem wszędzie
Pamiętaj o await gdy masz funkcję asynchroniczną
Jeśli nie dasz await to kod poleci dalej i catch nie złapie ewentualnego błędu.
Nie wykorzystuj błędów do kontroli sterowaniem programu
Jeśli wpadniesz na pomysł, by przeskoczyć do innego miejsca w kodzie to NIE. Zapomnij o tym pomyśle i pisz w notatniku przez resztę dnia za karę ;)
Dodaj narzędzie do zbierania wszystkich błędów
Sam korzystam najczęściej z Sentry i bardzo dobrze mi się z tym pracuje.
Jeszcze więcej wiedzy i przykładów w artykule.
Błędów nigdy się nie pozbędziemy z kodu. Możemy minimalizować ich ilość, ale zawsze coś zostanie. I od nas zależy, czy obsłużymy je poprawnie.
Rodzaje błędów
Mamy 2 rodzaje błędów: operational i programmer.
Operational - powstają w czasie działania systemu i oznaczają wynik inny niż spodziewany np.: walidacja, timeout
Programmer - błędy w kodzie, zła logika, nieobsługiwane sytuacje itd.
Dobrze jest umieć rozpoznać te dwa rodzaje błędów. Błędy od programistów muszą być szybko poprawione natomiast te operational mogą służyć do monitorowania stanu aplikacji.
Obsługa błędów
Dobrze mieć jedną funkcję/serwis odpowiedzialny za łapanie błędów, ich obsługę i logowanie (do naszych logów albo jakiegoś zewnętrznego serwisu)
W artykule przykłady kodu i więcej o tym dlaczego należy poprawnie łapać błędy w aplikacji.
Wszyscy staramy się trzymać dobrych wzorców przy tworzeniu oprogramowania. A co jak nie znamy dobrych wzorców? Najlepiej unikać tych złych.
Antywzorce w React
- Wsadzanie wszystkiego w Redux
- Trzymanie wszystkiego jako stan
- Przekazywanie propsów do dziecka przez {...props}
- Deklarowanie komponentów wewnątrz komponentów
- Przekazywanie za dużo informacji do komponentu
- Zbyt wczesna optymalizacja
- Skomplikowana struktura komponentu
Dokładniejsze wyjaśnienie i przykłady kodu w artykule. Polecam - szczególnie, gdy zaczynasz przygodę z React( napisz też wtedy do mnie - mam pytanie Co sprawiło ci najwięcej trudności na początku? )
|
