Witam.
Aktualnie uczę się podstaw języka z zamiarem osiągnięcia pracy na stanowisku Junior C++ w ciągu max 2 lat (im szybciej tym lepiej).
Korzystam głównie z książki Szkoła programowania C++ i mam do Was pytanie. Jak się uczycie? Staram się ogarnąć teraz typy złożone i podstawy zarządzania pamięcią,.
Czy lepiej przećwiczyć teraz typy złożone, których stosowania jeszcze nie do końca ogarniam (szczególnie wskaźników) czy może lepiej przelecieć podstawy C++ i robić tylko ćwiczenia z książki, a nad dokładnym zrozumieniem i przećwiczeniem tego przysiąść jak już np. dojdę do jakiegoś późniejszego etapu i wtedy ćwiczyć porządnie wszystko na raz?
Pozornie bezsensowne pytanie, ale kiedy człowiek umie nawet trochę, ale różne zagadnienia to później czasem łatwiej jest nauczyć się tych wcześniejszych i wydają się absurdalnie proste (przynajmniej z tego co się w szkole działo tak wnioskuję).
Ja teraz uczę się od podstaw nowego języka. Co prawda nie C++, a Haskella. Suche przeglądanie materiałów w internecie do nikąd mnie nie prowadziło więc zacząłem pisać interpreter Brainfucka. W tej chwili mam napisany Interpreter Brainfucka i Whitespace, ale dalej nie czuję żebym umiał Haskella. Muszę napisać coś jeszcze większego
Chyba sposób nauki zależy od człowieka. Jeden obejrzy kurs i sporo zostanie mu w głowie, a inny po przeczytaniu 5 książek nadal nie będzie nic umiał.
Z programowaniem jest też tak, że ile byś o tym nie przeczytał to dopóki nie spróbujesz czegoś napisać to nie zostanie Ci to w głowie, ani tego tak naprawdę nie zrozumiesz.
Myśle, że robienie zadań z książki + jakieś zadania ze stron typu SPOJ czy codewars to dobry mix.
No i jak zawsze wszyscy mówią - najwięcej nauczysz się robiąc coś co jest ci potrzebne. To mogą być małe rzeczy na początek jak jakiś timer czy sprawdzanie daty, później może być coś większego np. Komunikator.
Jak będziesz się uczyć takimi sztucznymi etapami na zasadzie "teraz uczę się co to wskaźniki a za miesiąc piłuję klasy", to pewnie zdążysz zapomnieć pierwsze nim opanujesz drugie i będziesz mógł ćwiczyć "wszystko naraz" ;)
Nie mówiąc już o tym, że właściwie to według jakich konkretnie kryteriów chciałbyś oceniać, czy już opanowałeś dane zagadnienie czy jednak musisz to jeszcze ćwiczyć zanim pójdziesz dalej?
Z perspektywy czasu, nauka "po kolei" i "z książki" gdy coś tam próbowałem się naumieć w pierwszym języku była straszną stratą czasu i przebiegała delikatnie mówiąc niezbyt efektywnie. Zachęca do kurczowego trzymania się pewnych rozwiązań, żeby obejść te do których "jeszcze się nie dotarło", a stąd już prosta droga do jakichś niekoniecznie dobrych nawyków. Teraz jak chcę / muszę użyć do czegoś języka którego za bardzo nie znam, to raczej poczytam z czym się go je, jak wygląda składnia, jakie ogólnie ma możliwości, a zamiast jakichś sztucznych ćwiczeń po prostu zaczynam realizować to, co akurat mam do zrealizowania - w praniu wychodzi, jakie muszą być następne kroki w nauce, dochodzi do zrewidowania dotychczasowej wiedzy która mogła okazać się błędna albo nieaktualna itd.
ucze sie teraz rosyjskiego i chinskiego, mam nadzieje za pare lat wyjechac do chin pracowac nad oprogramowaniem do handlu algorytmicznego jak to robi jedna z uzytkowniczek, @katelx chyba
Skoro myślisz o normalnej pracy, to trochę przewrotnie zacząłbym od trochę innego aspektu. Na początek opanuj jakiś system kontroli wersji. Cokolwiek - Git, SVN, etc. Zobaczysz, szybko zacznie to procentować. Możesz to robić równolegle z poznawaniem języka :) Co do nauki samego języka, to weź na początek jakiś prosty tutorial. Dzięki temu szybko skonfigurujesz środowisko do pracy. Odpalisz pierwszego hello world'a. Minie pierwsze zagubienie. A potem mogę tylko zacytować przedmówczynię - Sandrę. Najwięcej nauczysz się pisząc swój projekt. Nie bierz się od razu za książki, zwłaszcza te, które przypominają dokumentację języka. Szybko możesz poczuć zniechęcenie od nadmiaru nowych treści, które w dodatku niekoniecznie są przydatne na początku. Niemniej nie należy ich całkiem skreślać. Bardzo dobrze pomagają standaryzować wiedzę jak już człowiek napisze trochę kodu i rozbije się o kilka problemów :)
@TheRottenCookie Przy pierwszym języku sprawa jest mega prosta. Bierzesz porządną książkę napisaną fajnym językiem i lecisz od początku do końca przepisując przykład za przykładem, czytając objaśnienia kodu, psując te przykłady, dodając coś do siebie, uruchamiając modyfikacje w nieskończoność etc.
W przypadku następnego języka -> otwierasz dokumentację/tutorial/książkę prowadzącą po języku i czytasz pisząc co Ci do głowy przyjdzie. Nowy język porównujesz ze starym, bo znasz już klasy, funkcje, metody, tablice, pętle, typy danych, zwracanie itd.
Zasada jest taka. Nauczyć się jednego bardzo dobrze, a następny przyswoisz względnie szybko i bezboleśnie*
*Z pewnymi wyjątkami jak np. czysto funkcyjne paradygmaty.
Moim zdaniem lecąc z książki przykład za przykładem czy przerabiając jakiś tutorial jedyne czego się nauczysz to przepisywania z książki. A po skończeniu tutoriala / książki nagle jest stop i pytanie "co dalej?" - nagle nikt nie ciągnie za rączkę i nawet nie wiadomo czego szukać żeby się dalej "rozwijać". Więc bierzesz drugi tutorial albo książkę i znowu lecisz od deski do deski - 90% treści się powtarza, ale to nic bo zdążyłeś większości zapomnieć.
Jak chcesz się nauczyć naprawdę to po prostu zacznij programować. Tak po prostu bez uczenia się. Wymyśl jaki program chciałbyś stworzyć i spróbuj go zrobić. Ja dopiero po napisaniu kilku programików po paru dniach dowiedziałem się czym jest tablica, nie dlatego że natrafiłem na taki rozdział tylko dlatego że jej potrzebowałem.
Nauczysz się dzielenia problemu na mniejsze, szukania rozwiązania problemów, zadawania pytań. Nauczysz się gdzie sięgać po informacje, dokumentację, porady i wskazówki i gdzie znaleźć informacje o nowinkach. Myśl jakbyś chciał napisać książkę o programowaniu a nie ją przeczytać.
Oczywiście podstawy warto znać, najlepiej po rozwiązaniu problemu, poszukać innych rozwiązań i jak się to powinno zrobić poprawnie. Często przy rozwiązaniu opisywane są problemy o których nawet nie wiesz że mogą się pojawić - wtedy czytasz to rozwiązanie bez większego zrozumienia o czym mowa. Dużo lepiej najpierw natrafić na problem, a później przeczytać rozwiązanie.
Możesz te dwa lata spędzić na czytaniu książek, albo pół roku na programowaniu i szybkim przejrzeniu książki w celu uzupełnienia braków - zgadnij które podejście będzie ciekawsze i skuteczniejsze.
obscurity napisał(a):
Jak chcesz się nauczyć naprawdę to po prostu zacznij programować. Tak po prostu bez uczenia się. Wymyśl jaki program chciałbyś stworzyć i spróbuj go zrobić. Nauczysz się dzielenia problemu na mniejsze, szukania rozwiązania problemów, zadawania pytań. Nauczysz się gdzie sięgać po informacje, dokumentację, porady i wskazówki i gdzie znaleźć informacje o nowinkach.
Chciałbym to zobaczyć jak ktoś kto w życiu nie programował siada i pisze program. Czytałem już dziesiątki takich mędrców, którzy mówili:
- Krzychu! Kadetem tera!
Krzychu siadał i nie wiedział co ma tym Kadetem robić. Nie da się pisać bez znajomości języka. Wystarczy do przerabiania książki dorzucić po rozdziale-dwóch pisanie drobnych programów. Zresztą dobre książki po każdym rozdziale mają listę zadań do zrobienia samemu w celu utrwalenia wiedzy. Ogarnięcie tpodstawowych typów, jednej pętli, warunku i już coś wyrzeźbi. A to jest pewnie kwestia dwóch działów.
Moj system polega na wyznaczeniu sobie rozwiazania ktore chce osiagnac. Nie cierpie uczyc sie stopniowo, czyli tak jak @superdurszlak napisal - dzisiaj metody, jutro klasy za tydzien programowanie generyczne itp. Kazdy jednak musi znalezc swoj system i z niego korzystac. Wracajac do mnie: 1. Zajawka na projekt (co chcesz osiagnac i czy rzeczywiscie jest Ci to potrzebne), 2. Wybor technologi, 3. Research konkretnych rzeczy potrzebnych do osiagniecia zalozonego rozwiazania. Kiedy jestes ciekawy czegos i z wlasnej inicjatywy szukasz konkretnych rzeczy, to praktycznie wchloniesz 100%.
Podam na przykładzie Rusta (to mój 5-ty język na poważnie):
-
Na początku czytam oficjalne (jak są i są oczywiście polecane) materiały tak od deski do deski, porównuję z konceptami z innych języków programowania, w przypadku Rusta był to oczywiście oficjalny rust-book, może też inne strony lub tutoriale na YT (generalnie to nauka "na sucho")
-
Po etapie "wysiadywania" w punkcie poprzednim przechodzę dalej i piszę prosty projekt w danym języku, serwer oraz klient API w JSON, który:
- musi zostać "rozczłonkowany" na wiele plików, dzięki czemu poznaję moduły/pakiety w języku, w jaki sposób eksponuje się zmienne/metody/moduły itp. Tworzę prostego liba/package/crate, które sam sobie muszę później użyć w swoim projekcie.
- musi używać 3rd party libów, abym mógł je dołączyć do swojego projektu zgodnie ze sztuką w danym języku i zaczął używać
- musi "obsługiwać" testy jednostkowe, co oznacza konieczność (w miarę możliwości) pisania "czystych" funkcji oraz jakiegoś wstrzykiwania DI zgodnego ze sztuką w danym języku (to często mi psuje krew przy przy nauce nowych języków, bo co język, to nowe udziwnienia i podejścia do tego zagadnienia)
- w miarę staram się używać system typów restrykcyjnie, aby nie nadużywać typów zbyt ogólnych (przykład:
interface{}z Go) - musi mieć różnopoziomowe logowanie typu DEBUG, INFO, etc - oczywiście staram się to implementować na bieżąco i sprawdzać, czy się przydaje
- musi obsługiwać minimalną wielowątkowość z jakąś minimalnymi mechanizmami synchronizacji: chodzi o to, aby spróbować konceptów danego języka i sprawdzić jak w nich to funkcjonuje. Zazwyczaj w projekcie to sprowadza się do jakiegoś jednoczesnego odpytywania kilku API na raz i "synchronizacji" wyników i ich procesowania. Żaden rocket science.
- musi zapisywać coś do pliku i korzystać z tego (jakieś szczątkowe dane)
- oczywiście muszę zrobić prosty deploy
- Z ważniejszych rzeczy jeszcze:
-
staram się zrobić od napisania 1 linii po deploy takiej apki, czyli cały proces, choćby lokalnie, w tym próbuję np. robić creates/packages (Rust/Go), które są na 3rd party lokalizacji (zazwyczaj jakaś wirtualka u mnie) i muszę "przekonfigurować" package management, by z nich korzystać. To się często przydaje w prawdziwych projektach, gdzie repa z kodem "wrażliwym" są gdzieś pochowane za jakimś tajemnicztmi vpnami/proxy i zwykłe
cargo build/go get/pip installich prosto nie pobierze. -
próbuję sobie zrobić prosty Dockerfile z kompilacją mojej apki z custom repo, aby zobaczyć jakie hece wyjdą w trakcie budowania obrazu, czasem wychodzą jakieś "nowinki" w stosunku do baremetal np: kompilacja projektu w Go, na obrazie alpine (szło o musl o ile pamiętam). Oczywiście tworzę też prosty
docker-composez potrzebnymi usługami, by dało się na szybko postawić całość 1 komendą. -
finalnie próbuję poprzednich punktów w cloudzie - czyli na kloudowej instancji, z kloudowego docker registry i innego customowego "registry" jak chodzi o libki
-
jak mi się chce, to jeszcze w nowym języku próbuję bawić się w jakieś zadanka algorytmiczne, np. leetcode (kilka jakichś o różnych stopniu trudności), aby "obyć" się z prostym operowaniem na listach/tablicach/itp.
Ten sposób nauki języka sprawia, że stykam się ze sporą ilością potencjalnych problemów, które można napotkać w normalnych projektach + mam jakieś absolutne minimalne podstawy do pracy w danym języku (gdybym trafił do jakiegoś stacku w nim związanego)
lambdadziara napisał(a):
ucze sie teraz rosyjskiego i chinskiego, mam nadzieje za pare lat wyjechac do chin pracowac nad oprogramowaniem do handlu algorytmicznego jak to robi jedna z uzytkowniczek, @katelx chyba
znajomosc tych 2 jezykow (zakladajac ze masz biegly angielski) to dosc spory atut. w hft jest sporo rosjan :) a co do chinskiego to bardzo ulatwia zycie, zyskujesz +90 do charyzmy, przecietny chinczyk mysli ze przecietny bialy jest za glupi zeby ogarnac jezyk, wiec nawet jesli znasz te 50-100 slow to juz jestes gwiazda i daje ci to sporo benefitow profesjonalnie i prywatnie.