Uczenie się programowania

0

Cześć,
jak Wy zazwyczaj się uczycie programować? Z poradników? Przepisujecie kod ze stackoverflow? :D

U mnie to jest tak, że w miarę możliwości staram się sam coś stworzyć, a jak mi nie wychodzi to szukam odpowiedzi na stackoverflow i kopiuj-wklej. Jak myślicie, tak to powinno się odbywać? Czy inaczej?

1

Czy te pytania skierowane są wyłącznie do programistów C# i PHP, czy ogólnie do wszystkich?

0

Ja myślę, że najważniejsze jest to żeby rozumieć co się robi. Później dlaczego właśnie tak a następnie, jak można zrobić to lepiej. Kopiuj - wklej bez zrozumienia jest bez sensu. No i PISZ ten kod samemu, dzięki temu zapamiętujesz wiele rzeczy.

Ja się uczę z książek i internetu(kursy, materiały udostępniane przez uczelnie, SO, fora).

Dodaj może na jakim etapie jesteś, bo inne rady są kierowane dla kompletnych nowicjuszy a inne do średnio-zaawansowanych. Chociaż Ci drudzy to raczej już takich pytań na forum nie zadają

0

Na początku miałem poradnik z miesięcznika Ekspert (http://www.ks-ekspert.pl) o programowaniu we FPC (Pascal) - z nim poznałem jakieś kompletne podstawy (wczytywanie tekstu z konsoli, wyświetlanie i najprostsza obsługa IDE). Więcej nauczyłem się przeglądając gotowe kody i próbując zrozumieć, co z czym się łączy oraz w miarę możliwości dodając własne ficzery do gotowych programów (do których miałem kod źródłowy).

Bardzo złą praktyką jest natomiast kopiowanie na pałę kodu z SO - pewnie, fajnie jest Ctrl+C Ctrl+V i już program działa jak chcemy, lecz w programowaniu chodzi o zrozumienie. A w momencie, gdy wklejasz czyjś kod bez jego analizy, nic nie zrozumiesz i tak naprawdę nadal stoisz w tym samym bagnie, tyle że chwilowo je zakryłeś.

1

Ja uczę się z książek. Od zawsze uwielbiałem zapach papieru i druku, więc jest to dla mnie przyjemniejsze, niż ciągłe gapienie się w ekran (a i tak gapić się trzeba, bo przepisywanie kodu z książki + analiza kodu lub rozwiązywanie ćwiczeń z książki tego wymaga, ale nie męczysz tak wzroku - no chyba, że uczysz się np. HTML-a, wtedy możesz pisać w zeszycie, ale też do czasu). Oczywiście wszystko ma swoje plusy i minusy, musisz znaleźć najprzyjemniejszą formę nauki dla siebie.

1
  1. Pisząc kod i przeszukując dokumentację/fora/SO w przypadku napotkania problemu.
  2. Książki - do nauki rzeczy stałych (wzorców, dobrych praktyk, architektury, składni języka), nie konkretnych technologii.
  3. Tutoriale
0

Pierwsze słyszę, żeby książki nie uczyły technologii. Są różne książki na rynku i nauczyć się z nich można wszystkiego.

0
kiteboarder napisał(a):

Pierwsze słyszę, żeby książki nie uczyły technologii. Są różne książki na rynku i nauczyć się z nich można wszystkiego.

Moim zdaniem książki są dobre w douczaniu sie konkretnej technologii, kiedy juz znamy mocne podstawy i chcemy sie zaglebic w szczegoly implementacyjne albo po prostu w "czemu akurat tak". Na sam początek duzo bardizej efektywnie jest zaczac od prostych sampli z jakichś tutoriali zamiast zabierac sie za 1000+ stronową cegle - przynajmniej mi tak jest prosciej ;)

0
furious programming napisał(a):

Czy te pytania skierowane są wyłącznie do programistów C# i PHP, czy ogólnie do wszystkich?

Do wszystkich


Mam do Was jeszcze jedno pytanie - otóż ja piszę programy czy jakieś aplikacje tylko i wyłącznie gdy mam potrzebę. Mogę siedzieć do późna w nocy i kodzić co trzeba, ale jak nie mam potrzeby pisania to mogę i nie pisać przez miesiąc-dwa przez co część wiedzy mi umyka. Stąd moje pytanie - skąd mogę czerpać jakieś pomysły na różne aplikacje?

0
kiteboarder napisał(a):

Pierwsze słyszę, żeby książki nie uczyły technologii. Są różne książki na rynku i nauczyć się z nich można wszystkiego.

Przeczytaj może pytanie, które zadał autor wątku, bo ja na nie odpowiedziałem. I nigdzie nie napisałem, że "książki nie uczą technologii".

0

Książki - do nauki rzeczy stałych (wzorców, dobrych praktyk, architektury, składni języka), nie konkretnych technologii.

To Ty zwracaj uwagę na to, co piszesz. Bo Twój wywód jest dla mnie jednoznaczny i nie doprawiałbym do tego filozofii.

FakeAccount, imho każdy ma inaczej. Ja osobiście wolę przejść 1000 stron składni z przykładami kodu i ćwiczeniami na własne rozwiązanie, a dopiero później uzupełniać wiedzę np. samplami, tutorialami. W książce sobie zaznaczam wszystko co najważniejsze i wracam do zagadnień czasami kilka razy, ale wtedy mam wybraną najważniejszą treść, więc to chwila moment ;) No i polecam tablice informatyczne, wszystko w jednym miejscu.

0
kiteboarder napisał(a):

To Ty zwracaj uwagę na to, co piszesz. Bo Twój wywód jest dla mnie jednoznaczny i nie doprawiałbym do tego filozofii.

Taa...

Pytanie:

jak Wy zazwyczaj się uczycie programować?

Moja odpowiedź:

Książki - do nauki rzeczy stałych (wzorców, dobrych praktyk, architektury, składni języka), nie konkretnych technologii.

Nie chcesz filozofować, to nie filozofuj. Czytaj ze zrozumieniem i nie dopowiadaj sobie czegoś, czego nie napisano.

0
wszywka napisał(a):

jak Wy zazwyczaj się uczycie programować?
zazwyczaj wyglada to tak (czasem ten cykl trwa pare godzin, czasem rok-dwa):
a) tworze doskonale rozwiazanie
b) dziala swietnie
c) jednak nie do konca
d) patrze po necie, odpalam profiler, gadam z kolegami z zespolu
e) okazuje sie ze a) jest do d**y
f) wracam do a)

1

Ja podobnie jak @katelx, ale jednak inaczej.

Jeśli chodzi o sideprojecty (na których się w sumie najwięcej uczę):
a) tworzę prototyp (czasem ten cykl trwa kilka godzin, czasem kilka tygodni), często w ogóle używając nowej dla mnie technologii

b) rozwijam go trochę byle jak, aż do momentu kiedy cały kod staje się dość chaotyczny i ciężko mi się samemu w nim połapać

c) wtedy przepisuję od nowa, na czysto, ze wszystkimi dobrymi praktykami, korzystając również z TDD itp.

d) kod okazuje się "przeinżynierowany" i w końcu dochodzę do tego, że utykam w martwym punkcie, że porobiłem ileś modułów i abstrakcji, które nic nie robią tak naprawdę.

e) więc przepisuję jeszcze raz od nowa, już jednak podchodząc bardziej pragmatycznie, odrzucając TDD czy zaawansowane konstrukcje i stawiając na to, żeby program działał przede wszystkim. Stosuję dobrze poznane wzorce, ewentualne eksperymenty robiąc sobie na boku jako spajki. Przede wszystkim funkcjonalność, YAGNI, MVP(mam na myśli minimum viable project oczywiście, coś co działa, a co nie jest idealne) etc.

f) po jakimś czasie albo rozwijam dalej sideproject, albo z jakichś powodów go porzucam, albo przepisuję jeszcze raz od nowa :)

g) tym niemniej na każdym etapie się czegoś nowego uczę. Przede wszystkim poznaję plusy i minusy pewnych rozwiązań i coraz bardziej rozumiem problem, który chcę rozwiązać. No i dużo jest myslenia, choćby w kiblu. Nie tylko siedząc przed kompem.

Powyższe punkty jednak dotyczą sideprojectów, gdzie mam 100% swobody do tego co robię, jak robię i ile czasu to robię. W pracy zwykle bywałem rzucany na głęboką wodę i były już istniejące projekty do rozwijania, więc ta nauka inaczej przebiegała (myślę zresztą, że z powodu presji czasu w pracy z musu się mniej uczę, bo kto by mi pozwolił eksplorować rozwiązanie przez kilka tygodni? W pracy ważniejsze od nauki bywa "dostarczanie"). Więc w pracy zwykle:
a) zaznajamiam się z codebasem, czytam też dokumentację bibliotek/frameworków, których mam używać

b) hakuję jakieś funkcjonalności, lepiej lub gorzej (czasem również robię kilka podejść, ale szczerze mówiąc trochę mi wstyd, jak dużo prototypuję i rozkminiam, bo czuję presję czasu).

c) daję do code review, dostaję jakiś feedback

d) poprawiam

e) hakuję kolejne funkcjonalności, ew. dalej doczytując dokumentację czy zaznajamiąc się z codebasem itp.

Czyli w zasadzie uczę się robiąc taski i eksplorując kod, ale jednak czuję zbyt dużą presję czasu, i mam wrażenie że jest to nauka dość powierzchowna. Bo trzeba robić swoją robotę.

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