Dlaczego debugowanie jest lepsze w środowisku IDE? [Zamknięte]

Jestem programistą od ponad dwudziestu lat, programując w językach C, Perl, SQL, Java, PHP, JavaScript, a ostatnio w Pythonie. Nigdy nie miałem problemu, którego nie mogłem debugować przy użyciu starannie przemyślanych i dobrze umiejscowionych printinstrukcji debugowania .

Szanuję, że wiele osób mówi, że moje techniki są prymitywne, a użycie prawdziwego debuggera w IDE jest znacznie lepsze. Jednak z moich obserwacji użytkownicy IDE nie wydają się debugować szybciej i skuteczniej niż ja, używając moich kamiennych noży i skór niedźwiedzi. Jestem szczerze otwarty na naukę odpowiednich narzędzi, po prostu nigdy nie pokazano mi nieodpartej korzyści z używania wizualnych debuggerów.

Co więcej, nigdy nie czytałem samouczka ani książki, która pokazywałaby, jak skutecznie debugować za pomocą IDE, poza podstawami ustawiania punktów przerwania i wyświetlania zawartości zmiennych.

czego mi brakuje? Co sprawia, że ​​narzędzia do debugowania IDE są o wiele bardziej efektywne niż przemyślane użycie printinstrukcji diagnostycznych ?

Czy możesz zasugerować zasoby (samouczki, książki, screencasty), które pokazują lepsze techniki debugowania IDE?

Słodkie odpowiedzi! Bardzo dziękuję wszystkim za poświęcony czas. Bardzo pouczające. Głosowałem za wielu, ale na żadnego nie.

Kilka ważnych punktów:

• Debugery mogą pomóc mi w inspekcji ad hoc lub zmianie zmiennych, kodu lub dowolnego innego aspektu środowiska wykonawczego, podczas gdy debugowanie ręczne wymaga zatrzymania, edycji i ponownego uruchomienia aplikacji (prawdopodobnie wymagającej ponownej kompilacji).
• Debugery mogą podłączać się do działającego procesu lub używać zrzutu awaryjnego, podczas gdy przy debugowaniu ręcznym konieczne są „kroki prowadzące do odtworzenia” defektu.
• Debugery mogą łatwo i czytelniej wyświetlać złożone struktury danych, środowiska wielowątkowe lub pełne stosy środowiska uruchomieniowego.
• Debugery oferują wiele sposobów skrócenia czasu i powtarzalności wykonywania prawie wszystkich zadań związanych z debugowaniem.
• Debugery wizualne i debugery konsoli są przydatne i mają wiele wspólnych funkcji.
• Wizualny debugger zintegrowany z IDE zapewnia również wygodny dostęp do inteligentnej edycji i wszystkich innych funkcji IDE w jednym zintegrowanym środowisku programistycznym (stąd nazwa).

Kilka przykładów niektórych możliwości, które debugger IDE da ci nad komunikatami śledzenia w kodzie:

• Wyświetl stos wywołań w dowolnym momencie, dając kontekst dla bieżącej ramki stosu.
• Wejdź do bibliotek , których nie możesz ponownie skompilować w celu dodania śladów (zakładając, że masz dostęp do symboli debugowania)
• Zmieniaj wartości zmiennych podczas działania programu
• Edytuj i kontynuuj - możliwość zmiany kodu podczas jego działania i natychmiastowego zobaczenia wyników zmiany
• Móc obserwować zmienne, widzieć, kiedy się zmieniają
• Umiejętność pomijania lub powtarzania sekcji kodu , aby zobaczyć, jak będzie działał kod. Pozwala to przetestować teoretyczne zmiany przed ich wprowadzeniem.
• Sprawdź zawartość pamięci w czasie rzeczywistym
• Ostrzegają Cię, gdy są zgłaszane pewne wyjątki , nawet jeśli są one obsługiwane przez aplikację.
• Warunkowe punkty przerwania ; zatrzymywanie aplikacji tylko w wyjątkowych okolicznościach, aby umożliwić analizę stosu i zmiennych.
• Wyświetl kontekst wątku w aplikacjach wielowątkowych, co może być trudne do osiągnięcia przy śledzeniu (ponieważ ślady z różnych wątków będą przeplatane w danych wyjściowych).

Podsumowując, instrukcje drukowania są (ogólnie) statyczne i będziesz musiał ponownie skompilować, aby uzyskać dodatkowe informacje, jeśli oryginalne instrukcje nie były wystarczająco szczegółowe. IDE usuwa tę statyczną barierę, udostępniając dynamiczny zestaw narzędzi na wyciągnięcie ręki.

Kiedy po raz pierwszy zacząłem programować, nie mogłem zrozumieć, na czym polega wielka sprawa z debuggerami i pomyślałem, że mogę osiągnąć wszystko dzięki śledzeniu (oczywiście, to było na unixie, a debugger to GDB). Ale kiedy już nauczysz się, jak prawidłowo korzystać z debugera graficznego, nie będziesz chciał wracać do instrukcji drukowania.

• Debuger IDE umożliwia zmianę wartości zmiennych w czasie wykonywania.

• Debugger IDE pozwala zobaczyć wartości zmiennych, o których nie wiedziałeś, że chcesz zobaczyć, kiedy rozpoczęło się wykonywanie.

• Debuger IDE pozwala zobaczyć stos wywołań i zbadać stan funkcji, która przekazała dziwne wartości. (myślę, że ta funkcja jest wywoływana z setek miejsc, nie wiesz, skąd pochodzą te dziwne wartości)

• Debuger IDE umożliwia warunkowe przerwanie wykonywania w dowolnym punkcie kodu na podstawie warunku, a nie numeru wiersza.

• Debugger IDE pozwoli ci zbadać stan programu w przypadku nieobsługiwanego wyjątku, zamiast po prostu go wyrzucić.

Oto jedna rzecz, której na pewno nie możesz debugować za pomocą instrukcji „print”, czyli gdy klient przynosi zrzut pamięci i mówi „Twój program się zawiesił, czy możesz mi powiedzieć dlaczego?”

• Drukowanie instrukcji w całym kodzie zmniejsza czytelność.
• Dodawanie i usuwanie ich wyłącznie w celach debugowania jest czasochłonne
• Debugery śledzą stos wywołań, ułatwiając sprawdzenie, gdzie się znajdujesz
• Zmienne można modyfikować w locie
• Polecenia adhoc mogą być wykonywane podczas przerwy w wykonywaniu, aby ułatwić diagnozowanie
• Może być używany W POŁĄCZENIU z instrukcjami print: Debug.Write ("...")

Myślę, że debugowanie przy użyciu instrukcji drukowania to zagubiona sztuka i bardzo ważna dla każdego programisty. Kiedy już wiesz, jak to zrobić, pewne klasy błędów stają się znacznie łatwiejsze do debugowania w ten sposób niż za pomocą IDE. Programiści, którzy znają tę technikę, mają również bardzo dobre wyczucie, jakie przydatne informacje można umieścić w komunikacie dziennika (nie wspominając o tym, że faktycznie przeczytasz dziennik) również w celach niezwiązanych z debugowaniem.

To powiedziawszy, naprawdę powinieneś wiedzieć, jak korzystać z debugera krokowego, ponieważ w przypadku innej klasy błędów jest to DUŻO łatwiejsze. Zostawię to innym znakomitym odpowiedziom już opublikowanym, aby wyjaśnić, dlaczego :)

Z czubka mojej głowy:

1. Debugowanie złożonych obiektów - debugery pozwalają wejść w głąb wnętrza obiektu. Jeśli twój obiekt ma, powiedzmy, tablicę złożoną z obiektów złożonych, instrukcje print doprowadzą cię tylko do tego momentu.
2. Możliwość ominięcia kodu - Debuggery pozwolą Ci również pominąć poprzedni kod, którego nie chcesz wykonywać. To prawda, możesz to również zrobić ręcznie, ale musisz wstrzyknąć znacznie więcej kodu.

Jako alternatywę dla debugowania w IDE możesz wypróbować świetną konsolę PHP dla przeglądarki Google Chrome z biblioteką php, która umożliwia:

• Zobacz błędy i wyjątki w konsoli JavaScript Chrome i w wyskakujących okienkach powiadomień.
• Zrzuć dowolną zmienną typu.
• Zdalne wykonywanie kodu PHP.
• Chroń dostęp hasłem.
• Grupuj dzienniki konsoli według żądania.
• Przejdź do pliku błędów: linia w edytorze tekstu.
• Skopiuj dane błędów / debugowania do schowka (dla testerów).

Nie rozwijam się od prawie 20 lat, ale uważam, że używając IDE / debuggera mogę:

• zobacz wszystkie rodzaje rzeczy, o których bym nie pomyślał, aby zawrzeć w instrukcji print
• przejdź przez kod, aby sprawdzić, czy pasuje do ścieżki, którą myślałem, że pójdzie
• ustaw zmienne na określone wartości, aby kod zajmował określone gałęzie

Jednym z powodów korzystania ze środowiska IDE może być fakt, że współczesne środowiska IDE obsługują więcej niż proste punkty przerwania. Na przykład program Visual Studio oferuje następujące zaawansowane funkcje debugowania:

• zdefiniować warunkowe punkty przerwania (przerwij tylko wtedy, gdy warunek zostanie spełniony, lub tylko w n-tym czasie wykonania instrukcji w punkcie przerwania)
• przerwa w nieobsługiwanym wyjątku lub za każdym razem, gdy ma zostać wyrzucona (określona) funkcja ecxeption
• zmień zmienną podczas debugowania
• powtarzanie fragmentu kodu przez ustawienie następnej linii do wykonania
• itp.

Ponadto, gdy używasz debugera, nie będziesz musiał usuwać wszystkich instrukcji print po zakończeniu debugowania.

Jestem zaskoczony, że nie widziałem w innej odpowiedzi, że dwie metody debugowania nie wykluczają się wzajemnie .

printfdebugowanie może działać całkiem dobrze, nawet jeśli używasz standardowego debuggera (opartego na IDE lub nie). W szczególności ze strukturą rejestrowania, dzięki czemu można pozostawić wszystkie lub większość w wydanym produkcie, aby pomóc w diagnozowaniu problemów klientów.

Jak zauważono we wszystkich innych odpowiedziach tutaj, kluczową zaletą standardowego debuggera jest to, że pozwala on łatwiej zbadać (i potencjalnie zmienić) szczegóły stanu programu. Nie musisz z góry wiedzieć, na co możesz chcieć spojrzeć - to wszystko jest dostępne na wyciągnięcie ręki (mniej więcej).

Z mojego doświadczenia wynika, że ​​proste wydruki mają jedną ogromną zaletę, o której nikt nie wspomina.

Problem z debugerem IDE polega na tym, że wszystko dzieje się w czasie rzeczywistym. Zatrzymujesz program w określonym momencie, a następnie przechodzisz przez kolejne kroki i nie można cofnąć się, jeśli nagle zechcesz zobaczyć, co wydarzyło się wcześniej. Jest to całkowicie sprzeczne z tym, jak działa nasz mózg. Mózg zbiera informacje i stopniowo formułuje sprzeciw. Może zaistnieć potrzeba kilkukrotnego powtórzenia wydarzeń, ale gdy przekroczysz pewien punkt, nie możesz wrócić.

W przeciwieństwie do tego, wybrana seria wydruków / protokołów daje „przestrzenną projekcję zdarzeń czasowych”. Daje ci pełną historię tego, co się stało, i możesz bardzo łatwo cofnąć się i po czwarte kilka razy, po prostu przewijając w górę iw dół. Ułatwia udzielanie odpowiedzi na pytania typu „czy wystąpiło A przed zdarzeniem B”. Może sprawić, że zobaczysz wzory, których nawet nie szukałeś.

Tak więc z mojego doświadczenia. IDE i debuggery to fantastyczne narzędzia do rozwiązywania prostych problemów, gdy coś w pojedynczym stosie wywołań poszło nie tak, i do badania aktualnego stanu maszyny w przypadku określonej awarii.

Jednak gdy zbliżamy się do trudniejszych problemów, w których występuje stopniowa zmiana stanu. Tam, gdzie na przykład jeden algorytm uszkodził strukturę danych, to z kolei spowodowało awarię innego algorytmu. Lub jeśli chcemy odpowiedzieć na pytania typu „jak często to się dzieje”, „rób rzeczy w kolejności i w sposób, w jaki je sobie wyobrażam”. itd. W takim razie „stara” technika logowania / wydruku ma wyraźną przewagę.

Najlepiej jest użyć dowolnej techniki, gdy jest najbardziej odpowiednia, na przykład użyć logowania / wydruków, aby uzyskać dostęp do niektórych błędów, i zatrzymać się w punkcie przerwania, w którym musimy bardziej szczegółowo zbadać bieżący stan.

Istnieją również podejścia hybrydowe. Na przykład, gdy wykonujesz console.log (obiekt), w dzienniku pojawi się widget struktury danych, który możesz rozwinąć i zbadać bardziej szczegółowo. Jest to wielokrotnie wyraźna przewaga nad „martwym” dziennikiem tekstowym.

Ponieważ debugowanie aplikacji wielowątkowych za pomocą instrukcji print doprowadzi Cię do bananów. Tak, nadal możesz to zrobić za pomocą instrukcji print, ale będziesz potrzebować ich wielu, a rozwikłanie sekwencyjnego drukowania instrukcji w celu emulacji wielowątkowego wykonania zajmie dużo czasu.

Ludzkie mózgi są niestety tylko jednowątkowe.

Ponieważ prosiłeś o wskazówki do książek ... Jeśli chodzi o debugowanie systemu Windows, John Robbins ma kilka wydań dobrej książki o debugowaniu systemu Windows:

Aplikacje do debugowania dla Microsoft .NET i Microsoft Windows

Zauważ, że najnowsza edycja ( Debugowanie aplikacji Microsoft .NET 2.0 ) to tylko .NET, więc możesz chcieć starszej wersji (jak w pierwszym linku), jeśli chcesz debugować kod natywny (obejmuje zarówno .NET, jak i natywne).

Osobiście uważam, że odpowiedź jest tak prosta, jak „Zintegrowany debugger / IDE szybko dostarcza bogactwo różnych informacji, bez konieczności wpisywania poleceń. Informacje są zazwyczaj widoczne przed Tobą, a Ty nie mówisz im, co należy pokażę ci.

Łatwość w których informacje mogą być pobierane co czyni je lepiej niż tylko debugowanie wiersza polecenia lub „printf” debugowania.

Zalety debuggera nad printf ( uwaga nie debugger IDE, ale dowolny debugger )

1. Może ustawiać punkty obserwacyjne. To jeden z moich ulubionych sposobów wyszukiwania uszkodzeń pamięci

2. Potrafi debugować plik binarny, którego nie można w tej chwili ponownie skompilować

3. Potrafi debugować plik binarny, którego rekompilacja zajmuje dużo czasu

4. Potrafi zmieniać zmienne w locie

5. Może wywoływać funkcje w locie

6. Nie ma problemu, w którym statystyki debugowania nie są opróżniane, a zatem problemu z synchronizacją nie można dokładnie zdebugować

7. Debugery pomagają przy zrzutach rdzenia, instrukcje drukowania nie '

Oto, czego używam najczęściej w oknach debugowania VS.NET:

• Stos wywołań, który jest również świetnym sposobem na znalezienie kodu innej osoby
• Miejscowi i zegarki.
• Bezpośrednie okno, które jest w zasadzie konsolą C #, a także pozwala mi zmieniać zawartość zmiennych, inicjować rzeczy itp.
• Możliwość pominięcia linii, ustawiania następnej instrukcji do wykonania w innym miejscu.
• Możliwość najeżdżania kursorem na zmienne i podpowiedzi pokazującej mi ich wartości.

Podsumowując, daje mi widok 360 stopni na stan mojego kodu, a nie tylko małe okno.

Nigdy nie znalazłem książki uczącej tego rodzaju rzeczy, ale z drugiej strony wydaje się być dość prosta, jest prawie WYSIWYG.

• Debugger może dołączyć do działającego procesu

• Często łatwiej jest debugować kod z wątkami z debugera

Za pomocą debuggera IDE możesz zobaczyć wartości WSZYSTKICH zmiennych w bieżącym zakresie (na całej wysokości stosu wywołań) za każdym razem, gdy zatrzymasz wykonywanie.

Wydrukuj wyciągi mogą być świetne, ale zrzucenie tak dużej ilości informacji na ekran w dowolnym miejscu może dać całą masę drukowanych instrukcji.

Ponadto wiele debuggerów IDE umożliwia wpisywanie i ocenianie metod oraz ocenianie członków, gdy jesteś zatrzymany, co dodatkowo zwiększa ilość instrukcji print, które musiałbyś wykonać.

Wydaje mi się, że debugery są lepsze dla niektórych języków niż dla innych, jednak ...

Moja ogólna opinia jest taka, że ​​debuggery IDE są absolutnie, zadziwiająco wspaniałe dla języków zarządzanych, takich jak Java lub C #, są dość przydatne w C ++ i nie są zbyt przydatne w językach skryptowych, takich jak Python (ale może się zdarzyć, że po prostu nie wypróbowałem dobrego debugger dla wszystkich języków skryptowych).

Uwielbiam debugger w IntelliJ IDEA, kiedy zajmuję się programowaniem w języku Java. Po prostu używam instrukcji print, kiedy używam Pythona.

Jak ktoś powiedział powyżej: Debugger! = IDE.

gdb i (dawniej) TurboDebugger (samodzielny) działają dobrze dla obsługiwanych języków [red.], dziękuję. (lub jeszcze starsza technologia: debugger Clipper połączony z samym plikiem wykonywalnym xBase) - żadna z nich nie wymagała IDE

Ponadto, chociaż kodowanie w C / ++ jest rzadsze, instrukcje printf czasami maskują ten sam błąd, który próbujesz znaleźć! (na przykład problemy z inicjalizacją w automatycznych zmiennych na stosie lub alokacja / wyrównanie pamięci)

Wreszcie, jak powiedzieli inni, możesz używać obu. Niektóre problemy w czasie rzeczywistym prawie wymagają wydruku, a przynajmniej rozsądnego "* video_dbg = (is_good? '+': '-');" gdzieś w pamięci wideo. Pokazuje mój wiek, to było pod DOS :-)

TMTOWTDI

Oprócz tego, co powiedzieli inni plakaty, naprawdę lubię przechodzić przez jedną linię na raz razem z komputerem, ponieważ zmusza mnie to do myślenia o jednej linii na raz. Często łapię błąd, nawet nie patrząc na wartości zmiennych, po prostu dlatego, że jestem zmuszony spojrzeć na to, gdy klikam przycisk „następna linia”. Jednak nie sądzę, żeby moja odpowiedź ci pomogła, Bill, ponieważ prawdopodobnie masz już tę umiejętność.

Jeśli chodzi o zasoby do nauki, nie korzystałem z żadnych - po prostu przeglądam wszystkie menu i opcje.

Czy to w ogóle prawdziwe pytanie od prawdziwego programisty?

Każdy, kto spędził nawet 5 minut na debugowaniu z instrukcjami drukowania i debugowaniu za pomocą IDE - zdarzy się to bez pytania!

Używałem zarówno wydruków, jak i IDE do debugowania i wolałbym debugować za pomocą IDE. Dla mnie jedyny moment, w którym to nie działa, to sytuacje krytyczne pod względem czasu (takie jak debugowanie gier online), w których zaśmiecasz kod instrukcjami drukowania, a następnie przeglądasz pliki dziennika, gdy wszystko poszło strasznie źle. Jeśli nadal nie możesz tego rozgryźć, dodaj więcej wydruków i powtórz.

Chciałem tylko wspomnieć o użytecznej funkcji debuggera konsoli vs printf i vs debuggera w IDE.

Możesz podłączyć się do zdalnej aplikacji (oczywiście skompilowanej w trybie DEBUG) i sprawdzić jej stan zrzucając dane wyjściowe debugera do pliku za pomocą teenarzędzia POSIX . W porównaniu do printf, możesz wybrać, gdzie wyprowadzać stan w czasie wykonywania.

Bardzo mi to pomogło, kiedy debugowałem aplikacje Adobe Flash wdrożone w agresywnym środowisku . Wystarczy zdefiniować kilka akcji, które wyświetlają wymagany stan w każdym punkcie przerwania, uruchomić debuger konsoli fdb | tee output.logi przejść przez niektóre punkty przerwania. Następnie możesz wydrukować dziennik i przeanalizować informacje poprzez dokładne porównanie stanu w różnych punktach przerwania.

Niestety, ta funkcja [logowanie do pliku] jest rzadko dostępna w debugerach GUI, co sprawia, że ​​programiści porównują stan obiektów w ich głowie.

Nawiasem mówiąc, uważam, że należy zaplanować, gdzie i co debugować, zanim zacznie się debuger.

Cóż, inną rzeczą jest to, że jeśli dołączysz do nowego starego projektu i nikt tak naprawdę nie wie, jak kod robi to, co robi, nie możesz debugować przez echo zmiennych / obiektów / ... b / c, nie masz pojęcia, co to za kod w ogóle stracony.

W mojej pracy mam do czynienia z dokładnie taką sytuacją, a wizualny XDebuging pomaga mi zrozumieć, co się dzieje i gdzie w ogóle.

Z poważaniem

Raffael

Oprócz wielu rzeczy, o których już wspomniano, jedną z najważniejszych zalet debuggera w porównaniu z printf jest to, że używanie instrukcji printf zakłada, że ​​wiesz, w której funkcji znajduje się błąd. W wielu przypadkach tego nie robisz, więc musisz zrobić kilka domysłów i dodać instrukcje print do wielu innych funkcji, aby je zlokalizować. Błąd może znajdować się w kodzie frameworka lub gdzieś daleko od tego, gdzie myślisz, że jest. W debugerze znacznie łatwiej jest ustawić punkty przerwania w celu zbadania stanu w różnych obszarach kodu iw różnych momentach czasu.

Ponadto przyzwoity debugger pozwoli ci na debugowanie w stylu printf, dołączając warunki i akcje do punktów przerwania, dzięki czemu nadal zachowujesz zalety debugowania printf, ale bez modyfikowania kodu.

Debugowanie w środowisku IDE jest nieocenione w środowisku, w którym dzienniki błędów i dostęp do powłoki są niedostępne, na przykład na współdzielonym hoście. W takim przypadku IDE ze zdalnym debugerem jest jedynym narzędziem, które pozwala wykonywać proste czynności, takie jak przeglądanie stderrlub stdout.

Problem z używaniem instrukcji print polega na tym, że powoduje to bałagan w kodzie. IE, masz funkcję z 10 częściami i wiesz, że gdzieś się zawiesza, ale nie jesteś pewien gdzie. Więc dodajesz 10 dodatkowych instrukcji print, aby wskazać, gdzie jest błąd. Po znalezieniu i rozwiązaniu błędu musisz teraz wyczyścić, usuwając wszystkie te instrukcje print. Może to zrobisz. Może zapomnisz i skończy się w produkcji, a konsola twojego użytkownika będzie pełna wydruków debugowania.

Wauw, podoba mi się to pytanie. Nigdy nie odważyłem się go postawić ...

Wygląda na to, że ludzie mają po prostu różne sposoby pracy. U mnie najlepiej działa:

• Posiadanie solidnego modelu mojego kodu, w tym zarządzania pamięcią
• Używanie narzędzi (takich jak instrukcje drukowania) do śledzenia tego, co się dzieje.

Od ponad 40 lat zarabiam na życie programując, pracując codziennie nad nietrywialnymi technicznymi i naukowymi aplikacjami w C ++ i Pythonie, i mam osobiste doświadczenie, że debugger mi trochę nie pomaga.

Nie mówię, że to dobrze. Nie mówię, że to źle. Po prostu chcę się tym podzielić.

To nie tylko debugowanie. IDE pomaga w szybszym tworzeniu lepszego oprogramowania na wiele sposobów:

• narzędzia do refaktoryzacji
• intelisense, aby uczynić api bardziej wykrywalnym, lub przypominać o dokładnej pisowni / przypadku znanych elementów (niewiele przydatnych, jeśli używasz tego samego systemu przez 15 lat, ale to rzadkie)
• oszczędzaj na wpisywaniu poprzez autouzupełnianie nazw zmiennych i klas
• znajdź określone rodzaje błędów, zanim jeszcze zaczniesz kompilować
• Automatycznie przechodź do deklaracji / definicji zmiennych / metod / klas, nawet jeśli nie znajdują się one w tym samym pliku lub folderze.
• Przerwij na nieobsłużone i obsługiwane wyjątki

Mógłbym kontynuować.