|   |   | 

Człowiek się uczy na błędach, czyli co łączy Thomasa Edisona z debugowaniem

Utarło się, że pierwszym “bugiem” w branży IT była ćma, która w połowie XX wieku spowodowała awarię w jednym z przedpotopowych komputerów. Tak naprawdę jednak termin ten pojawił się ponad 140 lat temu, gdy szczytem innowacji była elektryczna żarówka.

Od tamtych czasów dzielą nas milowe kroki, ale… wciąż popełniamy błędy. Nawet podczas tak precyzyjnego zajęcia jak programowanie. Zanim wyjaśnimy takie pojęcia, jak reprodukcja błędu, wyizolowanie jego źródła i usunięcie defektu, sprawdźmy najpierw, od czego to wszystko się zaczęło.

Bug w historii

Podobno było w to roku 1878, gdy amerykański wynalazca, znany dziś m.in. z tego. że opatentował żarówkę elektryczną, użył w jednym ze swoich listów określenia “bugs” opisując usterki techniczne, z którymi się borykał. 

Znacznie więcej niż Thomas Edison do historii debugowania wniosła jednak admirał Grace Hopper. Amerykańska pionierka informatyki, która przez wiele lat służyła w marynarce wojennej USA, wsławiła się także pracą przy archaicznych jak na dzisiejsze czasy komputerach Harvard Mark I i Mark II. Pamiętamy ją jednak również dlatego, że to właśnie ona spopularyzowała określenie “bug” w informatycznym słowniku. 

Wzięło się to stąd, że podczas udoskonalania komputera Mark II do wnętrza maszyny w jakiś sposób przedostała się ćma (owad, robak, czyli po angielsku bug), powodując awarię. Naprawę usterki określono wówczas jako debugging, czyli odpluskwianie.

Czym jest debugowanie?

Dla początkujących nazwa ta wciąż może brzmieć tajemniczo, ale im szybciej dowiesz się, co oznacza to “zaklęcie”, tym prędzej zaczniesz wykorzystywać możliwości, jakie daje komputer. Jeśli tylko umiesz o to poprosić, maszyna może wyręczyć Cię w wielu żmudnych i czasochłonnych czynnościach. 

No to jeszcze raz. Bug to usterka w oprogramowaniu, która sprawia, że nie działa ono w sposób prawidłowy. Bug to insekt, pluskwa, niechciany robak – oczywiście w sensie metaforycznym – pojawiający się w oprogramowaniu najczęściej w czasie tworzenia kodu źródłowego, lub na etapie projektowania. Sprawcami tych błędów są programiści, developerzy, webmasterzy, czyli ci, którzy odpowiadają za proces powstawania programu. Użytkownicy są zaś tutaj ofiarami takich usterek.

I tak, jak to bywa ze szkodnikami w prawdziwym życiu, tak i w programowaniu istnieją wypracowane metody, które pozwalają się pozbyć natrętnych “insektów”. Służą do tego tzw. debugery. To programy, dzięki którym możemy dokładnie określić miejsce wystąpienia błędu w kodzie, a następnie je naprawić. Innymi słowy, debugowanie to proces usuwania błędów z oprogramowania.

Jak wygląda proces debugowania

Koduję od kilkunastu lat i jeszcze nie udało mi się napisać aplikacji wolnej od błędów. Przywykłem już do tego. To wszystko jest częścią procesu bycia programistą – pisze na stronie Codementor.io Matt Goldspink.  Coś w tym jest, jednak zdarzają się takie chwile, gdy nawet doświadczenie i rutyna nie uchronią przed prawdziwą katastrofą. – Najczarniejsze chwile zdarzają się wówczas, gdy usterkę odkryje ktoś, odpowiedzialny za kontrolę jakości jego pracy – przyznaje. Co zrobić, żeby takich wpadek było jak najmniej? 


Najczęściej podział poszczególnych etapów debugowania mieści się w 5 punktach:

  1. Reprodukcja, czyli odtworzenie błędu 
  2. Wyizolowanie źródła błędu 
  3. Identyfikacja przyczyny awarii 
  4. Usunięcie defektu 
  5. Weryfikacja powodzenia naprawy

Zawsze odtwarzaj swój błąd, zanim zaczniesz modyfikować kod. Nie dokonuj losowych założeń. Nie szukaj po omacku. Bez odtworzenia prawdziwej natury błędu nie będziesz w stanie go naprawić. A jeśli nie potrafisz zrobić tego samodzielnie, znajdź kogoś, kto pomoże. Twój czas jest cenny, nie marnuj go! – radzi Matt Goldspink. Następnym krokiem będzie wyizolowanie źródła usterki, czyli wykluczenie czynników, które nie mają bezpośredniego związku z błędem. Doświadczeni programiści odradzają debugowanie całego programu. Należy szukać tam, gdzie coś nie działa, analizować podejrzane fragmenty kodu, ignorując te, które nie przyczyniają się bezpośrednio do powstania błędu. Gdy błąd został wyizolowany, trzeba go teraz odszukać w kodzie, tu zpomocą przychodzi właśnie debuger, a następnie dokonujemy wyboru: usuwać, czy nie usuwać? Nawet mimo pewności, że “bug” jest przyczyną zmartwień programisty, nie wolno podejmować pochopnych decyzji. Każda zmiana w kodzie może bowiem wywoływać zmiany w innych miejscach. Zanim więc zaczniesz coś robić, przemyśl najpierw, jaki będzie to miało wpływ na cały kod. I wreszcie weryfikacja powodzenia naprawy, czyli sprawdzenie, czy wszystko działa tak, jak trzeba. Do tego celu służą testy oprogramowania. Jeżeli nie jesteś testerem, poproś o to któregoś z zawodowców. To właśnie testerzy są odpowiedzialni za wyłapywanie “bugów” i raportowanie ich deweloperom. Czym się zajmuje na co dzień tester oprogramowania i jak nim zostać? Posłuchaj wywiadu Kodilla.com.:

Przeczytaliście uważnie nasz artykuł? No to teraz pytanie za milion dolarów 🙂

Opublikowano w IT

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *