Kiedy mówimy o debugowaniu, ważne jest, aby zrozumieć, co może pójść nie tak i
w jakich sytuacjach możesz chcieć debugować kod lub uniknąć błędów, a
najbardziej oczywistą rzeczą, która może pójść nie tak, jest awaria aplikacji lub otrzymywanie Komunikat
o błędzie. W fazie
rozwoju jest to czerwone pole, które nakłada się na Twoją aplikację, co widzieliśmy już wcześniej w tym kursie, a te komunikaty o
błędach są oczywiście wyraźnym znakiem, że coś jest nie tak z twoim kodem.
Bardziej subtelne są błędy logiczne. W aplikacjach na pewno w pewnym momencie będziesz mieć
pewne zachowanie, które może nie mieć sensu lub gdy coś po prostu nie działa tak, jak powinno.
Nie pojawia się błąd, ale aplikacja działa nieprawidłowo,
działa
niepoprawnie i zazwyczaj występują pewne błędy logiczne, które to powodują.
I na koniec, masz interfejs użytkownika, styl, układ, wrażenia użytkownika, które
chcesz stworzyć, a może to jest wyłączone, może masz coś,
co po prostu nie wygląda lub nie wygląda tak, jak powinno. i jest to również coś, co może
pójść nie tak i którego należy unikać. Obecnie typowymi przykładami komunikatów o błędach lub
przyczynach komunikatów o błędach są błędy składniowe, w których po prostu masz literówkę w kodzie lub zapomniałeś nawiasów
klamrowych zamykających, coś w tym rodzaju, ale także po prostu błędy w
kodzie, na przykład wiersz kodu gdzie używasz wartości, której tak naprawdę
nigdy nie ustawiłeś, więc próbujesz na przykład obliczyć coś o nieokreślonej wartości lub parsować ciąg, który
jest faktycznie niezdefiniowany, coś
w tym rodzaju, co zwykle prowadzi również do błędów. A potem masz specjalny rodzaj błędu i są to błędy
nieuniknione, jak lubię je nazywać.
To nie znaczy, że są to błędy, których nie można uniknąć, ponieważ po prostu
nie jesteś
wystarczająco dobry jako programista, zamiast tego mam na myśli błędy, które mogą wynikać z Twojego żądania sieci i użytkownicy
aplikacji nie mają połączenia sieciowego lub że piszesz do systemu plików i jakoś ten dostęp jest zablokowany, więc nie możesz mieć
pewności, że nigdy nie zawiedzie, gdy użytkownicy korzystają z Twojej aplikacji, ponieważ nie możesz kontrolować, w jaki sposób korzystają z Twojej aplikacji lub w
jakich okolicznościach używają Twojej aplikacji i w przypadku takich błędów możesz także znaleźć strategie, w których nie można
uniknąć błędu, ale gdzie można sobie z tym poradzić. W przypadku błędów logicznych typowym przykładem może
być niepożądane lub nieoczekiwane zachowanie aplikacji i oczywiście chcesz się ich pozbyć, a także nieoczekiwanego
lub nieobsługiwanego zachowania użytkownika, aby użytkownicy korzystali z Twojej aplikacji w sposób nie zamierzali ich używać,
więc podczas testowania aplikacji podczas programowania chcesz
być naprawdę kreatywny i dowiedzieć się, czy użytkownicy mogą dostać się
do miejsc, w których mogą kontynuować lub w których aplikacja nie działa poprawnie, aby być może użytkownicy śledzili
pewna sekwencja kroków, która prowadzi do błędu, do błędu logicznego, może w pewnym momencie
brakuje niektórych danych wejściowych i nie sprawdzasz, czy dane wejściowe zostały ustawione, a zatem przy braku
tego ustawienia, możesz spowodować inny problem lub popełniłem kolejny błąd,
więc coś takiego.
Na koniec, jeśli mówimy o stylizacji, układzie, oczywiście możemy mieć nieoczekiwany lub niewłaściwy styl, więc
testujemy aplikację i widzimy, że nie wygląda to tak, jak powinno, a może
po prostu mamy niespójne wyniki na na różnych urządzeniach,
być może nasza aplikacja wygląda dobrze na iOS, ale nie na Androida lub wreszcie, może mamy układ, który po
prostu nie działa lub nie działa poprawnie na niektórych urządzeniach lub orientacjach.
Być może nasze treści nie mieszczą się na ekranie na bardzo małych
urządzeniach, to wszystko, co również chcemy wykluczyć. Teraz to możesz debugować,
jak debugujesz? Jakie masz narzędzia do debugowania błędów?
Teraz najbardziej oczywistym narzędziem, które dostajesz, a jednak narzędziem, które wielu ludzi przeoczy lub po prostu w ogóle nie patrzy,
są komunikaty o błędach,
poważnie przeczytaj komunikaty o błędach, które otrzymujesz.
Widziałem to tak często na moich kursach, że studenci dostają jakiś błąd i po prostu idą Och, mam błąd,
zrzut ekranu lub skopiuj i wklej go w sekcji Pytania i odpowiedzi, a czasami błędy mogą być bardzo trudne
do debugowania lub zrozumienia lub potrzebujesz doświadczenia, aby dowiedzieć się, co dokładnie poszło nie tak, ale
szczerze mówiąc, często komunikaty o błędach są naprawdę jasne, co poszło źle, lub nawet zawierają rozwiązanie dotyczące
sposobu naprawienia błędu.
I na koniec, po prostu biorąc komunikat o błędzie i googlując go, często prowadzisz bardzo daleko, ponieważ są
szanse, że nie jesteś pierwszym, który go dostanie.
Załóżmy teraz, że nie wyświetla się komunikat o błędzie, ale aplikacja nie działa poprawnie w pewnym
miejscu lub nie masz pewności, czy jakaś wartość jest ustawiona poprawnie w jakiejś części kodu.
Bardzo łatwym sposobem na sprawdzenie swojego kodu i sprawdzenie wartości, z którymi pracujesz
w kodzie, jest użycie starego, dobrego dziennika konsoli. Teraz debugowanie dziennika konsoli nie ma najlepszej reputacji
i rzeczywiście nie jest tak świetne, jeśli debugujesz bardzo skomplikowany
problem, ale po prostu wpadniesz na pomysł przepływu kodu lub niektórych wartości, z którymi pracujesz ,
wspaniale.
Możesz po prostu zrzucić go do swojego kodu, a następnie dowiedzieć się, jakiej wartości używasz, w którym momencie
lub jak coś się zachowuje w określonej sytuacji lub czy coś w ogóle się wykonuje,
a zatem zdecydowanie jest to coś, co powinieneś również zrobić.
Teraz w przypadku bardziej skomplikowanych problemów lub jeśli naprawdę chcesz krok po kroku krok po kroku, korzystanie z debugera
Chrome i punktów przerwania jest doskonałym narzędziem i jest obsługiwane przez React Native, zarówno podczas korzystania
z expo, jak i nie korzystam z expo. Tam możesz naprawdę zanurzyć się głęboko w kodzie i
poczuć, jak on działa, i przejść go krok po kroku i zaglądać do kodu podczas jego
wykonywania.
Spójrzmy teraz na te rzeczy.