Jeśli kodowałeś chociaż przez jakiś czas, prawdopodobnie masz już w pewnym stopniu opanowane debugowanie. Dla pozostałych z was mamy parę złotych zasad:
# 1: Nie bierz niczego za pewnik
Sprawdź wartości wszystkich zmiennych, uważnie przeczytaj i przejrzyj kod.
W dziewięciu na dziesięć przypadków, błąd kryje się w jednym obszarze problemu.
Nawiasem mówiąc, nigdy nie ukrywaj informacji przed kimkolwiek, kto chce Ci pomóc w debugowaniu. Pokaż mu działający kod i dane, a także wszystkie szczegóły komunikatów o wynikach i błędach. Ukrywanie informacji marnuje niepotrzebnie wszystkim czas.
# 2: Problem jest po Twojej stronie (chyba, że udowodnisz, że jest inaczej)
Kuszące jest wyciągnięcie wniosku, że błąd jest w bibliotece, języku, środowisku, narzędziach lub czymkolwiek innym. W rzeczywistości dla każdego błędu, który znajdziesz w cudzym kodzie, zazwyczaj znajdziesz co najmniej sto błędów we własnym.
Powinieneś więc założyć, że to twój kod jest problemem, tak długo dopóki nie udowodnisz absolutnie i ilościowo, że jest inaczej. Poproś w tym celu kogoś innego o sprawdzenie kodu, przeczytaj dokumentację, spróbuj odtworzyć problem w oddzielnym środowisku. Jeśli jesteś pewien, że Twój kod nie jest problemem, sprawdź ponownie.
# 3: Liczba przypadków błędów w kodzie jest nieskończona
Ośmielę się nazwać to pierwszym prawem McDonalda. Powtórzę: ilość sytuacji, w których kod może pójść w rozsypkę, jest teoretycznie nieskończona.
Nigdy nie przestaje mnie zadziwiać, jak wiele jest nowych i interesujących sposobów, w jaki mój własny kod może pójść w rozsypkę. Jest to jeszcze jeden powód, dla którego warto założyć, że problem leży w Tobie (Zasada # 2) – nawet jeśli przerobiłeś wszystkie możliwe wyjątkowe sytuacje lub przypadki niepowodzenia, wciąż znajdzie się jeszcze jeden problem. Gdy doświadczysz nieprzewidywalności kodu innych ludzi, czeka Cię całe życie niespodzianek.
Jeśli nie wpatrujesz się w ekran komputera, krzycząc „co tu się do jasnej ch.. dzieje!” lub inne takie minimum raz w roku, tzn. że robisz coś źle.
# 4: Złożoność jest twoim wrogiem
Prawdziwy kod jest złożony. Dlatego debugowanie to prawdziwy ból w kościach! Kiedy natrafisz na szczególnie trudny problem, pomocnym jest stworzenie minimalnego, kompletnego, weryfikowalnego przykładu (lub MCVE w języku StackOverflow).
Replikuj problem w stosunkowo świeżym środowisku z jak najmniejszą ilością kodu i jak najmniejszą liczbą zależności, jak to tylko możliwe. Jeśli to działa, dodawaj szczegóły aż do momentu, gdy eksploduje. To, co ostatnio zrobiłeś, jest prawie na pewno częścią problemu!
# 5: Jeśli coś jest nie tak, to pewnie jest błąd pamięci
Dotyczy to nie tylko języków takich jak C i C ++. Każdy błąd, który obejmuje całkowite wyrzucanie śmieci z dowolnego miejsca poza użytkownikiem, prawie na pewno jest związany z błędem pamięci.
Niezdefiniowane zachowanie i błędy pamięci istnieją w samym sercu stosu, w którym znajduje się nowoczesne oprogramowanie. Przeszukuj listę wyjątków w swoim ulubionym języku, a prawie na pewno znajdziesz coś związanego z pamięcią.
To, w jaki sposób wykrywasz i naprawiasz wspomniane błędy pamięci, zależy całkowicie od twojego języka i platformy.
# 6: Prawdopodobnie zapomniałeś średnika
Spędziłem dwa dni próbując naprawić nieskończoną pętlę w moim kodzie. Wyrywałem sobie włosy z głowy, będąc niemal przekonanym, że mój komputer jest opętany przez mroczną moc o złych intencjach, kiedy moja mama weszła do pokoju.
Przez chwilę wpatrywała się w ekran, a potem wskazała. „Czy nie potrzebujesz średnika w środku linii 56?”
Moja mama nie jest programistą. A jednak, zgadnij, czego zapomniałem w linii 56? Średnika!
Od tego czasu odkryłem, że wiele przerażających i tajemniczych błędów było z powodu brakujących znaków: średników, przecinków, ukośników, spacji. Istnieje pewna różnica między „poprawnym kodem” i „ważnym kodem”, a każdemu z nas nie uda się przeskoczyć nad przepaścią niczym Evel Kievel co najmniej raz w tygodniu.
Możliwe, że sam nie zobaczysz tych małych błędów. Wszyscy miewamy kod ślepy! Jeśli nie zauważysz go po kilku minutach, znajdź innego programistę, który to skontroluje – nie przejmuj się swoimi głupimi błędami. Zrobisz ich jeszcze wiele.
# 7: Nigdy nie lekceważ pomysłowości kompletnych głupców
Pełen cytat, na wypadek gdybyś się zastanawiał/a, to …
„Częstym błędem popełnianym przez ludzi przy próbie zaprojektowania czegoś całkowicie niezawodnego jest lekceważenie pomysłowości kompletnych głupców” – Douglas Adams
Prędzej czy później nieodparta siła, która jest w twoim kodzie, spotka się z nieuniknionym idiotyzmem użytkownika. (Nie śmiej się … są szanse, że znajdzie się użytkownik z niewystarczającą ilością kofeiny). W końcu ktoś poprosi twój kod, aby zrobił coś, co przeciwstawia się prawom fizyki, matematyki i zdrowego rozsądku.
Aby temu zapobiec, piszemy testy, które są absolutnie podstępne:
„Inżynier ds. Kontroli jakości wchodzi do baru, zamawia piwo, zamawia piwo 0, zamawia 999999999 piwa, zamawia jaszczurkę, zamawia, -1 piwo, zamawia, sfdeljknesv.” – Bill Sempf
Znajdź tak wiele genialnych sposobów na złamanie swojego kodu ile tylko możesz. Dowiedz się, co się dzieje, gdy wprowadzisz do niego śmieci. Złam zasady własnego API. Wyświetl interfejs, a następnie poproś kota o to, by usiadł na klawiaturze. Krótko mówiąc, rób okropne rzeczy w swoim kodzie.
(P.S. Nie żartuję, mówiąc o kocie, jeden z moich znajomych od kodowania ma kota, który dosłownie przeszedł test praktyczny na licencję radiową HAM z 85% podczas siedzenia na kolanach mojego śpiącego przyjaciela).
# 8: Oldskulowy papier jest twoim najlepszym przyjacielem
Współczesny programista ma do dyspozycji cały arsenał narzędzi do debugowania: debuggery, analizy statyczne, sprawdzanie pamięci, profilery kodu, frameworki testowe i lista jest długa! Ale nie przeocz najstarszego i najbardziej niezawodnego narzędzia do debugowania na świecie – kartki papieru, ołówka i własnych gałek ocznych.
Desk checking, jak się to nazywa, jest bezcennym narzędziem. Podczas, gdy przez wiele miesięcy możesz gonić swój ogon przy użyciu wszystkich złożonych narzędzi, nic nie pobije czytania samego kodu, zapisywania wartości każdej zmiennej podczas jej zmiany, wykonywania matematyki, oceny każdego logicznego zdania. Nie tylko masz świetną praktykę w myśleniu jak komputer, ale będziesz zaskoczony, jak szybko zerujesz problem.
Desk checking jest moją osobistą pierwszą linią obrony, używając go przed lub w parze z moim debuggerem. W ten sposób zaoszczędziłem wiele godzin paniki i bólu serca.
# 9: Błąd, który śledzisz, może być 'Jabberwockiem’
Programowanie jest dziwne. Z przyczyn, których w pełni nie rozumiemy, oprogramowanie niekoniecznie przestrzega praw matematyki lub fizyki. Czasami wydaje się, że ma własny umysł.
Weź pod uwagę następujące, wszystkie możliwości:
heisenbug (n): Błąd, który znika lub zmienia zachowanie, gdy próbuje się go zbadać lub odizolować.
mandelbug (n): Błąd, którego podstawowe przyczyny są tak złożone i niejasne, że jego zachowanie wydaje się chaotyczne, a nawet niedeterministyczne.
schroedinbug (n): Błąd w projekcie lub implementacji programu, który nie przejawia się, dopóki ktoś nie przeczyta źródła lub nie zauważy, że program nigdy nie powinien działać, w którym to momencie program natychmiast przestaje działać dla wszystkich, aż do naprawienia.
Choć mogą brzmieć mitycznie, są bardzo prawdziwe. W rzeczywistości obserwowałem i potwierdzałem wszystkie te działania przynajmniej raz.
Krótko mówiąc, debugowanie przez całe życie ma na celu stworzenie kilku dzikich historii. Podczas gdy większość błędów to błędy Bohra – czyli takie, które przejawiają się w dobrze zdefiniowanym zestawie warunków – a większość z nich to twoja wina [Reguła #2], bądź przygotowany na dziwaczność. Nigdy nie zakładaj, że zrozumiesz komputer.
Prowadzi mnie to do ważnego wniosku: twój komputer potraktuje wszystkie oszacowania czasu i trudności jako osobiste wyzwanie. Jeśli powiesz „wdrażanie X będzie łatwe” lub „powinno to zabrać mi tylko weekend, aby zrobić Y”, praktycznie zagwarantowałeś, że twój kod będzie pełen dziwactwa.
Na przykład kiedyś oszacowałem, że projekt potrwa tydzień. Sprzeciwiłem się wysiłkom czterech programistów, którzy musieli ukończyć projekt w ciągu trzech lat. (W zeszłym miesiącu osiągnął on pełną funkcjonalność).
Witamy w programowaniu.
# 10: Wyłącz i uruchom ponownie
Może to zabrzmieć głupio, że to sugeruję, ale działa to częściej niż można by się spodziewać, nawet z błędami w oprogramowaniu! Kiedy pracuję przy jakimś błędzie od dłuższego czasu i potwierdziłem, że problem nie leży po mojej stronie, ponownie uruchamiam komputer. Było kilka sytuacji, w których rozwiązało to problem całkowicie. I nigdy już się nie powtórzył.
Jednak… i to jest szalenie ważne… najpierw musisz wykluczyć samego siebie jako problem. Zjawisko to zostało poruszone w jednym z legendarnych MIT AI Koans:
Nowicjusz próbował naprawić zepsutą maszynę Lisp, wyłączając i włączając zasilanie.
Knight, widząc, co robi student, mówił surowo: „Nie możesz naprawić maszyny, po prostu zmieniając jej moc, nie rozumiejąc, co jest nie tak”.
Knight wyłączył i włączył maszynę.
Maszyna zadziałała.
# 11: Jeśli wszystko inne zawiedzie, porozmawiaj z kaczką;-)
UWAGA AUTORA: Pierwotnie planowałem artykuł na 10 reguł, ale straciłem rachubę. Oczywiście artykuł o debugowaniu będzie miał błąd.
Rubber ducking jest popularną praktyką wśród programistów i nie bez powodu. Często tylko głośne mówienie pomaga w innym przetwarzaniu problemu, prowadząc do rozwiązania. W tym celu wielu programistów trzyma gumową kaczkę na biurku.
Pamiętaj, że nie musi to być gumowa kaczka. W moim przypadku jest to postać winylowego Funko Doctor Whooves (z My Little Pony: Friendship is Magic). Cokolwiek poprowadzi twoją łódź… lub kaczkę.
Czytaj też: Potrzebny nam QA? czyli kto konkretnie?
Większość swojej kariery kodowania spędzisz na… debugowaniu i nie wiadomo, jakie dziwaczne rzeczy odkryjesz. Będziesz zgłębiał ludzką głupotę (szczególnie swoją własną) czy doświadczysz, jak denerwuje moc surowej, stosowanej matematyki. Zakładając, że przeżyjesz, będziesz miał mnóstwo historii do powiedzenia swoim dzieciom.
Zostawię cię wraz z nieśmiertelnymi, aczkolwiek błędnie zacytowanymi, słowami The Legend of Zelda:
Niebezpiecznie jest iść samemu……….. tak więc, powodzenia!:)
Autor: Jason C. McDonald
Oryginalna wersja artykułu: https://dev.to/codemouse92/the-rules-of-debugging-2hf5
Jason C. McDonald jest „nowym członkiem starej straży”: hakerem z doświadczeniem w wielu językach, pasją do wydajności algorytmicznej oraz ekspertem w programowaniu obiektowym, zarządzaniu pamięcią i nieokreślonym zachowaniem. Jest wiodącym programistą w MousePaw Media, posiada doświadczenie w zarządzaniu projektami i DevOps; jest głównym autorem standardów Commenting Showing Intent i Quantified Task Management. Oprócz kodowania, jest autorem publikowanych zarówno fikcji, jak i nie-fikcji, mówcą publicznym oraz autorem tekstów piosenek. Więcej informacji na temat Jasona można znaleźć na stronie https://www.indeliblebluepen.com