Sposób Rozwiązywania zadań ze Spoja - 99% algorytmiki?

Question

Witam,

Spotkałem się z powiedzeniem, iż SPOJ to w głównej części algorytmika. Jeśli chciałbym umieć rozwiązywać zadania ze Spoju, czy powinienem zagłębiać się w struktury danych oraz algorytmy? Hmm, nom, brzmi banalnie, lecz chciałbym po pierwsze zapytać czy zgadzacie się z tą tezą o spoju oraz czy faktycznie warto ( czasami banalne pytania są najbardziej podchwytliwe ). 

Jeśli uważacie inaczej, podzielcie się własną opinią i ewentualnie napiszcie co Wam pomogło przy tym serwisie :)

Z góry dziękuję! 

Answer 1

Nie znam SPOJa ale gdy uczyłem się JS to sporo czasu spędzałem na codewars, są tam różne zadanka (w tamtym czasie głównie w JS), które dotyczą właśnie różnych problemów algorytmicznych, logicznych itp. I teraz, z perspektywy dłuższego już czas powiem Ci, że to nie jest takie super... Owszem, poznałem wiele elementów języka ale w pracy najczęściej wykorzystujesz zupełnie inną wiedzę...

Oczywiście, jesli wejdziesz np. w game dev no to takie rzeczy są istotne, ale jeśli myślisz o tworzeniu aplikacji typowego użytku to lepiej zrób inaczej - ogarnij sobie podstawy, tu jak najbardziej ten spoj pewnie jest spoko, ale daj sobie na to powiedzmy 2-3 miesiące max. Potem wymyśl sobie jakąś większą aplikację i zacznij ją pisać od podstaw. To da Ci znacznie więcej.

Wiele osób startujących na juniorów umie robić jakieś tam proste algorytmy i oklepane zadanka z neta, ale odpadają np. na kwestiach stworzenia kompleksowo jakieś aplikacji.

Comments

Rozumiem Twój widzenia. Sam uważam, iż tworzenie własnych aplikacji / projektów to najlepszy sposób nauki, ponieważ gdy chcemy coś zaimplementować (nawet coś czego nie mamy pojęcia jak to zrobić ) często uczymy się poprzez poznawanie nowych elementów / sposobów realizacji. Boli mnie jednak to, że jako (no jeszcze nie zawodowy) programista, potrafię wykonać różne programiki, ale ogranicza mnie to po pierwsze, że bazuje na tych samych elementach / rozwiązaniach. Po drugie - właśnie w takich serwisach jak SPOJ wychodzi moje prawdziwe oblicze -> potrafię posługiwać się składnią, no ale jak jest już trudniejsze zadanie, które nie wymaga strikte składni, lecz myślenia, umysłu analitycznego, nieszablonowego myślenia to już padam (myślę, że nie tylko ja tak mam, lecz bardzo wielu programistów - przynajmniej nie z zawodu). To czego naprawdę chce to wyrobić sobie nawyki dobrego myślenia, aby rozwiązywać zadania skomplikowane, takich który mało kto by umiał rozwiązać. Dla mnie w programowaniu nie liczy się samo klepanie kodu, lecz zachowywanie jasności umysłu oraz ćwiczenie go, bo nie ma znaczenia jakim językiem będę się posługiwał - czy oferuje więcej czy mniej narzędzi. Chodzi o to, aby mieć jak najlepiej rozwinięty problem solving bo w wielu przypadkach będzie mi się z takim czymś skonfrontować. Nie jestem pewien czy to dobrze napisałem, ale myślę, że również rozumiesz mój punkt widzenia.

---

Rozumiem Cię, pamiętam jeszcze swoje początki ale teraz, z perspektywy czasu widzę, że w moim wypadku zbyt długo bawiłem sie w takie codewars, algorytmy itp. Gdzieś w pewnym momencie zbyt mocno skupiałem się na tym, a nie na tworzeniu pełnych aplikacji.

Bo pamiętaj, że programowanie to nie tylko język i umiejętność samego kodowania. To również umiejętnosć planowania aplikacji, planowania rozwiązania róznych problemów, umiejętność pracy ze środowiskiem, np. w świecie JS i webu - umiejętność pracy z pakietami npm, webpack itp., ogarnianie gita... i tu też jest ciekawie... wiele, chyba z 99% juniorów twierdzi, że zna git i umie z niego korzystac, a potem okazuje się, że umieją tylko robić commity... Ba, nawet spotkałem przypadki, gdzie ludzie nie potrafili cofać się w zmianach git, robić złączeń między commitami itp. i ręcznie poprawiali zmiany tak, aby były jak wcześniejsze... :) Takie hasła jak git pull, push, rebase, stash, cherry-pick, checkout, reset itp. powinny być jasne dla każdego juniora.

Dam Ci prosty przykład, załóżmy, że tworzysz aplikację do sprzedawania ubrań na potrzeby sklepu w formie strony www (jestem webowcem, więc dam przykład webowy ale zasady są te same wszędzie). Nagle przychodzi szef i mowi, że jednak nie chcemy mieć tylko opcji kupowania pojedynczo, ale chcemy dodać opcję koszyka. I co teraz robisz? Jak do tego podchodzisz? Umiałbyś usiąść z nim i zaplanować jak ma to działać? Kilka banalnie prostych pytań:

• gdzie trzymamy dane z koszyka, client czy serwer?
• Jak długo ma być ważny koszyk
• kiedy i jak sprawdzamy dostępnosć produktów
• czy będziemy chcieli robić jakieś rabaty dla wielu sztuk?
• czy koszyk ma być tez dla niezalogowanych?\
• czy w koszyku mamy mieć możliwość zmiany ilości kupowanych przedmiotów?

itp. itd. takich pytań trzeba zadać milion zanim w ogóle zacznie się pisać :) I to jest właśnie różnica między programistą, a osobą, która zna składnię i umie wyznaczyć n-ty wyraz fibbonaciego... Umiejętność analizowania aplikacji w szerszym ujęciu i do tego dopasowywania rozwiązań. Nie jest problemem dodać endpoint dla usuwania przedmiotu z koszyka, ale problemem jest dobre omówienie logiki kiedy, jak i kto może robić taką operację.

Jak zaczniesz pisać dowolną większą swoją apkę to sam zobaczysz, że napotkasz wiele takich właśnie drobnych problemów, które czasami potrafią wywrócić do góry nogami cały pomysł na jakąś implementację :)

---

Haha, świetnie to opisałeś. Postaram się balansować umiejętności programistyczne. Dzięki wielkie za pomoc :)