Wylapywanie glupich bledow, jak sobie radzic.

0

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?
0
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..

0

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.

0

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.

0

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.

0

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.

0

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.

0
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.

0

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 :)

0
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 :-)

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0