Jaka jest korzyść z unikania korzystania z debuggera?

W trakcie mojej kariery zauważyłem, że niektórzy programiści nie używają narzędzi do debugowania, ale sprawdzają na miejscu błędny kod, aby dowiedzieć się, na czym polega problem.

Podczas gdy wiele razy szybkie znajdowanie błędów w kodzie bez debuggera jest dobrą umiejętnością, wydaje się, że mniej produktywne jest spędzanie dużo czasu na poszukiwaniu problemów, gdy debugger z łatwością znalazłby małe błędy, takie jak literówki.

Czy możliwe jest zarządzanie kompleksem bez debuggera? Czy to jest wskazane? Jakie korzyści można uzyskać, stosując „ debugowanie psychiczne ”?

To, co wygląda na zgadywanie z zewnątrz, często okazuje się tym, co nazywam „debugowaniem w twoim umyśle”. W pewnym sensie jest to podobne do zdolności arcymistrzów do gry w szachy bez patrzenia na szachownicę.

Jest to zdecydowanie najbardziej efektywna technika debugowania, jaką znam, ponieważ w ogóle nie wymaga debugera. Twój mózg eksploruje wiele ścieżek kodu jednocześnie, zapewniając lepszy zwrot niż można uzyskać przy pomocy debuggera.

Nie byłem świadomy tej techniki, zanim krótko wkroczyłem w świat konkurencyjnego programowania , gdzie użycie debuggera oznaczało utratę cennych sekund. Po około roku rywalizacji zacząłem używać tej techniki prawie wyłącznie jako początkowej linii obrony, a następnie rejestrować debugowanie, używając rzeczywistego debugera siedzącego na odległym trzecim miejscu. Jednym z użytecznych efektów ubocznych tej praktyki było to, że zacząłem dodawać nowe błędy w wolniejszym tempie, ponieważ „debugowanie w moim umyśle” nie kończyło się, gdy pisałem nowy kod.

Oczywiście ta metoda ma swoje ograniczenia, głównie z powodu ograniczeń umysłu w wizualizacji wielu ścieżek w kodzie. Nauczyłem się szanować te ograniczenia mojego umysłu, zwracając się do debuggera do naprawy błędów w bardziej zaawansowanych algorytmach.

Im bardziej znam bazę kodu, tym mniej potrzebuję debuggera (ale nadal sprawdzałbym zgłoszony błąd, jest to ważna wskazówka w każdym rozumowaniu).

Jest to doskonałe narzędzie do zrozumienia niektórych dynamicznych zachowań o małej lub średniej złożoności, ale często dowiaduję się, że skupiają się one na szczegółach zamiast na większym obrazie. I po pewnym czasie właśnie tam są problemy: w interakcjach w szerszym zakresie, których dynamiczne zachowanie jest łatwiejsze do zrozumienia za pomocą innych narzędzi (na przykład rejestrowanie danych wejściowych i wyjściowych na granicach modułu).

Nie są złymi programistami, ale prawdopodobnie są strasznie nieefektywnymi narzędziami do rozwiązywania problemów.

Zwykle podążam za radą z Debugowania: 9 niezastąpionych zasad znajdowania nawet najbardziej nieuchwytnych problemów z oprogramowaniem i sprzętem (David Agans), a ten jest objęty „Przestań myśleć i wyglądać”

Każda praca wymaga korzystania z odpowiednich narzędzi we właściwy sposób. Jeśli masz debugger, użyj go, aby zobaczyć, co się właściwie dzieje. Większość błędów jest spowodowana założeniami.

Pracowałem z programistami, którzy odmawiają używania debuggerów, ponieważ wiedzieli lepiej. Klasyczną odpowiedzią, jaką otrzymałem raz było: „katastrofa nie jest spowodowana przeze mnie, spędziłem cały dzień sprawdzając kod [tam, gdzie się zawiesił] i nie ma nic złego”. (Co z tą wartością zerową, którą odczytano z bazy danych?) Szef wydawał się uważać, że to świetna odpowiedź, ale klient tego nie zrobił.

Opuściłem ten zespół tak szybko, jak tylko mogłem. Ich celem było wtopienie pracy i zrobienie prostego 10-minutowego problemu w całodniowy problem.

Najlepszym przewodnikiem po praktyce debugowania jest książka Steve McConnel Code Complete . Rozdział 23 zawiera szczegółowe informacje na temat debugowania, a ja przedstawię kilka punktów.

1. Zrozumienie problemu jest ważne, a korzystanie z debugera nie zastępuje go.
2. Zgadywanie jest złym podejściem do debugowania. Jeśli twoi koledzy naprawdę zgadują, zamiast myśleć o problemie, robią złą robotę. Zgadywanie oznacza umieszczanie losowych instrukcji drukowania w kodzie i liczenie na znalezienie czegoś przydatnego.
3. Jeśli twoi koledzy naprawdę nie wiedzą, jak korzystać z debuggera (zamiast nie używać go), to tak, są niekompetentni, tak jak ktoś, kto nie zna składni języka, którego powinni używać.

Ciężko powiedzieć. Debugowanie przez zgadywanie może działać, jeśli masz już pojęcie o tym, czym jest błąd (niepoprawna wartość przekazana do funkcji biblioteki, prawdopodobnie niepoprawny SQL itp.). Przyznaję, że robię to czasami, gdy sam błąd wydaje się mały lub oczywisty, na przykład „zbyt mały bufor znaków” - ślad stosu pokazuje mi linię, którą zawiódł i nie potrzebuję debugera, aby go rozwiązać.

Robienie tego przez cały czas może przynosić efekt przeciwny do zamierzonego, a jeśli kilka pierwszych „domysłów” się nie powiedzie, zgadywanie jest prawdopodobnie niewłaściwą strategią rozwiązywania problemów i należy wezwać prawdziwego debugera. Zwykle powiedziałbym, że nie ma nic złego w używaniu debugera .

To powiedziawszy, pracowałem z narzędziami i środowiskami, w których debugger był tak trudny do prawidłowego działania, lub tak minimalny i bezużyteczny, że zgadywanie było niestety często lepszym podejściem. Pracowałem z niektórymi zastrzeżonymi narzędziami, które nawet nie miały odpowiednich debuggerów. Przypuszczam, że możliwe jest, że jeśli ktoś zbyt długo pracował w takich środowiskach, ostatecznie straciłby zaufanie do debuggerów i polegał wyłącznie na zgadywaniu.

Dziwi mnie, że w dyskusji na ten temat nie wspomniano o „testowaniu jednostkowym”.

Ponieważ zajmuję się programowaniem testowym, nie spędzam dużo czasu w debuggerze. 10 lat temu posłusznie przechodziłem przez debugger:

1. Po napisaniu fragmentu kodu, aby upewnić się, że zadziałał i
2. Kiedy otrzymałem raport o błędzie, próbuję zdiagnozować problem

Po 10 latach rozwoju opartego na testach odkryłem, że jestem o wiele bardziej produktywny jako programista, jeśli:

1. Testy jednostkowe piszę przed napisaniem kodu, aby upewnić się, że napisałem go poprawnie
2. Testy jednostkowe piszę natychmiast po otrzymaniu raportu o błędzie, aby spróbować powielić i zgłębić problem.

Umożliwienie komputerowi przejścia przez kod i sprawdzania poprawności wyniku jest tysiące razy szybsze niż myślę lub krok po kroku, aby mentalnie zweryfikować wyniki i nie popełnia błędów.

Nadal muszę od czasu do czasu wchodzić w debugger i nadal jestem zaangażowany w mentalną analizę kodu ... ale tylko rzadko i głównie w przypadku bardzo trudnego kodu.

Osobiście staram się minimalizować użycie debuggera poprzez:

• używając statycznych kontrolerów i podobnych opcji kompilatora, które sugerują możliwe źródła błędów po prostu analizując kod
• pisanie kodu z jak najmniejszą ilością efektów ubocznych, w możliwie najbardziej funkcjonalnym stylu, eliminując w miarę możliwości stan zmienny
• pisanie testów jednostkowych przy minimalnej rozsądnej szczegółowości
• nie połykać wyjątków

Oczywiście wszyscy popełniają błędy, więc nawet podczas komponowania programów w ten sposób, jeśli test się nie powiedzie, używam debugera do sprawdzenia wartości wyrażenia pośredniego. Ale przestrzegając powyższych zasad, wada jest łatwiejsza do zlokalizowania, a debugowanie nie oznacza bolesnego, nieokreślonego procesu.

W miarę możliwości używaj debugera. Debuger albo po prostu napotka problem (och, nie sprawdziliśmy tej wartości), albo zapewni dużo kontekstu, który jest użyteczny podczas analizy odpowiedniego kodu (wow, stos jest całkowicie pomieszany, ja może to być problem przepełnienia bufora).

Debugowanie to bardzo przydatne narzędzie do sprawdzania stanu obiektów i zmiennych w kodzie w czasie wykonywania.

Jak wcześniej wspomniano w odpowiedziach powyżej, debugowanie jest niezwykle pomocne, ale w niektórych przypadkach jest ograniczone.

Z mojego doświadczenia wynika, że ​​korzystanie z debuggera jest bardzo przydatne, ponieważ pomaga ujawnić fałszywe założenia dotyczące stanu mojego kodu. Niektóre osoby nie są tak bystre w czytaniu kodu w celu znalezienia błędu, więc debugowanie może pomóc w ujawnieniu fałszywych założeń, które ty lub inny programista poczyniłeś na temat stanu kodu.

Być może spodziewasz się, że parametr nigdy nie będzie zerowy po przekazaniu do metody, więc nigdy nie sprawdzasz tego przypadku i nie kontynuujesz metody, jakby ten parametr nigdy nie był zerowy. Rzeczywistość jest taka, że parametr będzie w końcu jest zerowa w pewnym momencie nawet jeśli ustawiony jako warunek wstępny do metody, że parametr nie powinien być NULL. To się zawsze stanie.

W przeciwieństwie do użyteczności debuggerów w wyżej wymienionych przykładach, trudno jest mi je stosować, gdy w grę wchodzi wielowątkowość (tj. Współbieżność, przetwarzanie asynchroniczne). Może to pomóc, ale łatwo jest stracić orientację w wielowątkowej mgle, gdy punkty przerwania debuggera są trafiane w jednym wątku w punkcie A i całkowicie oddzielnym wątku w punkcie B. Deweloper jest zmuszony przesunąć nowy punkt przerwania ” proces myślowy „na szczycie” stosu jego mózgu i zorientuj się w kodzie w punkcie nowego punktu przerwania. Po tym, jak trafność punktu przerwania B maleje, programista przełącza się z powrotem do pierwszego punktu przerwania i musi przypomnieć sobie to, czego szukał przed uruchomieniem punktu przerwania B. Wiem, że może to być mylące wyjaśnienie,

Również nieprzewidywalność współbieżnego kodu może dodatkowo rozpraszać programistę podczas debugowania współbieżnego kodu.

Podsumowując, moim szczerym zdaniem:

• Debugowanie, gdy używana jest współbieżność = zwiększona tendencja do utraty koncentracji na „wzorcu myślenia debugowania”

i

• kiedykolwiek indziej = zwiększona wydajność debugowania b / c twoja uwaga nie jest przerywana przez nieoczekiwane punkty przerwania (nieoczekiwane z powodu warunków wyścigu).

Myślę, że są trochę zbyt hardkorowi. Osobiście, gdy napotykam błąd, ponownie sprawdzam kod, próbuję prześledzić go w logice programu, ponieważ czasami pomaga mi to odkryć inne problemy lub skutki uboczne łatwiej niż po prostu użycie debbugera i naprawienie błędu tam, gdzie się objawia. .

Nawet kiedy myślę, że go przybiłem, zwykle debuguję go, aby upewnić się, że mam rację. Kiedy problem jest nieco bardziej złożony, uważam, że debugowanie jest absolutnie niezbędne.

Także ... tylko moja opinia, ale nie ma usprawiedliwienia dla niezbyt korzystnego wykorzystania narzędzi, które nowoczesne IDE może przynieść na stół. Jeśli pomoże ci to w szybszym i bardziej niezawodnym zakończeniu pracy, powinieneś z niej skorzystać.

Nienawidzę uogólniać, ale wielu programistów, których spotkałem, uważa, że ​​istnieje tylko jeden sposób rozwiązania problemu (ich sposób). Łatwo jest założyć, że wymyślono każdy możliwy test. Inna perspektywa może być bardzo cenna.

Programowanie metodą prób i błędów może wymyślić kilka świetnych nowych podejść i uchwycić rzeczy, które inni przeoczyli.

Minusem, zwykle trwa znacznie dłużej.

Eee, to zależy od osoby. Osobiście sam nie używam debugerów. Kiedy programuję mikrosterowniki, w zasadzie używam diod LED lub zapisuję dane w pamięciach EEPROM w celu „debugowania” kodu. Nie używam JTAG.

Kiedy programuję oprogramowanie na komputery PC lub serwery, zwykle używam rejestrowania i dużej ilości danych wyjściowych z konsoli. W przypadku języków w stylu C korzystam z dyrektyw preprocesora, aw Javie używałem poziomów dziennika.

Skoro nie używam debugerów, czy powiedziałbyś, że robię coś źle? Są to zadania redaktorów, aby pokazać mi, gdzie mam błędy składniowe, a gdy pojawia się błąd logiczny, muszę tylko przeprowadzić testy.

Istnieje różnica między tym, że nie trzeba używać debugera, ani nie wiedzieć, jak (lub odmówić) korzystania z debuggera. Debuger jest tylko jednym z wielu narzędzi do śledzenia i naprawiania błędów. Pracowałem z programistami, którzy potrafią rozwiązać zagadkę w głowie i innymi, którzy myślą, że potrafią.

Najlepszą kombinacją jest napisanie kodu, aby można go było łatwo testować za pomocą testów jednostkowych i rejestrować błędy. Masz nadzieję, że nie musisz przeglądać dzienników ani używać debugera. To trochę jak wykupienie ubezpieczenia. Mamy nadzieję, że nigdy nie musisz go używać, ale gdy napotkasz błąd, którego nie można rozwiązać przez ponowne sprawdzenie kodu, jest już za późno, aby dodać poprawną obsługę błędów / logowanie, testy jednostkowe lub nauczyć się korzystać z debuggera.

Różne narzędzia / platformy sprzyjają różnym technikom debugowania (debugger, logowanie, testy jednostkowe itp.) O ile programiści znają kilka technik ich platformy / narzędzia, oprócz jedynie ponownego sprawdzenia kodu, mogą być wykwalifikowany programista, ale jeśli mają tylko jedną sztuczkę, jeśli chodzi o debugowanie, w końcu napotkają błąd, którego nie mogą znaleźć ani naprawić.

Wiele odpowiedzi, ale nie wspominając o Heisenbug ?!?!

Błędy Heisenbugs występują, ponieważ typowe próby debugowania programu, takie jak wstawianie instrukcji wyjściowych lub uruchamianie go w debuggerze, zwykle modyfikują kod, zmieniają adresy pamięci zmiennych i czas jego wykonywania.

Używam debuggera, tylko w najgorszym przypadku (w przypadku trudnych do znalezienia błędów). Ponadto, zgodnie z najlepszymi praktykami, o których mówi wielu uznanych programistów / testerów, dobrze jest dokładnie przetestować kod. W ten sposób możesz poradzić sobie z większością problemów i dlatego nie będzie potrzeby używania debuggera.

Czytałem ostatnio argument przeciwko debugowaniu debugera (czy był to StackOverflow?). Powinieneś mieć przypadki testowe względem swojego kodu. Jeśli testy przejdą pomyślnie, debugowanie prawdopodobnie nie spowoduje wykonania błędu (założenie: będziesz debugować z danymi podobnymi do danych testowych).

Z drugiej strony rejestrowanie jest obowiązkowe. Jeśli zdasz testy i wdrożysz do produkcji, może się okazać, że masz błąd. Dowody błędu pochodzą z czegoś, co wydarzyło się w przeszłości. tzn. ktoś mówi: „Jak to się tam dostało?” Jeśli nie masz dobrych dzienników, nigdy nie znajdziesz przyczyny. Nawet debugger może w tym momencie się nie przydać, ponieważ nie wiesz, jak wyglądały dane, co spowodowało błąd. Musisz mieć możliwość debugowania aplikacji z dzienników.

Niestety, parafrazuję całkiem sporo i być może robię oryginalny argument nieprzyzwoitością. W szczególności pozycja „Istnieją ważne pomocniki do debugowania, aby spędzić czas na programowaniu”, może być prostopadła do znaczenia debuggerów. Ale część dotycząca trudności w ustawianiu stanu systemu w konfiguracji, która sprawia, że ​​debugowanie jest przydatne do znajdowania błędów, uderzyła mnie jako coś do przemyślenia.

Przy dobrych testach jednostkowych i wyjątkach zapewniających ślad wsteczny rzadko trzeba używać debugera.

Ostatni raz użyłem debugowania, kiedy otrzymałem plik podstawowy w jakiejś starszej aplikacji.

Czy jestem „sługą debbugera”, czy też ci faceci są „zbyt hardkorowi”?

Ani. Są po prostu ludźmi, którzy lubią utrudniać sobie życie.

Debugowanie to tylko narzędzie, z którego dobry programista powinien korzystać biegle.

Z pewnością czasami możesz na pamięć wiedzieć, gdzie może być błąd, jeśli znasz bazę kodu. Ale możesz również stracić cały dzień lub tydzień, aby znaleźć nieznośny błąd, po prostu zaglądając do kodu.

W dynamicznie wpisywanych językach bez debugowania (nawet jeśli jest to po prostu zrzut wartości do konsoli) zgadywanie czasami staje się niemożliwe.

Aby odpowiedzieć na twoje pytanie - być może są świetnymi programistami, ale ich umiejętności rozwiązywania problemów i ich biegłość w polowaniu na błędy są złe.

Zależy od zakresu problemu. Jeśli program jest mały, a sprawy są dobrze podzielone, prawdopodobnie możesz to rozwiązać, patrząc. Jeśli program ma 4,5 miliona linii kodu opracowanych przez zespół ponad 100 osób w ciągu kilku lat, pewne błędy będą niemożliwe do wykrycia.

Ten, o którym mowa we wspomnianym programie (w C), był nadpisywaniem pamięci. Debuger z punktem przerwania pamięci zidentyfikował obrażającą linię kodu, gdy tylko pojawił się błąd. Ale w tym przypadku nie ma możliwości, aby ktoś mógł odczytać i zachować wszystkie 4,5 miliona wierszy kodu w celu zidentyfikowania jednego miejsca, które ktoś napisał poza swoją tablicą (a ponadto musiałby znać układ środowiska wykonawczego pamięci dla stanu ogromnego programu około 10 minut na długi ciąg wejść, aby dostać się do tego punktu).

Chodzi o to: w małych programach lub rzeczach, które są wysoce modułowe, możesz uciec bez debuggera. Jeśli program jest naprawdę duży i złożony, debugger może zaoszczędzić dużo czasu. Jak powiedzieli inni, jest to narzędzie i ma sytuacje, w których przewyższa jakąkolwiek inną metodę, i inne, w których nie jest najlepszym wyborem.

Jeśli błąd występuje na komputerze klienta lub na komputerze, którego środowisko znacznie różni się od twojego, wówczas skonfigurowanie debugera / zdalnego debugera jest uciążliwe. Tak więc, w zimny dzień, w którym pojawia się błąd z pola, odpowiedź „ale… nie mam debuggera” nie pomaga. Dlatego musisz opracować zestaw umiejętności rozwiązywania problemów i znajdowania błędu tylko poprzez zrozumienie kodu i plików dziennika.

Co za bzdury: „Prawdziwi programiści nie potrzebują debuggerów”. Równie dobrze mogę powiedzieć, że prawdziwy programista nie potrzebuje IDE, daj mi tylko notes i tępy ołówek. Debuger to narzędzie, jak każde inne, które wspomaga produktywność.

Weź również pod uwagę, że nie wszyscy, którzy mają zadanie debugowania kodu, znają ten kod. Wielu wykonawców przychodzi do środowiska, w którym mają jedynie ogólny ideał tego, co się dzieje. Mogą nawet otrzymać szczegółowy opis środowiska - lub 20-letnią mapę schematu i przewodnik po tajemnych konwencjach nazewnictwa (spróbuj zrozumieć różnicę między tabelą X1234 a tabelą X4312 z polami F1, F2 i F3 [tak, śmieci takie jak ten istnieje], gdy jesteś nowy), ale wiele razy ten opis jest błędny; w przeciwnym razie dlaczego występuje błąd „tajemnicy”.

Jako ktoś nowy w środowisku, możesz spędzić godziny lub dni na mapowaniu i poznawaniu dużej bazy danych dla obszaru problemu, który możesz naprawić, a potem nigdy nie musisz na nią patrzeć. To ogromna strata czasu i pieniędzy. Jeśli masz dostęp do debugera, możesz sprawdzić, co się dzieje, poprawić go i zniknąć w ciągu kilku minut. Całe to hooey „nie potrzebujesz debuggerów” to po prostu elitarne obrzęki.