Jeśli natknąłeś się na błąd, w którym wydawało się „niemożliwe” aby zrozumieć, co się dzieje – co tak właściwie sprawiło, że tak się czułeś?

Przyczyny w skrócie

Oczywiście błędy zawsze zdarzają się z logicznych powodów, ale zdecydowanie natykamy się w pracy na takie błędy, które zdają się być nadprzyrodzone – dopóki ich nie rozgryziemy, naturalnie. Podstawowe przyczyny, dla których tak się dzieje to fakt, że:

• trudno odtworzyć błąd w warunkach testowych,
• nie rozumiesz dobrze całego systemu, w którym program działa
• trudno jest uzyskać dane o błędzie,
• jedno z Twoich założeń jest błędne,
• błąd jest naprawdę złożony.

Przypatrzmy się wybranym przypadkom.

Trudno odtworzyć błąd w warunkach testowych

Niektóre błędy to błędy, które zdarzają się tylko kilku użytkownikom, nie mogą być konsekwentnie odtwarzane przez użytkowników lub w ogóle we własnym zakresie i mają nieco różne opisy w każdym zgłoszeniu błędu. Walcząc z nimi człowiek ma ochotę czasem zmienić zawód, bo stwierdza że się do niczego nie nadaje.

Przyczyn tego, że nie możemy odtworzyć błędu, może być kilka. Błąd może być niedeterministyczny - uruchamiasz swój program z dokładnie tymi samymi danymi wejściowymi 1000 razy i tylko raz się nie udaje. Zdarza się to często w warunkach wyścigu w programach wielowątkowych.

Inny przykład to sytuacja, gdy błąd zdarza się tylko w produkcji. Wiele błędów jest trudnych do odtworzenia w środowisku deweloperskim albo dlatego, że trudno jest dokładnie określić, które dane wejściowe powodują błąd, albo też dlatego, że występują one tylko w określonych warunkach (takich jak duży ruch), które są trudne do odtworzenia.

Możesz też po prostu nie mieć dostępu do konkretnej maszyny, na której błąd występuje.

Irytujące jest też to gdy błąd bardzo wolno się reprodukuje. Istnieją błędy, w których dokładnie wiesz, jak je sprokurować ale odtworzenie błędu zajmuje dużo czasu. Trudno jest walczyć z błędem, gdy możesz spróbować tylko jednego albo dwóch eksperymentów dziennie.

Nie rozumiesz dobrze całego systemu, w którym program działa

Często jest tak, że błąd dotyczy systemu lub koncepcji, o której nie wiedziałeś Czasami błędy są spowodowane przez część systemu, o której istnieniu nawet nie wiedziałeś a wtedy trudno jest się zorientować, że to właśnie tam tkwi problem.

Jedno z Twoich założeń jest błędne

Na przykład w prawie wszystkich przypadkach zakładamy, że kompilator nie popełnia błędu i że błąd jest w naszym kodzie. Ale błąd kompilatora też się zdarza! Inna sytuacja: zakładasz, że Twój nowy kod jest uruchamiany, podczas gdy w rzeczywistości coś jest buforowane i uruchamia się inny kod. Może przyjąć, że jakaś zmienna środowiskowa jest ustawiona, gdy tak naprawdę nie jest. Szukasz tydzień błędu w kodzie a okazuje się, że za brak komunikacji z urządzeniem jest odpowiedzialny uszkodzony kabel USB. Albo korzystasz z dokumentacji, której ślepo wierzysz – a ona ma błąd o którym dowiesz się po kilku dniach przeglądania forum albo listy mailingowej.

Czasami też na początku debugowania widzisz coś, co wygląda bardzo podejrzanie i spędzasz dużo czasu na przyglądaniu się temu bliżej ale potem okazuje się, że jest to całkowicie niezwiązane z błędem. Zmarnowałeś czas, owszem, ale pamiętaj - jest to całkiem normalne i często nie oznacza, że zrobiłeś coś złego (nie da się obrać idealnej, najskuteczniejszej ścieżki do zrozumienia błędu za każdym razem!).