Pisze w Javie - ogólnie to się uczę i staram się rozwiązywac zadania z CodeWars, Code f Advent czy HackersRank. Czesto jak coś napisze, to za pierwszym razem nie działa, więc musze właczyć debugera i prześledzić zmienne, żeby obczaić że w jakimś warunku coś nie działa - póxniej tak poprawiam kod kilka razy. Czy to jest normalne? Czy można sie jakos nauczyć przeiwdywać co będzie się działo w programie tak żeby nie robić tyle błędów?
0
0
Jak być dobrym w pisaniu kodu?
Ćwiczyć. Dużo ćwiczyć.
2
@DarkoZZZ Testy jednostkowe się pisze i gra gitara.
13
To jest normalne. To jest tak bardzo normalne, że nawet swego czasu krążył mem że jeśli coś działa za pierwszym razem to na 100% coś jest nie tak i wyjdzie na produkcji.
1
Trochę z innej beczki. Nie bez powodu TDD ma najpierw RED, potem Green.
Jak działa od razu to ja bym się zastanowił gdzie robię błąd.
Im większa wprawa tym głupsze błędy. Rutyna też daje znać o sobie.
13
pisz male, wyspecjalizowane obiekty i funkcje. redukuj mutowalny stan. pewnie da ci to tak 90% bledow mniej juz na etapie kodowania a i testowanie bedzie latwiejsze.
0
Nie wiem jak inni, ale jak mi kod zadziała za pierwszym razem to podchodzę do niego bardzo podejrzliwie. Kiedyś miałem taką sytuację, że pisałem kod przez ~2h bez uruchamiania. Po uruchomieniu wyskoczył jakiś drobny warning i potem już wszystko działało... Następne 20 minut przeglądałem debuggerem czy na pewno działa ;-)
0
hadwao napisał(a):
Po uruchomieniu wyskoczył jakiś drobny warning i potem już wszystko działało... Następne 20 minut przeglądałem debuggerem czy na pewno działa ;-)
Zrobisz następną drobną zmianę, bo wyszła dopiero po czasie, znowu 20 albo 30 minut z debuggerem czy teraz też działa.
W tym momencie do drzwi pukają testy i proponują współpracę.
Bywa, że produkt żyje aktywnie 10 lat i bez przerwy wchodzą drobne zmiany.
0
A jak się uczyć algorytmiki, bo same książki chyba nie wystarczą - tak żeby dużo pisać i uczyc się od innych? Czy sa jakieś fora gdzie wspólnie rozwiązuje się wyzwania itp?
0
Spoko, bez spiny. Te typowe 2 semestry ASD, zaliczenia, laborki, egzamin wystarczą. Dalej już ewentualnie w pracy.
0
Tylko że ja już nie jestem na studiach, ale w pracy :) Studiowałem jakies 15 lat temu to tylko było sortowanie bąbelkowe, stosy itp. A poetm 12 lat przepracowane jako analityk biznesowy więc co najwyżej SQL i 3 lata jako architekt integracji. A programować chcę się uczyć po to że widziałem że znając Javę mogę więcej wycisnąć z szyny danaych którą używam w pracy. A jak już się zacząłem uczyć Javy, to mi się programowanie spodobało i chciałbym wiedzieć więcej niż potrzebuję do pracy :)
0
Weź sobie jakiś kurs ASD (algorytmy & struktury danych), byle nie Ważniak na początek ;) i leć z materiałem.
Nie bierz się za Cormen bo sorry za szczerość, nie przerobisz go. Ustal sobie plan nauki na 2 m-ce. Zrobisz plan W CAŁOŚCI w 4 to będzie dobrze. Później ewentualnie uzupełniaj wiedzę kiedy już zrobisz typowe ASD w wersji light. 2 iteracje nauki ASD będą lepsze dla ciebie od jednej dużej.
0
Przestań używać debuggera na codzień - spowoduje to że będziesz przykładał o wiele większą wagę do logów które dają jakiekolwiek informacje. Zamiast pisać implementacje funkcjonalności, zacznij od przekształceń typów jakie w nich będą następować. Jak spinają się typy, zacznij pisać funkcjonalność. W dużej mierze może pomóc zredukować całkiem sporą liczbę błędów
0
DarkoZZZ napisał(a):
Pisze w Javie - ogólnie to się uczę i staram się rozwiązywac zadania z CodeWars, Code f Advent czy HackersRank. Czesto jak coś napisze, to za pierwszym razem nie działa, więc musze właczyć debugera i prześledzić zmienne, żeby obczaić że w jakimś warunku coś nie działa
Może za rzadko odpalasz program? Jeśli piszesz dużo kodu naraz i odpalasz program dopiero, jak skończysz cały, to bardzo prawdopodobne, że będziesz miał pełno błędów i że będziesz musiał ich szukać debuggerem.
Jakbyś odpalał program po zmianie każdej głupoty, to byś nie miał tylu błędów naraz (np. dodajesz warunek? To włączasz od nowa program i sprawdzasz, czy warunek działa, robisz jakiegoś printa/loga, czy co tam macie w tych Javach. Jak nie działa, to nie musisz włączać debuggera, tylko patrzysz na ten warunek i zmieniasz).
Innymi słowy co chwila uruchamiasz program i sprawdzasz, czy każda pierdółka działa.
Czyli bardziej opłaca się testować manualnie zamiast manualnie debugować.
Żeby to jednak zautomatyzować, możesz pisać kod w paradygmacie TDD. Czyli piszesz test jednostkowy, potem implementację do tego testu, potem kolejny test, i kolejną implementację. I tak w kółko. Wtedy jak coś nie działa, to często widzisz już, że coś jest źle po tym, który test nie przechodzi, a które przechodzą.
- póxniej tak poprawiam kod kilka razy.
Nie ma w tym złego, ani dziwnego.
żeby nie robić tyle błędów?
Robienie błędów jest ok i nie to jest problemem. Raczej problem zaczyna się wtedy, kiedy nie wiesz gdzie znajduje się błąd. Jak . Czyli debuggowanie jest problemem. Albo jeszcze gorzej - jeśli nie wiesz, że jakiś błąd istnieje. Wtedy twój program zawiera jakiś ukryty błąd.
Dlatego lepiej programować iteracyjnie, czyli zmieniać jedną rzecz naraz i odpalić i sprawdzić czy ta rzecz działa. A dopiero potem dopiero kolejną.
Czy można sie jakos nauczyć przeiwdywać co będzie się działo w programie tak żeby nie robić tyle błędów
To już jest inne pytanie. Przewidywanie nie uchroni przed wszystkimi błędami (np. możesz pomylić plus z minusem czy zrobić inną literówkę), z drugiej strony nie zawsze błąd jest błędem, bo program może mieć jakąś wadę, która nie musi być błędem, a być po prostu jakąś wadą, ograniczeniem. Poza tym nawet typowe błędy nie zawsze się ujawniają, bo niektóre się ujawniają tylko w specyficznych okolicznościach, np. po jakiejś akcji użytkownika.
Tylko wyszukiwanie "edge case'ów" to już głębsza sprawa, wymaga to z jednej strony myślenia za każdym razem "co może pójść nie tak" , z drugiej strony doświadczenia *, a z trzeciej strony podejścia eksploracyjnego - np. możesz "bawić się programem", czyli włączasz i klikasz bez sensu (jak prawdziwy użytkownik) próbując go "zepsuć". Wtedy istnieje nadzieja, że wykryjesz jakieś niewidzialne wcześniej bugi. Podobnie kodem można się bawić. Zmieniać dla zabawy jakieś linijki i zobaczyć czy przestanie działać, albo co się stanie generalnie.
* (bo pewnych rzeczy nie jesteś w stanie przewidzieć, dopóki ich nie doświadczysz. I dopiero potem będziesz w stanie na podstawie swojego doświadczenia myśleć szerzej o programie. Poza tym żeby naprawdę wyeliminować błędy, to i tak musisz raczej wypuścić program w świat i zebrać feedback od prawdziwych użytkowników, którzy będą go odpalać "po swojemu" na swoich urządzeniach. I wtedy znajdą błędy, o których w ogóle byś nie pomyślał. Tak jak ilustruje to ten tweet https://twitter.com/brenankeller/status/1068615953989087232 )
2
DarkoZZZ napisał(a):
Tylko że ja już nie jestem na studiach, ale w pracy :) Studiowałem jakies 15 lat temu to tylko było sortowanie bąbelkowe, stosy itp. A poetm 12 lat przepracowane jako analityk biznesowy więc co najwyżej SQL i 3 lata jako architekt integracji. A programować chcę się uczyć po to że widziałem że znając Javę mogę więcej wycisnąć z szyny danaych którą używam w pracy. A jak już się zacząłem uczyć Javy, to mi się programowanie spodobało i chciałbym wiedzieć więcej niż potrzebuję do pracy :)
Te stosy i sortowania plus grafy (grafy, grafy i jeszcze raz grafy) to miecz potężniejszy niż się wielu studentom wydaje. Pisanie jakichś poważniejszych botów w FPSach, czy AI w RTS trudno na poważnie zrobić bez grafów, minimalnego drzewa rozpinającego czy szukania najkrótszej ścieżki w grafie. Grafy są też strasznie pomocne w generowaniu losowych poziomów w grach. Oczywiście ma to też przełożenie na inne dziedziny poza gamedev. Odśwież sobie materiał - na necie są materiały z różnych uczelni gdzie idzie się zorientować jakie algo i struktury są omawiane. A no i strona pewnego Tarnowskiego liceum. ;)
0
Pytanie po co? Jesteś podróżnikiem z przeszłości gdzie dostajesz 120sekund pracy maszyny na dzień a jak przekroczysz czas albo karta perforowana ma błąd to haltują proces? Ja rzadko kiedy coś napisze co za pierwszym razie się kompiluje. Jeszcze rzadziej jeśli za pierwszym razem działa zgodnie z założeniami i logika. Na prawdę prawie nigdy wychodzi kod zgodny z zamierzona architektura i ładnymi wzorcami. Zazwyczaj wychodzi pół spaghetii, które po 10 poprawkach się skompilowało, po 2h działa jak należy a i tak tester znajdzie jakieś 2-3 chore ścieżki, które wygenerują błąd. To normalny proces wytwórczy oprogramowania. Szkolenie się, żeby kompilator nie wypluwał błędów to błędny cel - celem powinno być dostarczenie finalnie bezbłędnego oprogramowania o to w miarę szybko.