Mniejsze zło debugowania
2007-11-13 12:44Banałem będzie stwierdzenie, że szukanie błędów w kodzie bywa wkurzające. Odpowiedź na proste pytanie – dlaczego coś nie działa? – to czasami długie godziny dłubania w programie, mało przyjemnych rendez-vous z debuggerem czy nawet stosowania bardziej drastycznych metod. Ale ponieważ w programowaniu nic nie dzieje się bez powodu (a przynajmniej chcemy w to wierzyć ;D) i przy założeniu, że dysponujemy odpowiednio dużymi zasobami: czasu, samozaparcia, a przede wszystkim umiejętności, w końcu uda się znaleźć tę upragnioną przyczynę błędu…
A przyczyny mogą być trywialne. Pomyłka o jedynkę, nieopacznie wstawione x zamiast y, pomylenie plusa z minusem , i tak dalej. Takie błahostki zgodnie z prawem Murphy’ego mają wybitną skłonność do pojawiania się akurat w tych newralgicznych miejscach, które mają największy wpływ na działanie całego kodu – i oczywiście całkowicie je rozstrajają. A co gorsza, z bliżej niewiadomych przyczyn programistę uważnie oglądającego fragmenty z takimi “literówkami” ogarnia najczęściej chwilowa ślepota tudzież niewytłumaczalny zanik spostrzegawczości. Dopiero za n-tą inspekcją, przeprowadzoną najlepiej po długim odpoczynku od kodu, da się cokolwiek znaleźć.
Z drugiej strony poważne i trudne do znalezienia błędy mogą mieć poważne i trudne do usunięcia przyczyny. Inżynieria oprogramowania mówi, że im wcześniej w cyklu tworzenia programu błąd się pojawił, tym trudniej jest go potem wyeliminować. Jeżeli więc kruczek tkwił w założeniach projektowych, w modelu programu lub, co gorsza, w określeniu funkcjonalności, to nie będzie łatwo poradzić sobie z nim na etapie implementacji. Wyburzenie kilku ścian nie pomoże, jeśli fundamenty położono na niestabilnym gruncie.
Którego z tych dwóch rodzajów błędów oczekiwalibyśmy, jeżeli spędziliśmy już na debugowaniu dużo, naprawdę dużo czasu? Błąd drugiego typu to sprawa ciężkiego kalibru. Można wówczas powiedzieć, to oto odkryliśmy problem, który rzeczywiście jest adekwatny do tych godzin czy dni spędzonych na polowaniu na niego. Inaczej mówiąc, możemy uznać, że faktycznie zrobiliśmy wszystko, co w naszej mocy, i że cały ten wysiłek był naprawdę potrzebny, gdyż nie było innej drogi.
Z kolei pierwszy typ błędu to właściwie przeciwny biegun. Teoretycznie można było go załatwić w najwyżej kilkanaście minut, po prostu przeglądając jeszcze raz kod i dopisując ten zapomniany przecinek czy cokolwiek innego. Jak mogliśmy w ogóle spędzić nad tym tyle czasu, który przecież powinno się wykorzystać bardziej produktywnie?
Jeżeli kiedykolwiek ktoś odkryje przyczynę owej chwilowej ślepoty programistów na drobne omyłki, to osobiście uważam, że zasługuje przynajmniej na Ig Nobla :) Sądzę też jednak, że o wiele lepiej jednak paść jej ofiarą niż stwierdzić, że znaleziony błąd jest ową “ciężką sprawą”. Może i obniży to nieco naszą samoocenę, ale przynajmniej oszczędzi mnóstwa roboty.
-
k_b:
November 13th, 2007 o 15:31Heh, jakieś dwie godziny temu myślałem nad kodem dlaczego tak źle się wyświetlają flagi państw (edytor do gry strategicznej), gdy jakąś wstawimy. Po zabawach z logerem i komentowaniem kodu odpocząłem, zacząłem jeszcze raz przeglądać kod i… okazało się, że przypisywałem w (width) dla x, a h (height) dla y zamiast przypisywać na odwrót :P. Ja się raczej zastanawiam jak można popełnić tak głupi błąd :).
-
Liosan:
November 13th, 2007 o 23:03Ponoć genialne skutki przynosi inspekcja kodu w kilka osób – twórca pokazuje a wszyscy szukają… jak zobacze to uwierze :)
-
io:
November 14th, 2007 o 23:34Pamiętam jak kiedyś siedziałem bite 3 dni… i jak wielka była radość, gdy ten błąd odnalazłem :). Hm, a w zeszłym roku, jak pisałem magisterkę z symulacji komputerowych… wtedy po 7-8 miesiącach odkryłem z kolegą, że i ja i on mamy błąd w swoich programach. Wszystko by było pięknie, gdyby nie to, ile procesoro-godzin (albo raczej tygodni (jeśli nie miesięcy ;) ) i to na mocnych klastrach obliczeniowych), poszło gdzie raki zimują ;).
pozdrwaiam
-
Reg:
November 15th, 2007 o 16:13Ja znam częściwą przyczynę tej ślepoty. Jest nią Bjarne Stroustrup i inni twórcy języków programowania, którzy przy projektowaniu kierowali się niewiadomo-czym zamiast odpornością na błędy i zrobili tak, że wystarczy “=” zamiast “==”, żeby program źle działał… zamiast zgłosić błąd kompilacji.
-
Xion:
November 15th, 2007 o 20:18Owszem, języki są mało ‘niebłędotwórcze’, ale czasami z dobrymi chęciami można przesadzić. Przepraszam, że znowu narzekam na biedną Javę, lecz to właśnie tam konieczne jest śledzenie wszystkich możliwości wyrzucania wyjątków i tworzenia kodu łapiącego lub określania, że wyjątek może opuścić funkcję. Fakt, nieco większe bezpieczeństwo – i nieco więcej roboty :)
-
io:
November 16th, 2007 o 9:36Akurat operatory == i = są dość zrozumiałe. Prawdą jest, że początkujący zawsze mają z tym problemy, ale łatwo się do tego przyzwyczaić. Poza tym pomylenie tych operatorów nie powinno generować błędu, gdyż ograniczałoby to możliwości programistyczne w C. I w sumie nie jest to wina Bjarne`a, który przecież nie wymyślił języka ANSI C, tylko przerobił na C++ :), a te operatory istniały wcześniej.
Dodam do tego, że większość dobrych kompilatorów daje warningi w miejscach gdzie przeważnie używa się innego operatora, niż został użyty.pozdrawiam
-
KKKas:
November 18th, 2007 o 23:56Reg: Jeśli chodzi o == i =, to częściowym rozwiązaniem jest przestawienie się na pisanie:
if (STALA/funkcja == zmienna)
zamiast:
if (zmienna == STALA/funkcja)Przy pomyłce == z = przynajmniej kod się nie skompiluje… Minusem jest, że nad kodem z taką kolejnością trzeba zastanowić się 100ms dłużej niż nad “standardowym” zapisem, ale może nieraz uratować nas od błędu ;-)
Recent posts
