Wylapywanie glupich bledow, jak sobie radzic.

Witam,
Podczas pisania programu, dosc duzego, co chwile zatrzymuje sie przy sory za wyrazenie, [CIACH!].

Przykladowo, wysylam komunikat do serwera z loginem a ten za cholere go <ort>niechce </ort>przyjac. Czytalem RFC, idealna zgodnosc. Lacznie zmarnowalem prawie pelne 2 dni (!) zeby dojsc do tego, ze trzeba wyslac ten login odczekujac jakies 3-5 sekund po powitaniu...

<ort>Wkoncu </ort>moge posunac sie z programem dalej, ale co to... kolejny blad w juz gotowej funkcji, ktora wykrzacza program znowu <ort>niewiedziec </ort>dlaczego.

Ogolnie pomysl + pisanie zajmuje jakas srednio godzine, a wylapywanie bledow, kilka dni (!!!) nawet najglupszych. Czy to jest normalne? Czy z programowaniem zawsze tak jest, ze przez glupoty, dziwne bledy marnuje sie wiele dni?

Poszukujacy PRAWDY napisał(a)

Ogolnie pomysl + pisanie zajmuje jakas srednio godzine, a wylapywanie bledow, kilka dni (!!!) nawet najglupszych. Czy to jest normalne? Czy z programowaniem zawsze tak jest, ze przez glupoty, dziwne bledy marnuje sie wiele dni?

Tak. Im masz więcej praktyki, tym programujesz szybciej: nie dlatego, że łatwiej znaleźć błędy, ale dlatego, że pisanie zajmuje już tylko pół godziny :>

Mówiąc serio, omijanie takich błędów to kwestia 2 rzeczy: po pierwsze doświadczenie w temacie (dlatego nie szuka się do pracy po prostu programistów, tylko programistów z doświadczeniem w czymś konkretnym), po drugie intuicji i dostrzegania potencjalnych błędów tam, gdzie nikt inny ich nie widzi.

Poszukujacy PRAWDY napisał(a)

Czy z programowaniem zawsze tak jest, ze przez glupoty, dziwne bledy marnuje sie wiele dni?

Niestety tak zostaje do końca. Czasem głupoty zabierają znacznie więcej niż kilka dni..

Ja czesto stosuje podejscie z pisaniem testow. Pisze test np. klasy, ktory przy okazji wyznacza co dana klasa/metoda ma robic. Implementuje to co trzeba, zapuszczam test, poprawiam bledy, testuje, poprawiam bledy itp. I o klasie/metodzie zapominam, bo robi dokladnie co powinna. Jak pozniej cos dodaje, zmieniam, poprawiam, wystarczy zapuscic test, zeby sprawdzic czy WSZYSTKO hula tak jak powinno :) Niestety nie zawsze sie da test napisac, a po drugie pisanie testow zajmuje rowniez sporo czasu.

Testy to pomocne rozwiązanie, ale czasem pisząc test też nie dostrzegasz samemu, że coś powinno działać inaczej - być może tak, jak z tym serwerem z pierwszego postu. Czasem by się przydało, gdyby test twojego kodu pisał ktoś inny.

No tak jest idealnie, jak sie pisze zespolowo, ale nie zawsze jest zespol do pomocy :) Ja staram sie pisac test zgodnie z zalozeniami projektowymi, jak juz jest ustalone co jak ma dzialac.

ja odkryłem metodę: pisać małe kodziki próbujące każdą możiwość kodu i będące bardzo "verbose", po poznaniu ich wyników łączyć w gotow program usuwając verbosity itp.

Robię podobnie. Najpierw piszę kod. Działa - super. Nie działa, to wyświetlę sobie wartość jakiejś zmiennej czy stan programu. Jest zgodny z zamierzeniami - szukam dalej, nie jest - błąd jest gdzieś wcześniej. Znów coś sobie wyświetlę.

Jak mimo tego nie daję rady to dopiero debugger i jazda :D

Jak debugger nie daje rady, to na jakiś czas z danym kodem daję sobie spokój - często wracając do niego od razu błąd staje się oczywisty.

Szczawik napisał(a)

[...] - często wracając do niego od razu błąd staje się oczywisty.

Tez tak mam, dobrze jest sie oderwać od programu na jakiś czas bo gdy podchodzisz do niego za drugim razem jesteś mniej wkręcony w kod, a wkręcając sie od nowa widzisz głupie i oczywiste błędy.

sama prawda.. ja do tego wlaczam jeszce jedna rzecz, po czesci zwiazana z idea testow -- na czas 'pierwszego pisania' czesto przygotowuje w klasach metody podobne do void validate(); wywolywane na starcie i tuz przed koncem kazdej metody, i ktorych zadanie jest jedno: sprawdzic dokladnie stan obiektu, jak cos bedzie nie tak, throw z opisem. duza zaleta jest to, ze wnetrze validate() mozna w bardzo latwy sposob o #ifdef ktory ja totalnie wylaczy w wersjii 'release'. a kiedy mamy pewnosc ze juz sie na peno nie przyda, to i kazde jej wywoalnie mozna oifdefowac. a juz w ogóle luksus jak sobie napisac male makro ktore skraca to wszystko (prolog/epilog funkcji) do pojedyncych linijek :)

quetzalcoatl napisał(a)

sama prawda.. ja do tego wlaczam jeszce jedna rzecz, po czesci zwiazana z idea testow -- na czas 'pierwszego pisania' czesto przygotowuje w klasach metody podobne do void validate(); wywolywane na starcie i tuz przed koncem kazdej metody, i ktorych zadanie jest jedno: sprawdzic dokladnie stan obiektu, jak cos bedzie nie tak, throw z opisem. duza zaleta jest to, ze wnetrze validate() mozna w bardzo latwy sposob o #ifdef ktory ja totalnie wylaczy w wersjii 'release'. a kiedy mamy pewnosc ze juz sie na peno nie przyda, to i kazde jej wywoalnie mozna oifdefowac. a juz w ogóle luksus jak sobie napisac male makro ktore skraca to wszystko (prolog/epilog funkcji) do pojedyncych linijek :)

Ja tego nie robie ale chyba spróbuje... brzmi zachęcająco :-)

Ta metoda nazywa się inkluzją asercji.

Dobra, jak wiesz, co chcesz konkretnego zapewnić w wyniku funkcji, ale jeśli po prostu szukasz w miejscu 'jakiegoś' błędu, to nie zawsze daje rezultaty przy dużym nakładzie pracy; nie daje też często rezultatów przy błędach, wynikających ze stanu systemu (na przykład niedziałanie funkcji zapisu do pliku, bo zabrakło miejsca na dysku). Oczywiście na to są i inne metody.

wiem jak sie nazywa, jednak nazwa neizorientowanemu nie pomoze.. poza tym tak jak przy kazdych testach - spradzic mozna do woli, lacznie ze stanem systemu i innymi dziwami (kto mi zabroni napisac asserta testujacego czy wolne miejsce na dysku >= potrzebne :) ), wszystko zalezy tylko od tego ile chcemy czasu poswiecic na pisanei tego.. a na bledy wynikle nagle i w zapomnianym/nieprzewidzianym miejscu to tylko logi i sledzic w debuggerze..

Johnny_Bit napisał(a)

ja odkryłem metodę: pisać małe kodziki próbujące każdą możiwość kodu i będące bardzo "verbose", po poznaniu ich wyników łączyć w gotow program usuwając verbosity itp.

Dobra metoda. W inżynierii czasami nazywa się to "Ruskim Testem". Postępuję podobnie, ale jako że 90% kodu jaki napisałem w życiu powstał w Javie to mam trochę ułatwione zadanie. Wbito mi do głowy programowanie sterowane testami. Najpierw staram się napisać JUnitowe testy w oparciu o interfejs. Następnie implementuję interfejs i jeżeli muszę wykorzystać coś co jeszcze nie powstało piszę najprostszą zawsze działającą fasadę. Następnie odpalam test. Działa to borę się za następną klasę. Nie? JUnit i tak mi pokarze który test się wywalił już wiem gdzie szukać. jak nie widać na pierwszy rzut oka to odpalam debugger "na kartce" i piszę sobie co kod w każdej linii robi. Jak "na zdrowy chłopski rozum" całość działa to odpalam normalny debugger i szukam błędów.

Warto poszukać odpowiedników JUnita dla języka w którym aktualnie się pisze.

Dla C# podobnie dziala NUnit (zreszta pewnie wzorowany), wielkim plusem jest integracja ze srodowiskiem #develop :)

dla C++ - w booscie jest framework od testow.. zapomnialem nazwy:| boost::test? jakos tak

Taka mała moja sugestia, może ktoś z was zechciałby się podzielić swoją wiedza i praktyką jeśli idzie o używanie takich mechanizmów jak [J|N]Unit? Najlepiej za pomocą, prostego choćby artykułu? Co Wy na to Koziołek, johny_bravo?

Qyon napisał(a)

Taka mała moja sugestia, może ktoś z was zechciałby się podzielić swoją wiedza i praktyką jeśli idzie o używanie takich mechanizmów jak [J|N]Unit? Najlepiej za pomocą, prostego choćby artykułu? Co Wy na to Koziołek, johny_bravo?

Do JUnita powoli przymierzam się do napisania czegoś, ale nie mam czasu :( Niestety.

No ja niestety to samo... Odpisanie na forum to chwila, ale napisanie arta chyba ponad mozliwosci jesli chodzi o czas... Zreszta nie wiem czy bym podolal ;P

OK w dziale poświęconym Javie jest już artykuł o JUnit i prosty przykład testów. Zapewne będę go jeszcze modyfikował, jednak na teraz wystarczy. link
Testy jednostkowe

drobna uwaga - unit tests przypadkiem sie nie tlumaczy na testy modulowe?

W środowisku javowym przyjęło się używać określenia "testy jednostkowe". Żeby było weselej określenie "testy modułowe" jest używane we wszelkich innych środowiskach :)

eh.. widac javowcy jak zwykle musieli sobie zrobic nowy, lepszy termin na kolejna zapozyczona skad inad rzecz:)

a nie :) tym razem ciała dała korekta w helionie bodajże. Nie pamiętam już w której książce pojawiło się to określenie. Zgłaszano erratę, ale nik nic nie poprawił :)

hehe.. a to przepraszam tutaj Javowcow za ten konkretny przypadek :) a z helionem to rzeczywiscie czesto jego terminologia jest "po prostu inna".. np. ostatnia ksiazka od UML2.0.. nie pamietam tytulu.. przejrzalem sobie i po prostu beczalem z terminow :)

W pewnym momencie przychodzi taki moment, że głupie błędy poprawia się natychmiast po tym jak się zauważy, że coś jest nie tak. Ja tak obecnie mam, że mniej więcej połowa błędów wynika z tego, że używam jakiejś technologii (biblioteki, API), którą jeszcze niezbyt dobrze poznałem. Spora część pozostałych błędów to użeranie się z błędami w cudzym kodzie, w jakiś bibliotekach, serwerach aplikacyjnych itp. Jeśli chodzi o pozostałe błędy, to jak kod jest poprawnie zaprojektowany i stosuje się zasady KISS i DRY w połączeniu ze standardowymi wzorcami projektowymi, to nie ma bata, wyrafinowany (taki na 3 dni) błąd jest prawie niemożliwy do popełnienia. A proste wyłażą natychmiast w testach jednostkowych lub przy zwykłym, ręcznym sprawdzaniu programu. Stosowanie asercji też bardzo pomaga.

BTW. Mam okazję oceniać projekty studentów na pewnym wydziale politechnicznym i zauważam, że większosć błędów implementacji wynika z tego, że niektórzy mają tendencje do nadmiernego komplikowania kodu. W kilkudziesięciu zagnieżdżonych if-ach czy pętlach ciężko się połapać, a co dopiero znaleźć błąd.

DryKiss jak to niektorzy mowia :) jest ok, ale czasem prowadzi do napisania 200% kodu wiecej anizeli by to bylo potrzebne. poza tym niektorzy mowia ze takie suche to nie milo :) czasem czas stracony na napisanie czegos wymaga odpuszczenia sobie abstrakcji od detali i wykorzystania wlasnie faktu ze znamy detale i zalozenia do skrocenia roboty.. niemniej calkowicie sie zgadzam z w/w. jak mamy czas - powinno tak to sie robic, dzieki temu przygotowujemy sobie baze i mozna co raz czesciej korzsytac z tego co juz sie napisalo i zalozyc ze jest ono w 100% ok

taki off-top: KISS to keep it simple stupid, a co znaczy "DRY"?

// DRY - Q

@Krolik, znam conajmiej trzy przypadki błędów "ciekawych" i wyrafinowanych, które powstaną właśnie w trakcie zabawy ze wzorcami i DryKiss. Wszystkie dotyczyły nieprawidłowego podejścia w warstwie logiki biznesowej. Testy kodu pozwalają na wyłapanie około 50% błędów. Pozostałe 50% wynika z błędnych założeń biznesowych.

50% z biznesowych? to za lezy jak liczyc.. jesli za blad biznesowy przyjac wszystkie extra-wymagania jakie sie pojawiaja pomiedzy zakonceniem analizy a skonczeniem implementacji to bym zaryzykowal ze min 65% :)

KISS = Keep It Stupid Simple (..idiotycznie proste)
KISS (zlosliwie) = Keep It Simple, Stupid (..proste, glupku)

DRY = Don't Repeat Yourself

dodatkowe wymagania pojawiające się już w trakcie implementacji powodują jakieś 80% błędów. MI chodziło raczej o błędy wynikające z niespójności w dokumentacji i faktu że zazwyczaj nad niespójnymi kawałkami pracują różni ludzie. Wychodzą z założenia że dokumentacja jest wspólna i spójna więc piszą kod zgodnie ze swoimi założeniami. Następnie próbują to zintegrować i jak to się mówi qpaException i nikt nie umie powiedzieć co się stało.