Błędy w kodzie to coś normalnego. Zjawisko, z którym musi radzić sobie każdy programista na porządku dziennym. Jednak kiedy jesteśmy na początku przygody z programowaniem, błąd w kodzie może u nas wywoływać panikę. Przynajmniej u mnie tak było. Poradziłam sobie z tym uczuciem tworząc swój system na debugowanie kodu. Korzystam z niego do dzisiaj i chcę się z Tobą nim podzielić.
Błędy w kodzie – czy już można panikować?
Gdy zaczęłam pierwszą pracę na juniorskim stanowisku, wszystko było dla mnie nowe (pisałam o tym m.in. w tym wpisie). Ogarnianie nowych narzędzi, technologii, sposobu pracy. Było tego naprawdę dużo. Kiedy więc w końcu skonfigurowałam środowisko i chciałam zabrać się do pracy, a w konsoli pojawiał się błąd za błędem, byłam naprawdę przytłoczona. Miałam wrażenie, iż kręcę się w kółko. Czerwony kolor w narzędziach deweloperskich Chrome’a powodował u mnie palpitacje serca. Nie miałam pojęcia, jak się zabierać za rozwiązywanie problemów w kodzie.
Gdy prosiłam o pomoc, często dostawałam odpowiedź typu “zrób tak i tak”. Miałam wrażenie, iż wszyscy wiedzą, co robić, tylko nie ja. Kiedy już opanowałam pierwszą reakcją, czyli panikę, podeszłam do problemu metodycznie. Zauważyłam, iż odpowiedzi doświadczonych kolegów i koleżanek się powtarzają. Powtarzały się też błędy, które widziałam. Zrozumiałam, iż radzenie sobie z błędami to jest część mojej pracy (ba, choćby ta większa!). Musiałam po prostu to ogarnąć, zamiast denerwować się, gdy coś nie szło po mojej myśli.
I narodził się pomysł na mini procedury
Zapisywałam najczęstsze błędy w kodzie plus to, jak można sobie z nimi poradzić. Pojawiły się też czynności, które mogłam wykonywać za każdym razem, gdy coś było nie tak, a ja chciałam mieć pewność, iż błąd, z którym mam do czynienia, to jest faktycznie błąd kodu. A nie coś, co ja źle zrobiłam i mogę gwałtownie naprawić.
Podobną taktykę zaczęłam stosować, gdy kod nie działał tak, jak chciałam. Tzn. w przypadku, gdy nie było błędu w konsoli albo w terminalu, ale aplikacja nie zachowywała się tak, jak miała. Oczywiście dużą część stworzonych przeze mnie mini procedur była specyficzna dla danego projektu czy technologii. Jednak widzę, iż można z nich wyciągnąć kroki, które są uniwersalne. Znajdziesz je poniżej.
Ten wpis został zainspirowany jedną z ostatnich lekcji na kursie Vanilla JS Academy, na którym jestem. Prowadzący dzielił się tam swoim sposobem na błędy w kodzie i pomyślałam, iż fajnie byłoby zrobić coś takiego. A przy okazji porozmawiać o tym, czy Ty wykonujesz jakieś konkretne kroki, gdy kod nie działa (napisz do mnie i podziel się koniecznie).
Opisane poniżej procedury nie są jedynymi adekwatnymi. Zaryzykuję choćby stwierdzenie, iż pewnie istnieją jakieś lepsze sposoby. Cały czas staram się usprawniać sposób debugowania kodu. Na chwilę obecną to jest to, co się u mnie sprawdza. Zachęcam Cię do testowania poniższych rad i szukania swoich własnych kroków do lepszego debugowania.
Uniwersalne kroki
Najpierw chcę Ci przedstawić kilka uniwersalnych kroków, które można wykonać. Nie są one związane z tym, czy błąd jest wyświetlony w konsoli, czy kod nie działa tak, jak powinien.
Sprawdzam, czy zapisałam wszystkie zmiany
Na sam początek sprawdzam, czy na pewno zapisałam zmiany we wszystkich plikach, na których pracowałam. Błąd może zwyczajnie wynikać z tego, iż zmieniłam coś w jednym pliku, korzystałam z tego w drugim i nie zapisałam wprowadzonych zmian. Edytor czy IDE, w którym pracujesz, na pewno ma wskaźnik pokazujący, czy plik jest zapisany, czy nie. W Visual Studio Code jest to biała kropka przy nazwie pliku (na górnym pasku) i półprzezroczysta kropka przy nazwie folderu, w którym są niezapisane pliki (w bocznym widoku wszystkich plików).
Sprawdzam, czy pracuję na dobrej wersji kodu
Szczególnie przydatne, gdy pracujesz w zespole, więc nie ty jedna/jeden zajmujesz się kodem. Zawsze sprawdzam, czy na pewno mam zaciągnięte ostatnie zmiany, zanim zabiorę się do dalszego debugowania. Błędy w kodzie mogą wynikać po prostu z tego, iż mam nieaktualny wersję lokalnie.
Odświeżam stronę/odpalam projekt raz jeszcze
Rada w stylu “proszę to wyłączyć i włączyć raz jeszcze”. Jakby głupio nie brzmiało, naprawdę pomaga w wielu przypadkach. Strona czy projekt mogą nie działać, bo patrzę na nieaktualną, nieodświeżoną wersję. choćby jeżeli wydaje Ci się, iż masz przed sobą odpowiednią wersję, warto raz jeszcze włączyć podgląd w przeglądarce albo odpalić projekt na nowo. Opcjonalnie w tym przypadku można też wyczyścić dane przeglądarki, czy to cookies, czy local lub session storage (jeśli oczywiście wiesz, iż Twoja strona czy projekt się na nich opiera).
Sprawdzam, czy projekt jest dobrze “odpalony”
Co to dla mnie oznacza? Sprawdzam, czy projekt dobrze się zbudował, czy mam podpięte odpowiednio wszystkie pliki. Czy wymagane pliki są zaimportowane. Upewniam się, iż działa Internet (jeśli wymaga tego projekt) i iż jestem w dobrej sieci. Według mnie warto sobie stworzyć taką listę rzeczy, które muszą zostać spełnione, aby w ogóle projekt działał. To naprawdę oszczędza czasu, bo czasem męczymy się godzinę z jakimś problemem, a okazuje się, iż WiFi się przełączyło i dlatego mamy błąd.
Błąd w konsoli lub terminalu
Teraz zajmijmy się błędem, który pojawia się w konsoli albo w terminalu. Może być tak, iż aplikacja, czy strona nie buduje się wtedy wcale (ale nie jest to warunek konieczny). Co wtedy robię?
Dokładnie czytam wiadomość błędu
Wydaje się oczywiste, ale zdecydowanie oczywiste nie jest. Sama miałam ten problem, iż jak widziałam czerwoną planszę, to nie skupiałam się na jej treści. A w zdecydowanej większości przypadków, z treści błędu jesteśmy w stanie wywnioskować, co takiego się stało. Pewnie, zdarzą się też błędy, w stylu “masz błąd” i nic więcej i wtedy trzeba się trochę nagłowić. jeżeli komunikat, który widzisz, ma jakąś treść, dokładnie ją przeczytaj.
To naprawdę bardzo ważne. Nie raz prowadziłam warsztaty dla początkujących i wiem, iż jak nie ma się dużo do czynienia z kodem, łatwo zwyczajnie spanikować widząc błąd. Zdarzało mi się dostawać screeny z błędami, w których wyraźnie było napisane, co zrobić, aby się tego błędu pozbyć. A osoby, które wysyłały mi screeny, pytały, co mają robić. Wiem, iż to przychodzi z czasem, więc uczulam od razu – czytaj na spokojnie i zastanawiaj się, jakie kroki powinny być kolejne.
Stosuję się do instrukcji z komunikatu błędu
Komunikat błędu, który widzisz, może sugerować, co należy zrobić, aby błędu się pozbyć. Warto tego spróbować, zamiast wynajdywać koło na nowo. Może być też tak, iż błąd, który widzisz, zdarzył Ci się już wcześniej i wiesz, jak sobie z nim poradzić. Chodzi mi o to, iż komunikat może mówić na przykład, iż zmienna jest niezdefiniowana, wtedy od razu wiesz, iż należy ją zdefiniować albo iż zrobiłaś/zrobiłeś błąd w nazwie, bo na pewno tę zmienną masz zdefiniowaną.
Staram się zlokalizować linię/część kodu, która powoduje błąd
Jeśli nie jest to wyraźnie podane w komunikacie błędu, staram się zlokalizować część kodu, której ten błąd może dotyczyć. zwykle po prostu komentuję fragmenty i sprawdzam, czy błąd pojawia się nadal. Staram się tutaj doprowadzić, albo do wyświetlenia innego błędu, albo to zniknięcia błędu obecnego. Tak, błąd inny niż ten, z którym walczymy, to zdecydowanie krok do przodu, jakby pokrętnie to nie brzmiało. Jak już mam część kodu, której błąd dotyczy, dokładnie ją analizuję i staram się próbować różnych rzeczy, które pokrywają z tymi z kolejnej części (czyli co robię bezpośrednio z kodem).
Kod nie działa tak, jak powinien
Teraz chyba częstszy przypadek, czyli kod działa, nie mamy błędu, ale nie wszystko jest tak, jak powinno. Co wtedy robię?
Staram się znaleźć ostatnią działającą dobrze wersję kodu
To się sprawdza nie tylko, jak pracujemy w zespole, ale jak działamy sami. jeżeli dana funkcjonalność działała, a teraz nie działa, lokalizuję ostatnią wersję kodu, w której było dobrze. Sprawdzam, co zmieniło się od tego czasu. Biorę pod uwagę też zainstalowane paczki czy biblioteki.
Jeśli udaje mi się zidentyfikować zmiany – usuwam je i sprawdzam, czy faktycznie to pomaga. jeżeli tak, dokładnie analizuję, co robi kod, szukam błędów w logice. Jednym słowem – staram się sprawić, aby działało.
Jeśli ciężko mi zlokalizować ostatnią działającą wersję kodu (a wiem, iż taka była), korzystam z komendy git bisect. Pozwala ona cofnąć się np. o parę miesięcy, oznaczyć kolejne commity jako dobre albo złe i tym samym szukać, który commit wprowadził błąd do naszego kodu. Stosowanie git bisect super opisuje Maciej Aniserowicz w tym wpisie, więc odsyłam do niego po więcej szczegółów.
Szukam najmniejszego możliwego fragmentu kodu odpowiedzialnego za błąd
Moim celem jest znalezienie najpierw pliku, potem funkcji czy metody, a najlepiej linii powodującej, iż kod nie działa tak, jak powinien. Używam console.log, aby sprawdzić, do którego momentu jest dobrze. W metodach czy funkcjach zwykle robię console.log na wejście i wyjście (sprawdzam, jakie dane weszły, co zostały zwrócone). Korzystając z console.log, zawsze opisuję, co w nim wyświetlam, żeby uniknąć ściany logów w konsoli, które nic mi nie mówią.
Wiem, iż można też w takiej sytuacji korzystać z debuggera, ale ja nie posługuję się płynnie tym narzędziem, więc dużo go nie używam. Mam za to w planach go dobrze opanować, więc chętnie przygarnę wszystkie rady dotyczące debuggera.
Ustalam plan działania
Tutaj już wchodzimy w bardzo szczegółowe działania, więc myślę, iż nie ma sensu ich dokładnie opisywać, bo dużo zależy od tego, co chcę uzyskać i oczywiście, jakie dokładnie mam błędy w kodzie. Gdy udaje mi się zlokalizować, z jakiej linii albo fragmentu wynika błąd, ustalam plan działania.
Nie chodzi mi to o jakiej dalekosiężne plany, ale o podejście do problemu z głową. To znaczy – zakładam na przykład, iż spróbuję dodać console.log we wszystkich metodach odpalanych w danym fragmencie, sprawdzę, czy wszystkie dostają i zwracają odpowiednie dane, analizuję strukturę danych.
Rozpisuję logikę na kartce
Często też rozpisuję logikę działania kodu na kartce. Jak problem jest złożony, wypisuję, co ma robić kod w jakich momentach i sprawdzam po kolei, czy tak się dzieje. Więcej o tym, jak rozpisywać na kartce to, co robi kod, tłumaczyłam tutaj.
Wiele zależy od błędu, z którym mam do czynienia. Jak pracuję z wieloma komponentami, plikami czy klasami – sprawdzam, w jakiej kolejnością są ładowane pliki, czy nie pojawia się problem związany z nieodpowiednią kolejnością ładowania. Zapisuję na kartce, w jakiej kolejności powinny być i co dokładnie robią, aby potem łatwiej było mi prześledzić, co dzieje się w odpalanym programie.
Tworzę nowy branch i jak najczęściej commituję zmiany
Zanim zacznę wprowadzać zmiany w kodzie, który nie działa, tworzę nową gałąź (branch) w gicie. Dzięki temu mam możliwość zawsze wrócić do oryginalnego brancha bez konieczności cofania wprowadzonych zmian. Często dzieje się tak, iż za bardzo nakombinuję próbując rozwiązać problem i mam masę nowych błędów. Gdy jestem w takiej sytuacji, mogę porzucić zmiany, które zrobiłam i zacząć raz jeszcze.
Staram się równocześnie jak najczęściej commitować zmiany, które wprowadzam. Dokładnie opisuję, co zmieniłam. Potem wyświetlając listę commitów widzę, czego próbowałam. Mam też opcje wrócić do wybranego commita, jeżeli mam taką potrzebę.
I tak dalej…
Błędy w kodzie to taka trochę niekończąca się opowieść. Często coś się wysypuje i musimy sobie z tym radzić. Powyższe sposoby nie są niezawodne, ale pomagają mi ustrukturyzować debugowanie. Dają poczucie, że mam kontrolę nad tym procesem i dzięki nim trochę mniej się miotam, gdy kod nie działa.
Nie muszę chyba dodawać, iż debugowanie najlepiej ćwiczy się… debugując. A jak jesteś na początku drogi z kodem, warto ćwiczyć w praktyce jak najszybciej się da. Najlepiej tworząc swoje projekty! Między innymi o tym, jak się zabrać za swój pierwszy projekt, skąd wziąć na niego pomysł, jak wybrać technologie i zaplanować prace, opowiem podczas darmowego webinaru 8 lipca. Nie przegap i zapisz się już dzisiaj korzystając z formularza na tej stronie.
Jeśli przydała Ci się któraś z wymienionych przeze mnie metod, podziel się tym tekstem. Niech inne osoby też sprawniej poskramiają błędy w kodzie
A Ty masz swój system na debugowanie kodu? Napisz do mnie
albo maila na joanna[at]wakeupandcode.pl i pogadajmy. Chętnie poznam Twój punkt widzenia!
