DebugowanieAktywny NR.8 Jestem programistą od 5 lat i pracując – zwłaszcza przy aplikacjach legacy zdałem sobie sprawę jak ważne jest debugowanie kodu. Można by powiedzieć, że debugowanie kodu jest ważniejsze niż jego pisanie. Nie ma co ukrywać w dużych firmach bardziej dbamy o gotowe aplikacje niż pisanie nowych.

Nie ma co ukrywać to będzie główne zajęcie w twojej karierze. Jak jednak tę aktywność zamienić w produktywność.

Debugowanie kodu to nie sztuka.  Debugowanie kodu to cierpienie. Trzeba jednak znaleźć swoją drogą w tym wszystkim.

Debugowanie ponad cierpieniem

Za pierwszym razem nikt nie stworzy doskonałego kodu. Co więcej, trudno oczekiwać, że aplikacja, która ma 10 lat w przypadku X,Y,Z,A nie tworzy jakiegoś problemu, który wcześniej nie był wykryty.

Zdolność znajdowania błędów i ich naprawa jest ważna i jest częścią twoich umiejętności, które dadzą ci pieniądze.

Jest to najtrudniejsza zdolność do nauki i jest to najtrudniejsza umiejętność do przekazania jej jako nauczyciel.

Oczywiście uczenie się tego, jak kod działa krok po kroku jest proste, ale to za mało.

Musisz logicznie rozumieć co się dzieje, co może się dziać i co się nie dzieje na pewno w takim kodzie. Musisz być kreatywny w rozumieniu, dlaczego dany problem występuje, gdy go nie widać.

To jest trudne. Jak więc osiągnąć ten stan ZEN i debugować kod ponad cierpieniem.

1. Poznaj narzędzia

Ustaw breakpointy. Ustaw śledzenie zmiennych. Postaw zakładki w kodzie. Przechodź po kodzie krok po kroku.

To są podstawy, ale jeśli nie umiesz korzystać z narzędzi, to na tym etapie będziesz miał problem.

Moja aplikacja legacy była napisana specyficznie pod IE8. W pewnym momencie śledzenie kodu z poziomu przeglądarki okazało się zbyt trudne. Nagle odkryłem, że kodu JavaScript wystarczy aby w wybranych miejscach dodał on słowo

debugger

Chciałem uzyskać wizualizację kodu po stronie Visual Studio, mimo iż wcześniej nie mogłem się połączyć. Wynikało to z tego, że aplikacja IE otwierała okna w oknie i nie było mowy o debugowaniu okna, gdy debuguję aplikację.

Warto sprawdzić co nasze narzędzia, przeglądarki potrafią. Ułatwić sobie można życie na wiele dni.

2. Załóż, że wszystko jest spie###one

Zakładanie, że coś “na pewno” działa i to na pewno nie jest to, wiele razy kopnęło mnie w zad. Niestety, ale musisz założyć, że wszystko jest skopane, dopóki tego na swoje oczy nie sprawdzisz.

Kto wie, być może właśnie zmarnowałeś 3 dni, bo uznałeś z góry, że pewna przyczyna nie może wystąpić.

Na ślepo więc nie wierz, że coś na pewno działa. Zwłaszcza jeśli jest to twój kod.

Warto przygotować sobie kartkę papieru i krok po kroku eliminować powody, dla których aplikacja może nie działać. Pilnuj swoich założeń, bo kod, mimo iż jest logiczny, to nie można mu wierzyć, dopóki się tego nie zobaczy.

3. Skup się na poszczególnych regionach

Debugowanie kodu od początku do końca to bardzo męczący proces i będę szczery nawet niewykonalny przy gigantycznych śmieciowych aplikacjach. Sam się o tym przekonałem.

Dlatego skupiaj się na pojedynczych regionach. Gdy uznasz, że tam błędu nie ma szukaj gdzie indziej.

4. Małe modyfikacje

Gdy sytuacja wciąż nie jest jasna. Trzeba sobie dopomóc i wymusić działanie zdradliwego kodu jeszcze bardziej. Na szczęście kod i aplikacja to nie pacjent, więc możesz celowo szkodzić aplikacji i ją modyfikować w zły sposób, aby błąd okazał się bardziej wyraźny.

Zadaj więc sobie pytanie. "Jeśli zmienię ten kod, to powinno stać się to, ale czy tak będzie?”

O dziwo ta strategia też wiele razy mnie uratowała.

5. Poproś o pomoc i opisz swój problem

Wiele razy zdarzyło mi się i byłem obserwatorem niesamowitego fenomenu. Każdy w pewnym momencie łapie doła i chce się poddać.

Pojawia się kolega, który chce pomóc tyle tylko, że aby tej pomocy udzielić musi się dowiedzieć w czym jest problem. Tutaj może pojawić się magia. Programista, tłumacząc kod i dlaczego z nim utknął nagle zaczyna rozumieć to, czego jeszcze nie sprawdził, albo w czym tak naprawdę jest błąd.

Co ciekawe ten sposób też działa w prawdziwym życiu. Każdy czasem potrzebuje tylko kolegi słuchacza do ruszenia swoich myśli do przodu.

6. Zrób przerwę

Nic nie rusza do przodu. Jest późna pora. Nie ma co – już nic nie zdziałasz. Czas na przerwę.

Umysł musi się czasem odświeżyć. Możesz tak zamarznąć w swoim myśleniu, że stracisz rozwiązanie problemu. Przerwa jest potrzebna. Myślenie w zamkniętej pętli wcale nie ułatwia sprawy.

Podsumowując

Miałem okres w karierze, w którym każdy dzień zaczynał się od listy 35 bugów. Gdy je naprawiłem przychodziły do mnie kolejne 4 błędy. Nie było sympatycznie. Tak wyglądała moja praca przez 5 miesięcy.

Nawet jednak w takim piekle nauczyłem się czegoś pożytecznego. To co robisz nie jest łatwe. Powiedziałbym, że debugowanie kodu jest trzy razy trudniejsze i irytujące.

Pamiętaj jednak, że istnieje debugowanie ponad cierpieniem.