Programowanie to bardzo przyjemne i pozwalające się spełnić zajęcie....
Do czasu gdy coś pójdzie nie tak ;-)
Wtedy, gdy rozwiązuje się problemy najlepiej posługiwać się jedną prostą heurystyką, która wyraża się w krótkim "To Twoja wina" ;-)
Objawia się to na kilka sposobów, dziś o trzech ;-)
Przecież ten kod tego nie mógł popsuć!
Sytuacja:
Wcześniej działało, do kodu dodano proste zmiany, które zostały już przejrzane i NIE MAJĄ PRAWA sprawiać problemów, a kod się nie kompiluje/nie działa coś czego nie dotykano.
Przeglądamy kod po raz 10 i upewniamy się, że to NA PEWNO nie jest wina tego kodu.
Rzeczywista przyczyna problem:
To prawie na pewno wina tego świeżo dodanego kodu.
Co do tej zmiany masz 100% pewność, że wystąpiła. Wszystkie inne przyczyny problemu, jak zmiana konfiguracji, pad serwera/bazy, problemy z classloaderem, działalność skrzatów czy cud są możliwe, ale zdecydowanie mniej pewne jest to, że akurat teraz wystąpiły.
To, że czytając kod nie widzisz błędu niczego nie dowodzi, patrzysz na kod szukając potwierdzenia tego, że działa dobrze i widzisz to czego wypatrujesz. Tak spostrzec możesz zwykle tylko bardzo wyraźne błędy.
Rozwiązanie:
Usuń te zmiany w kodzie, powtórz test.
Dopiero teraz, jeśli nadal coś nie działa szukaj winnych gdzie indziej.
Zysk:
Szybciej wrócisz do etapu tworzenia, mniej się będziesz denerwować tym, że świat działa bez sensu.
Znowu coś popsuli!
Sytuacja:
Aplikacja działa i nagle przestaje. Coś się nie zapisuje tam gdzie powinno, albo wyświetlają się dane.
Prawie na pewno pada tekst "k... znowu padł .....".
Rzeczywista przyczyna problemu:
Prawdopodobnie masz błąd w aplikacji, który nie jest widoczny od razu.
Wyciek pamięci, albo classloader czy coś podobnego wariuje. A zwykle po prostu błąd w nowo dodanym kodzie, który dopiero w takich warunkach się objawia.
Rozwiązanie:
Sprawdź logi, spytaj kogoś kto korzysta z podobnej konfiguracji czy u tej osoby działa, zresetuj aplikację, zresetuj komputer. Jeśli nic nie pomaga, to grzecznie i delikatnie spytaj tego kto kontroluje to co wydaje się być winowajcą czy coś zmienili w konfiguracji.
Zysk:
Nie będzie trzeba później iść do kogoś i przyznawać, że to jednak był błąd po Twojej stronie. Jeśli błąd jest u kogoś innego to grzecznie o nim informując wiesz, że ten ktoś się tym zajmie bo mu będzie wstyd, że zawiódł Cię jako usera, nie będzie się denerwować, że go ktoś napada i nań krzyczy.
Ktoś zrobił commit z felernym kodem.Sytuacja:
Robisz zmiany, chcesz zrobić update do najnowszej wersji, ściągasz ją, mergujesz gdy trzeba, kompilujesz i jest problem już w trakcie kompilacji albo w trakcie testowania.
Od razu podejrzewasz, że to ktoś coś zmienił i popsuł Twój kod. Zaczynasz przeglądać commity by znaleźć winnego...
Rzeczywista przyczyna problemu:
Prawie na pewno przyczyna Tkwi w Twoim kodzie.
Każdy stara się wrzucić do repo kod, który działa, czasem zdarzają się błędy, ale dużo rzadziej niż dobre commity. Jeśli zmiany są w Twoim kodzie, który jeszcze nie trafił do repo i w cudzym który do repo trafił to są duże szanse, że Twój kod jest źródłem błędu. To, że tego nie było wcześnie widać to tylko przypadek.
Zysk:
Jeśli będziesz szukać błędu w cudzym kodzie to gdy go nie znajdziesz będziesz mieć skrycie pretensje do tej osoby bo zmarnujesz czas próbując przed sobą dowieść, że to nie Twoja wina, a w końcu dojdziesz do wniosku, że jednak była Twoja...
Nawet jeśli problem nie był w Twojej zmianie to zyskujesz, bo po pierwsze osoba, która wprowadziła błąd może go w międzyczasie znaleźć, jeśli tego nie zrobisz to idąc do tej osoby mówisz "Hej, chyba coś się popsuło, sprawdziłem swój kod i wydaje mi się, że to nie jego wina, możemy sprawdzić u Ciebie?", od razu jesteś tym kimś kto był miły i wyrozumiały, a to procentuje ;-)
Lekcja jest prosta, pokornym trzeba być i trzeba zakładać, że to jest Twój błąd.
Gdy nie jest to Twój błąd to masz nagrodę, że to jednak nie Twoja wina, jeśli jednak to był Twój błąd to nie denerwujesz się niepotrzebnie obwiniając innych i nie musisz się wstydzić tym, że komuś przypisałeś swój błąd.
A, że jednak to zwykle jest Twój błąd to szybciej go znajdujesz i uczysz się na przyszłość takich więcej nie robić ;-)
Podobne postybetaO tym czemu branche są złe...Kiedy zmieniać pracę i po co? (w IT) WyboryA może by tak rubber duck debugging stosować do problemów życiowych? ;-)OS X po tygodniu - tak sobie
.png)
.png)
