Wskazówki dotyczące debugowania z bardzo małą ilością informacji? [Zamknięte]

Odziedziczyłem projekt z dość dużą bazą kodu, a oryginalny programista rzadko, jeśli w ogóle, odpowiada na e-maile. Istnieje mnóstwo różnych sposobów, aby to zrobić, a ja nie znam ich wszystkich. Dużo zduplikowanego kodu na tych ścieżkach (zamiast funkcji zawartych, powiedzmy, 5 stron, które robią względnie to samo, kod jest kopiowany na 5 stronach) i pewne subtelne problemy w bazie danych (wszyscy słyszeliśmy o kodzie spaghetti , ale czy słyszałeś kiedyś o bazie danych spaghetti?)

Z tym wszystkim radzę sobie przez większość czasu bez problemu.

Problem polega na tym, że klient gdzieś znajdzie błąd. Zazwyczaj wysyłają zrzut ekranu kończącego się problemu i mówią: „Czy mógłbyś na to spojrzeć?” jednocześnie podkreślając, że na stronie jest coś niewłaściwego, a czasem tego, czego oczekiwano. Podaje się niewiele innych informacji, a próba rozmowy z nimi i zdobycia więcej (np. Tego, co zrobili, aby uzyskać wynik) jest jak ciągnięcie zębów.

Zasadniczo sprowadza się do tego:

• Duża i złożona baza kodu nie jestem w 100% zaznajomiona
• Wiele sposobów może się nie udać
• Bardzo mało informacji o tym, jak powstał błąd

Czy ktoś ma jakieś wskazówki, porady, sugestie itp. Dotyczące debugowania tego rodzaju rzeczy?

Kiedy dostaję coś takiego, zwykle żądam więcej informacji. Nie jestem pewien, jak to jest, gdzie pracujesz, ale tutaj, jeśli nie mam wystarczających informacji, aby odtworzyć problem lokalnie, mogę odesłać bilet z oznaczeniem Nie można odtworzyć, z prośbą o więcej informacji, i wiedzą, że nic nie zostanie naprawione, dopóki Jestem w stanie to zepsuć po mojej stronie.

Jeśli Twoi klienci mają problem z opisaniem kroków, poproś ich o zrzut ekranu z filmem. Istnieje kilka bezpłatnych produktów, które mogą je tworzyć, takich jak Jing. Ułatwia to oglądanie dokładnie tego, co robią.

EDYCJA: Jing był dobrym pomysłem, kiedy napisałem to kilka lat temu. Od tego czasu zmodyfikowali swój instalator, aby załadować system z „dodatkowym” crapware, o który nigdy nie prosiłeś, więc nie mogę go dłużej polecać. Istnieje jednak wiele przyzwoitych rejestratorów ekranu.

Dobrym początkiem może być ta książka .

Korzystam z poniższej definicji, ponieważ wygląda na to, że programisty nie ma w pobliżu, aby ją wesprzeć.

Starszy kod to kod źródłowy, który odnosi się do nieobsługiwanego już.

Miałem podobny problem kilka lat temu, a największym wzrostem wydajności i czyszczenia kodu było zintegrowanie śledzenia błędów w systemie.

Użyliśmy Fogbugz (zakładam, że nadal robią Fogcreek!) I byliśmy w stanie zbudować mechanizm obsługi wyjątków, w którym użytkownik może nacisnąć przycisk w dowolnym momencie, gdy wyjątek zostanie zgłoszony i zostanie natychmiast zalogowany do naszego systemu - nie będzie więcej połączeń i nigdy więcej zrzutów ekranu. Dzięki tej opcji bierzesz potrzebne informacje zamiast próbować wyodrębnić je od użytkownika. Wygląda na to, że jakiś wariant przydałby Ci się dobrze, zwłaszcza z opcją zrzutu ekranu.

Inną rzeczą, którą chcesz zacząć, to zacząć dodawać rejestrowanie. Możesz sięgać nawet do rejestrowania każdego wywołania metody z wartościami argumentów. Ponieważ wygląda na to, że pracujesz ze starszym kodem (kod bez testów), to logowanie pomoże Ci dodać odpowiednie testy jednostkowe, abyś nie powtarzał żadnych problemów.

Moja najszczersza rada to rozpoczęcie refaktoryzacji tam, gdzie to możliwe. Nie mogę policzyć, ile razy widziałem kopię funkcjonalności, ale okazało się, że nie była to w 100% pełna kopia. To było 99,9% kopii i 1 mały, drobny błąd, który spowodował błąd. Zacznij dodawać testy jednostkowe do wszystkiego, a jeśli masz dział kontroli jakości, spróbuj uruchomić zautomatyzowane skrypty testowe dla tych fragmentów kodu, który pracujesz.

Z drugiej strony sprawdź, ile logowań można wprowadzić do kodu. Oznacza to, że jeśli nie ma zbyt wiele przeszkód w logowaniu, możesz dodać flagę do kodu, aby rozpocząć zbieranie pełnych informacji do własnych celów debugowania. Jest to coś, co użytkownik może włączyć lub wyłączyć, jeśli można uruchomić okno dialogowe. Pomogło mi to więcej razy, niż potrafię zliczyć. Zwykle dostaję „to nie działa” bez zdjęcia problemu. Mówię tylko: „wyślij mi plik dziennika”.

Zacznij od napisania testów jednostkowych. Wybierz klasę lub funkcję i napisz zestaw testów odpowiadający, jak Twoim zdaniem powinien on działać. Jeśli testy się nie powiodą, dowiedz się, dlaczego. Jeśli jest to błąd - napraw go. Jeśli twoje oczekiwania okażą się błędne, dowiedz się, co faktycznie robi i odpowiednio zmodyfikuj testy.

Gdy masz już przyzwoity zestaw testów jednostek roboczych, masz siatkę bezpieczeństwa do przeprowadzenia refaktoryzacji w celu oczyszczenia kodu.

Powtarzaj, dopóki nie zrozumiesz podstawy kodu.

Nie trzeba dodawać, że należy to zrobić z wyprzedzeniem, a nie w odpowiedzi na zgłoszenie błędu.