Ja, na przykład, dodaję kod debugowania (taki jak instrukcje drukowania) tylko wtedy, gdy próbuję zlokalizować błąd. A kiedy go znajdę, usuwam kod debugowania (i dodam przypadek testowy, który konkretnie testuje ten błąd). Czuję, że zaśmieca prawdziwy kod i dlatego nie ma tam miejsca, chyba że debuguję.
Jak ty to robisz? Czy pozostawiasz kod debugowania na miejscu, czy usuwasz go, gdy jest przestarzały (co może być trudne do oceny, kiedy to jest)?
Odpowiedzi:
Należy wyciągnąć instrukcje drukowania debugowania; Jeśli jednak chcesz je dodać, aby debugować problem z produkcją, warto rozważyć, czy masz wystarczającą ilość informacji w swoim systemie rejestrowania. Informacje o parametrach, stanach błędów i tak dalej mogą być przydatne później, gdy pojawi się następny błąd. Korzystanie z dobrego środowiska rejestrowania, które może dynamicznie włączać komunikaty dziennika debugowania lub śledzenia, może być bardzo przydatne na wolności.
Kod dodany specjalnie do debugowania powinien zostać usunięty z oprogramowania produkcyjnego.
To, czy jest to całkowite usunięcie, czy umieszczenie w sekcjach kompilacji warunkowej (jak w C / C ++ / C #), zależy od Ciebie i Twojego standardu kodowania.
Istnieje wiele powodów:
ChrisF i Alaric mają ważne punkty; +1 dla nich. Potrafię zidentyfikować co najmniej 5 różnych typów kodu debugowania, którego używam.
Używanie dzienników do zrzucania stanu systemu w określonym momencie.
void function(...)
{
...dump everything i know about.
}
Używanie dzienników do wykonywania punktów kontrolnych.
void function(...)
{
...got here 1
...got here 2
}
Kod, który faktycznie wymusza spełnienie określonego warunku, ale psuje normalne zachowanie. Przykład:
Rejestrowanie weryfikacji - sklasyfikowałbym to jako rejestrowanie pełne, które może być użyte do sprawdzania poprawności oprogramowania, które nie powinno być uwzględniane w produkcji, jak na przykład sprawdzanie poszczególnych kroków algorytmu.
Rejestrowanie operacji - zapoznaj się z postem Alarica . To właściwie to, co rozumiem przez „rejestrowanie operacji”.
1, 2 i 3 powinny być całkowicie usuwane. Coś w rodzaju 4 Prawdopodobnie skompilowałbym warunkowo z kodu. W przypadku 5 Alaric miał świetną okazję do dynamicznego wyłączania dzienników. W większości przypadków może to dotyczyć punktu, w którym ChrisF ma swoją drugą kulę.
1)… przez 1.… (tak, że formatowanie Markdown rozpoznaje go jako listę) i wcina przykładowy kod o 8 spacji (ponownie, aby Markdown podniósł go jako przykład kod na liście).
To zależy od tego, co robi kod. Część kodu używanego do debugowania można pozostawić bez zmian, a niektóre należy usunąć.
Kod weryfikujący poczytalność parametrów w metodzie nie zawsze jest przydatny, gdy kod działa poprawnie, ale często jest utrzymywany, aby upewnić się, że kod nadal działa poprawnie.
Czasami piszesz kod inaczej, aby ułatwić debugowanie kodu, na przykład obliczanie wartości i umieszczanie jej w zmiennej lokalnej, a następnie użycie zmiennej w następnym wierszu, co ułatwia sprawdzenie wyniku obliczenia podczas pojedynczego kroku przez kod. Możesz przepisać kod, aby bezpośrednio użyć obliczonej wartości, ale koszt użycia zmiennej lokalnej jest tak mały (jeśli w ogóle), że nie ma powodu, aby przepisywać kod. Poza tym po przetestowaniu kodu nie ma sensu, zawsze istnieje niewielkie ryzyko, że wprowadzisz błąd podczas jego zmiany.
Kod, który dodajesz tylko w celu wyśledzenia określonego błędu, często można usunąć po jego znalezieniu.
Dawno, dawno temu używałem dużo kodu do debugowania. Niemal całkowicie celowałem w system Windows, więc było wiele funkcji wyjściowych łańcucha debugowania, których nie pamiętam, jak przeliterować, więc mogłem przechwycić ślad za pomocą konkretnego programu.
Część kodu debugowania pozostała na miejscu, szczególne rzeczy, które miały zagnieżdżać wywołania. Jednak pomimo tego, że ciąg znaków debugowania w większości nie byłby widoczny w systemie produkcyjnym, wszystko to zostało wykonane w ramach kompilacji warunkowej.
Rzeczywistość jest jednak taka, że cały ten kod debugowania wymagał dużego wysiłku w przypadku czegoś, co idealnie byłoby obsługiwane w inny sposób - oczywiście przy użyciu debugera. W tym czasie nie byłem pod wrażeniem debuggera Borland C ++. Narzędzia były tam, ale zbyt często dawały mylące wyniki, a użycie debuggera innego niż IDE (często konieczne) oznaczało zapamiętanie skrótów klawiszowych, co oznaczało odwrócenie uwagi od wykonywanego zadania.
Jedynym doświadczeniem debugowania, które jest gorsze, jest GDB z wiersza poleceń.
Bycie ekspertem w zakresie narzędzi, których używasz na co dzień, jest oczywiście ważne - ale debugowanie naprawdę nie powinno być czymś, co robisz na co dzień. Jeśli używasz debugera tak często, możesz nauczyć się dziesiątek poleceń i / lub skrótów klawiaturowych, wydaje mi się to nieco czerwoną flagą.
Kiedy pracowałem w Visual Studio 7, było jednak jasne, że debugowanie może być bardzo praktyczne i skuteczne. Jeśli możesz przeprowadzić debugowanie w programie Visual Studio (w tym wersje ekspresowe), debugowanie jest bardzo proste. Bez wątpienia, jeśli możesz znaleźć odpowiedni interfejs GUI / IDE, GDB jest również łatwy i skuteczny, chociaż nie przeprowadziłem jeszcze tego wyszukiwania.
Można również powiedzieć coś o testowaniu jednostkowym, z analizą zasięgu za pomocą gcov. Im bardziej pewne jest zachowanie bibliotek, tym mniej potrzeba głębokiego debugowania - i tym rzadziej potrzebujesz debuggera. Pisanie testów jednostkowych jest dość rozsądnym rozwiązaniem, które powinieneś robić przez większość dni.
Nieoczekiwanie ważne narzędzie = cmake, narzędzie do budowania, które pozwala mi łatwo przełączać się między budowaniem dla GCC i dla VC ++, między innymi. Mogę więc przeprowadzić testy jednostkowe i zasięg oparty na gcov za pomocą GCC, ale łatwo przejść do VC ++, aby użyć debuggera.
Moje zdanie: kod debugowania używany do zabicia błędu w danym kodzie, który zazwyczaj usuwam całkowicie. Kod debugowania użyty do zabicia błędu wynikającego z sił zewnętrznych, które zazwyczaj po prostu komentuję.
Jeśli błąd pochodzi z testowania jednostkowego lub wewnętrznego, kod debugowania można całkowicie usunąć. Ale jeśli błąd pochodzi z produkcji, kod debugowania powinien znajdować się wewnątrz znaczników kompilacji. Umieszczenie go w znacznikach kompilacji pomoże innym programistom zrozumieć, że ten kod służy wyłącznie do debugowania.
Użyj TDD , aby Twój kod testowy zawsze zawierał miejsce, w którym jest utrzymywany.