Wyjaśnienie procesu programowania na podstawie moich błędów w kodzie.

pytanie zadane 5 września 2016 w JavaScript przez nowa Początkujący (450 p.)

Hej :) Z góry zaznaczę, że nie umieściłam tego postu w dziale "projekty" bo 1)to nie jest skończony projekt 2)nie oczekuję ocen co do podobania się bo niektóre nie działają.

O co mi chodzi więc?

Uczę się programować w JavaScript, a by było radośniej dla mnie moja główna forma nauki to tworzenie Ponga. Niestety znajdowanie rozwiązań nie idzie mi zbyt dobrze (znajduje rozwiązanie, ale potem okazuje się że inne rzeczy przestają działać, a potem z kolei w pewnym momencie "poprawiając kod" zmieniam całkowicie te fragmenty i pojawiają się inne problemy) więc byłoby super poznać wasz sposób myślenia przy projektowaniu rozwiązań i naprawianiu błędów. Jeszcze do tego tworząc wasze przykłady oparte na grze Pong/na moich błędach w kodzie - ideał :)

Druga rzecz która okazałaby się dla mnie bardzo pomocna to wyjaśnienie w jaki sposób mogłabym używać jednej funkcji do prawie identycznych zadań. Teorie jako tako znam, ale nie potrafię tego stosować w praktyce pisząc własne funkcje.

Trzecia rzecz to wyjaśnienie w jakiej kolejności powinno się umieszczać różne funkcje, ify itp. Pod koniec pisania kodu zaczęłam umieszczać fragmenty kodu gdzie byłoby wygodniej dla mnie. Przy okazji.. kod w niektórych miejscach wygląda inaczej bo ciągle się uczę, próbuję i zmieniam sposób pisania kodu i mojego myślenia o programowaniu.

Czwarta rzecz to wyjaśnienie powodu dla którego w funkcji naliczającej punkty następuje błąd. Punkty są mnożone przez czas usypiania funkcji czego kompletnie nie rozumiem :(

Z góry dziękuję tym którzy przebrnęli za mój zalew(jakoś to dziwnie brzmi :D) pytań i tym którzy będą mieli ochotę mi pomóc :) Nie chcę przepisywać kodu nie myśląc przy tym więc gdyby ktoś narzekał... o to powód dlaczego moje pytania są dosyć ogólne ;p

link do strony z grą: https://nooowa.github.io/My-version-Pong-game/

link do plików z kodem: https://github.com/nOoOwA/My-version-Pong-game

komentarz 5 września 2016 przez jpacanowski VIP (101,940 p.)
edycja 5 września 2016 przez jpacanowski

Polecam video tutorial Kursownik.pl - po jego obejrzeniu opanujesz język JavaScript na dość przyzwoitym poziomie. A w czasie kursu stworzysz takie gry jak Asteroids czy Bomberman. https://kursownik.pl/kursy/html5_canvas/

Korzystaj lepiej z requestAnimationFrame(), zamiast z setInterval()
https://youtu.be/vZ7ub0zNYUA

Pong mi się podoba i daję plus ;) Widzę, że niewiele z tego tutoriala potrzebujesz, ale coś tam ciekawego pewnie wyciągniesz, np. jak z tym requestAnimationFrame()... :D

komentarz 5 września 2016 przez nowa Początkujący (450 p.)

Dziękuję za link :)

komentarz 5 września 2016 przez jpacanowski VIP (101,940 p.)

Edytowałem komentarz ;)

2 odpowiedzi

odpowiedź 6 września 2016 przez uRTLy Bywalec (2,420 p.)
wybrane 6 września 2016 przez nowa

Najlepsza

Jeśli jesteś naprawdę początkująca to szczerze odradzam zabieranie się za pisanie testów - ja rozumiem że to jest ważne ale lepiej poznać bdb język i framework o ile używasz, niż poświęcać więcej czasu na wymyślenie i zakodowanie prawidłowego, sensownego testu . Na początku faktycznie twój kod będzie porozrzucany w różnych miejscach i usuwany kilkukrotnie, ale testy temu nie zapobiegną - z reguły oprócz usuwania twojego kodu będziesz też usuwała testy za niego odpowiedzialne.

Ciśnij wszystkie wątpliwe wyniki ( albo takie które powinnaś uzyskać ) w console.logi - zaoszczędzisz na początku więcej czasu i szybciej rozwiążesz problem. Używaj ich mnóstwo.

Co do problemu z usuwaniem - no cóż, tego sposobu myślenia sama się nauczysz kodując coraz więcej i więcej. Co do używania jednej funkcji do identycznych zadań to na początek możesz spróbować podawać do niej np dodatkowy argument podczas wywoływania tej funkcji w określonym miejscu. Zrobić w niej if'a na początku i sprawdzić który kod wykonać - pod warunkiem argument mówi po co jest - tzn jest fajnie nazwany. Ogólnie to wydaje mi się że to jest bardziej problem architektury aplikacji, więc możesz to na razie tak obchodzić.

Powinnaś za pierwszym razem zrobić tę apkę tak żeby w ogóle działała, a potem refaktoryzować kod na lepiej napisany, ładniejszy albo mniejszy. Spróbuj np skrócić ilośc lini kodu, spróbować do problemu podejść mądrzej , podzielić go bardziej na części, włożyc niejasne if'y / jakiekolwiek warunki do fajnie nazwanych zmiennych albo funkcjii. To ci ułatwi pisanie kodu.Ogólnie twoim celem jest zbudować działającą aplikację z klocków - a nimi są funkcje. Divide and conquer.

Użyj do tego np kartek na których zapiszesz twój proces myślowy ( za każdym razem analizuj kilka razy czy ten krok jest potrzebny, czy apka nie robi czegoś na około)

A i żeby nie było - testy są naprawdę ważne - ale jeżeli się dopiero uczysz to pierd... to ;).

komentarz 6 września 2016 przez event15 Szeryf (93,790 p.)

Pozwoliłem sobie przywrócić ten komentarz, ponieważ niesamowicie ciekawą dyskusję mozna podjąć.

Twórca TDD - Kent Beck a następnie cała ekipka od XP i Agile mówią zupełnie inne rzeczy na temat testowania w porównaniu z Tobą.

Przede wszystkim test powinien być prosty, mały, wcale nie musi zajmować dużo czasu. W testowaniu typu test-first chodzi głównie o przyspieszenie pracy z rozwojem programu. Z początku wygląda to bardzo mozolnie i wolno. Człowiek pisze teścik, następnie pisze do tego działający kod (test decyduje o tym, czy to działa, czy nie). Następnie powtarza to - po jakimś czasie robi malutką refaktoryzację. Dopiero po osiągnięciu pewnego etapu rozwoju człowiek zauważa niesamowite tempo powstawania aplikacji, która ma co najmniej 80% pokrycia w testach - a więc i daje pewność w działaniu (pomijając profesjonalne testy tworzone przez zaowodowych testerów).

No i trzeba z góry powiedzieć, że w przypadku programowania jak pisze się o testach to ma się na myśli proces tworzenia. To nie jest proces debugowania i sprawdzania wszystkich możliwości wykiwania aplikacji. To nie testy A\B czy regresyjne. Tu chodzi o metodę małych kroków które dokumentuje się każdym zielonym testem.

Inna sprawa, że pisanie testów nie jest taką straszną rzeczą dla początkującego, a niektóre rodzaje testowania pomagają skutecznie i bardzo szybko nauczyć się podstaw pięknego projektowania kodu. Cały proces masz pod kontrolą i w momencie testu wiesz jak chcesz by aplikacja była zaprojektowana.

Kartki to zupełnie dodatkowa pomoc w tworzeniu aplikacji.

komentarz 6 września 2016 przez nowa Początkujący (450 p.)

Event15 a znasz może jakieś dobre źródła, które wyjaśniają testy o których piszesz, ale nie tylko suchą teorie, ale też wyjaśniają sposób myślowy który powinien zachodzić podczas pisania takich testów?

Pytanie dodatkowe :D : czy przy początkach programowania też były tworzone testy? Szczerze mówiąc trudno mi sobie to wyobrazić. Jeśli nie to jak wyglądało? Występował tylko pseudokod do pomocy w programowaniu?

Najlepsza odpowiedź poszła do Bywalca bo zaznaczyć was obu nie mogę niestety :D

komentarz 6 września 2016 przez event15 Szeryf (93,790 p.)

Możesz o testach ogólnie przeczytać w:

xUnit Test Patterns - Gerard Meszaros (The Addison-Wesley Signature Series)
Software Testing. Concepts and Operations - Ali Mili (John Wiley & Sons 2015)
TDD - Kent Beck
Testy jednostkowe. Świat niezawodnych aplikacji. Wydanie II - Roy Osherove
Growing Object-Oriented Software Guided by Tests - Steve Freeman (The Addison-Wesley Signature Series)

Przy czym bardzo polecam Kenta Becka oraz Roya Osherove.

Tak wygląda TDD Kata w PHP:

https://vimeo.com/151998091

Nie potrafię zbytnio pomóc jeżeli chodzi o testowanie w JavaScript - aczkolwiek z tym możesz uderzać śmiało do @Comandeera.

komentarz 7 września 2016 przez uRTLy Bywalec (2,420 p.)
edycja 7 września 2016 przez uRTLy

ogólnie myślę tak o testach bo sam miałem i mam takie problemy i mimo że pisze w Angularze - podobno idealnym do testowania to dalej tego robić nie umiem...,Wciąż jestem na etapie głębokiego poznawania go i wpadam w te błędne koło o którym pisze - mam kilka różnych pomysłów jak to zrobić inaczej/ bardziej angular-way więc usuwam wszystko łącznie z testami i lecę od nowa. Przyznam - testowanie naprawdę mnie męczy i klepie mózg.

Dlatego zaproponowałem odpuszczenie testów bo będąc zupełnie niedawno na tym samym etapie co Ty - wiem jak ciężko napisać coś co nie robi czegoś "przy okazji", coś co jest pure function i zostanie w twoim kodzie dłużej niż pierwszy krzyk lintera o brak średnika ( Linter - używasz ? Też może być badzo pomocne narzędzie - nalegam abyś używała ) .

Koniec końców testując od początku na pewno wiele zyskasz.

Btw. właśnie dlatego to ukryłem bo nie chciałem komuś podpaść za to twierdzenie o testach.

komentarz 7 września 2016 przez event15 Szeryf (93,790 p.)

ogólnie myślę tak o testach bo sam miałem i mam takie problemy i mimo że pisze w Angularze - podobno idealnym do testowania to dalej tego robić nie umiem...

Roy Osherove w swojej książce właśnie o tym pisze. Nauka testowania i zmiana myślenia o tworzeniu oprogramowania z początku nie są szybkie i proste. Człowiek analizuje zbyt wiele przypadków i boi się że wszystko robi źle. Prawda jest taka że to tylko proces dla programisty i wcale nie musisz testować wszystkich możliwości. Od dokładniejszych testów są profesjonalni testerzy. Nie testuje się też wszystkich metod. Wyłącznie te, które wykonują jakąś jednostkę pracy. Tak jak na moim filmie każdy test sprawdzał odpowiednio różne etapy działania programu. Aczkolwiek na filmie jest Kata, więc do programu o jednej funkcjonalności pisze się dużo więcej testów niż w realnym życiu ma to miejsce.

Nie rozumiem czemu usuwasz wszystko łącznie z testami? Testy pisze sie tylko raz a później one zawsze są prawdziwe. Nie ma wymogu, aby kod testów jednostkowych był idealnie czysty jak kod produkcyjny. Wystarczy, że testy spełnią swoje zadanie.

odpowiedź 5 września 2016 przez Comandeer Guru (602,310 p.)

znajduje rozwiązanie, ale potem okazuje się że inne rzeczy przestają działać, a potem z kolei w pewnym momencie "poprawiając kod" zmieniam całkowicie te fragmenty i pojawiają się inne problemy

Pierwsze skojarzenie: ewidentny brak testów ;) To podstawowa umiejętność, która równocześnie od razu wpłynie na sposób, w jaki będziesz pisała kod.

komentarz 5 września 2016 przez nowa Początkujący (450 p.)

Dziękuję za odpowiedź i od razu się dopytam: czy formy testów zawsze muszą być takie same (słyszałam, że jest ich parę rodzajów) i czy musi być ich też kilka typów a może wystarczy jeden, który wykaże że to co chcemy napisać działa w teorii(?)

Ps.Zrobiłam test (sama wymyśliłam formę więc dlatego mogło nie wykazać błędu) do funkcji która zawiera też naliczanie punktów i odłączona od reszty działa. Masz może pomysł jaki test mogę zastosować do tej funkcji by znaleźć problem?

komentarz 5 września 2016 przez Comandeer Guru (602,310 p.)

W JS najpopularniejsza jest forma obecna np. w Mocha czy Jasmine, czyli:

describe( 'Co testujemy', () => {
    it( 'co ma robić', () => {
        // Konkretny test.
    } );
} );

// Takich grup describe może być więcej.

Ogólnie to testy są jednostkowe i inne (integracyjne, E2E). Najwięcej napiszesz testów jednostkowych. To są testy, które sprawdzają, czy konkretna funkcja działa tak jak powinna. Wyżej są testy integracyjne, które sprawdzają jak działają różne cześci systemu razem. E2E to takie "testy użytkownika", czyli automatycznie robią to, co user by robił w aplikacji i sprawdzają, czy nie wywala błędów.

A co do testu: najpierw wydziel samo dodawanie punktów do osobnej funkcji. Wówczas będziesz w stanie sprawdzić, czy samo dodawanie punktów działa jak należy i będziesz mogła już w prostszy sposób ustalić, w którym momencie coś się krzaczy ;)

komentarz 6 września 2016 przez nowa Początkujący (450 p.)

Dopiero teraz zauważyłam tą odpowiedź :( Mam zaznaczać najlepsze odpowiedzi/pomocne i człowiek aż czuje jakąś dziwną presję :D W każdym razie chciałam podziękować za odpowiedź :) Jak dziś dam radę napiszę swój pierwszy "profesjonalny" test do funkcji :)