Uczenie się programowania

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?

flowCRANE
Moderator Delphi/Pascal
  • Rejestracja:ponad 13 lat
  • Ostatnio:około 6 godzin
  • Lokalizacja:Tuchów
  • Postów:12166
1

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


Pracuję nad własną, arcade'ową, docelowo komercyjną grą z gatunku action/adventure w stylu retro (pixel art), programując silnik i powłokę gry od zupełnych podstaw, przy użyciu Free Pascala i SDL3. Więcej informacji znajdziesz na moim mikroblogu.
pedegie
  • Rejestracja:około 11 lat
  • Ostatnio:ponad rok
  • Postów:204
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ą

Patryk27
Moderator
  • Rejestracja:ponad 17 lat
  • Ostatnio:ponad rok
  • Lokalizacja:Wrocław
  • Postów:13042
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ś.


edytowany 1x, ostatnio: Patryk27
kiteboarder
  • Rejestracja:ponad 9 lat
  • Ostatnio:prawie 3 lata
  • Lokalizacja:Warszawa
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.

somekind
Moderator
  • Rejestracja:około 17 lat
  • Ostatnio:około 10 godzin
  • Lokalizacja:Wrocław
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
kiteboarder
  • Rejestracja:ponad 9 lat
  • Ostatnio:prawie 3 lata
  • Lokalizacja:Warszawa
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.

twonek
ciężko co parę miesięcy kupować nową książkę bo wyszła nowa wersja frameworka
kiteboarder
ale nie kupuje się nowej książki gdy wyjdzie nowa wersja frameworka (chyba, że ktoś chce), tylko kupuje się je po to, aby zdobyć wiedzę elementarną, np. nauczyć się danej składni, wzorców projektowych, alogrytów itd. jak już te podstawy zdobędziesz, to przy nowym frameworku czytasz specyfikację i fora
twonek
czyli piszesz dokładnie to samo co @somekind, więc nie rozumiem sensu tego posta
kiteboarder
no właśnie nie, bo @somekind wyraźnie implikuje, że nowych technologii z książek się nie uczysz, a to nieprawda (przykład najnowszego C# i .NET). jeśli chcesz, to siedzisz w specyfikacji, a jeśli nie, to kupujesz publikację (jeśli jest na rynku). więc konkretnych technologii można się uczyć z książki. w swojej ostatniej wypowiedzi brakło mi słowa "zazwyczaj" na początku zdania, co zmienia sens. ja osobiście książki kupuję, bo lubię, ale większość lata po stronach i czyta
twonek
Jako osoba trzecia nigdzie nie widzę takiej implikacji. Napisał jedynie, że nie używa książek do nauki technologii, nigdzie nie widzę "książki nie uczą technologii".
FA
  • Rejestracja:prawie 11 lat
  • Ostatnio:ponad 7 lat
  • Postów:475
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 ;)

Wizzie
od tego jest chyba dokumentacja, czo? :P
FA
No troche tak, ale dokumentacja to jednak taki poziom wyzej, jak juz wiesz czego konkretnie w niej szukac. Technologiczne biblie maja ta przewage nad dokumentacja, ze: 1) Przewaznie sa napisane w bardizej przystepny i ciekaszy sposob (obrazki i takie tam) ;p 2) Ksiazke mozna sobie wziac do parku czy czytac w drodze do/z pracy - z dala od kompa - i mimo to cos z niej jednak wyniesc 3) Czesto ksiazki sa pisane subiektywnie, autor bazujac na swoim dosiwadczeniu przekazuje rozne "tipy" czego w danym kontekscie unikac, co moze byc przydatne itd
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?

edytowany 1x, ostatnio: flowCRANE
FA
Poszukaj w google np tego: "martyrs mega project list" - na początek. Potem jakies freelancerskie fora, czy nawet tutaj w ogloszenia mozesz zagladnac i szukac pomslow
somekind
Moderator
  • Rejestracja:około 17 lat
  • Ostatnio:około 10 godzin
  • Lokalizacja:Wrocław
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".

kiteboarder
  • Rejestracja:ponad 9 lat
  • Ostatnio:prawie 3 lata
  • Lokalizacja:Warszawa
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.

LukeJL
tyle, że pytanie brzmiało "jak Wy zazwyczaj się uczycie programować?" a nie "z czego jest możliwe nauczyć się programować", więc to co somekind pisał dotyczyło jak on się uczy. Zresztą nie tylko on. Sam o ile kiedyś się uczyłem technologii rowniez z książek to teraz jeśli kupuję książki papierowe to tylko na tematy np. wzorców, architektury czy umiejętności miękkich, bo książki papierowe są zwykle przestarzałe już w momencie ich wydania.
kiteboarder
okej, napisałem już, że inaczej zrozumiałem jego wypowiedź. a co do książek to myślę, że różnie z tym bywa nawet w przypadku technologii. niektóre potrafią się osadzić na dłużej, ale racja, sprawa jest dynamiczna. wymaga jednak indywidualnego rozpatrzenia
somekind
Moderator
  • Rejestracja:około 17 lat
  • Ostatnio:około 10 godzin
  • Lokalizacja:Wrocław
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.

kiteboarder
Spoko, wyluzuj. Inaczej zrozumiałem Twoją wypowiedź. Po sprawie.
katelx
  • Rejestracja:prawie 10 lat
  • Ostatnio:4 miesiące
  • Lokalizacja:Hong Kong
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)

pedegie
czyli wszystko co stworzyłaś było do d**y? :D
katelx
bledne wnioski wyciagasz. napisalam w jaki sposob ucze sie nowych rzeczy a nie ze tworze wylacznie beznadziejny soft :)
pedegie
toć żartuje, easy :)
katelx
no ja mysle! :)
LukeJL
  • Rejestracja:około 11 lat
  • Ostatnio:około 4 godziny
  • Postów:8407
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ę.


edytowany 6x, ostatnio: LukeJL
Kliknij, aby dodać treść...

Pomoc 1.18.8

Typografia

Edytor obsługuje składnie Markdown, w której pojedynczy akcent *kursywa* oraz _kursywa_ to pochylenie. Z kolei podwójny akcent **pogrubienie** oraz __pogrubienie__ to pogrubienie. Dodanie znaczników ~~strike~~ to przekreślenie.

Możesz dodać formatowanie komendami , , oraz .

Ponieważ dekoracja podkreślenia jest przeznaczona na linki, markdown nie zawiera specjalnej składni dla podkreślenia. Dlatego by dodać podkreślenie, użyj <u>underline</u>.

Komendy formatujące reagują na skróty klawiszowe: Ctrl+B, Ctrl+I, Ctrl+U oraz Ctrl+S.

Linki

By dodać link w edytorze użyj komendy lub użyj składni [title](link). URL umieszczony w linku lub nawet URL umieszczony bezpośrednio w tekście będzie aktywny i klikalny.

Jeżeli chcesz, możesz samodzielnie dodać link: <a href="link">title</a>.

Wewnętrzne odnośniki

Możesz umieścić odnośnik do wewnętrznej podstrony, używając następującej składni: [[Delphi/Kompendium]] lub [[Delphi/Kompendium|kliknij, aby przejść do kompendium]]. Odnośniki mogą prowadzić do Forum 4programmers.net lub np. do Kompendium.

Wspomnienia użytkowników

By wspomnieć użytkownika forum, wpisz w formularzu znak @. Zobaczysz okienko samouzupełniające nazwy użytkowników. Samouzupełnienie dobierze odpowiedni format wspomnienia, zależnie od tego czy w nazwie użytkownika znajduje się spacja.

Znaczniki HTML

Dozwolone jest używanie niektórych znaczników HTML: <a>, <b>, <i>, <kbd>, <del>, <strong>, <dfn>, <pre>, <blockquote>, <hr/>, <sub>, <sup> oraz <img/>.

Skróty klawiszowe

Dodaj kombinację klawiszy komendą notacji klawiszy lub skrótem klawiszowym Alt+K.

Reprezentuj kombinacje klawiszowe używając taga <kbd>. Oddziel od siebie klawisze znakiem plus, np <kbd>Alt+Tab</kbd>.

Indeks górny oraz dolny

Przykład: wpisując H<sub>2</sub>O i m<sup>2</sup> otrzymasz: H2O i m2.

Składnia Tex

By precyzyjnie wyrazić działanie matematyczne, użyj składni Tex.

<tex>arcctg(x) = argtan(\frac{1}{x}) = arcsin(\frac{1}{\sqrt{1+x^2}})</tex>

Kod źródłowy

Krótkie fragmenty kodu

Wszelkie jednolinijkowe instrukcje języka programowania powinny być zawarte pomiędzy obróconymi apostrofami: `kod instrukcji` lub ``console.log(`string`);``.

Kod wielolinijkowy

Dodaj fragment kodu komendą . Fragmenty kodu zajmujące całą lub więcej linijek powinny być umieszczone w wielolinijkowym fragmencie kodu. Znaczniki ``` lub ~~~ umożliwiają kolorowanie różnych języków programowania. Możemy nadać nazwę języka programowania używając auto-uzupełnienia, kod został pokolorowany używając konkretnych ustawień kolorowania składni:

```javascript
document.write('Hello World');
```

Możesz zaznaczyć również już wklejony kod w edytorze, i użyć komendy  by zamienić go w kod. Użyj kombinacji Ctrl+`, by dodać fragment kodu bez oznaczników języka.

Tabelki

Dodaj przykładową tabelkę używając komendy . Przykładowa tabelka składa się z dwóch kolumn, nagłówka i jednego wiersza.

Wygeneruj tabelkę na podstawie szablonu. Oddziel komórki separatorem ; lub |, a następnie zaznacz szablonu.

nazwisko;dziedzina;odkrycie
Pitagoras;mathematics;Pythagorean Theorem
Albert Einstein;physics;General Relativity
Marie Curie, Pierre Curie;chemistry;Radium, Polonium

Użyj komendy by zamienić zaznaczony szablon na tabelkę Markdown.

Lista uporządkowana i nieuporządkowana

Możliwe jest tworzenie listy numerowanych oraz wypunktowanych. Wystarczy, że pierwszym znakiem linii będzie * lub - dla listy nieuporządkowanej oraz 1. dla listy uporządkowanej.

Użyj komendy by dodać listę uporządkowaną.

1. Lista numerowana
2. Lista numerowana

Użyj komendy by dodać listę nieuporządkowaną.

* Lista wypunktowana
* Lista wypunktowana
** Lista wypunktowana (drugi poziom)

Składnia Markdown

Edytor obsługuje składnię Markdown, która składa się ze znaków specjalnych. Dostępne komendy, jak formatowanie , dodanie tabelki lub fragmentu kodu są w pewnym sensie świadome otaczającej jej składni, i postarają się unikać uszkodzenia jej.

Dla przykładu, używając tylko dostępnych komend, nie możemy dodać formatowania pogrubienia do kodu wielolinijkowego, albo dodać listy do tabelki - mogłoby to doprowadzić do uszkodzenia składni.

W pewnych odosobnionych przypadkach brak nowej linii przed elementami markdown również mógłby uszkodzić składnie, dlatego edytor dodaje brakujące nowe linie. Dla przykładu, dodanie formatowania pochylenia zaraz po tabelce, mogłoby zostać błędne zinterpretowane, więc edytor doda oddzielającą nową linię pomiędzy tabelką, a pochyleniem.

Skróty klawiszowe

Skróty formatujące, kiedy w edytorze znajduje się pojedynczy kursor, wstawiają sformatowany tekst przykładowy. Jeśli w edytorze znajduje się zaznaczenie (słowo, linijka, paragraf), wtedy zaznaczenie zostaje sformatowane.

  • Ctrl+B - dodaj pogrubienie lub pogrub zaznaczenie
  • Ctrl+I - dodaj pochylenie lub pochyl zaznaczenie
  • Ctrl+U - dodaj podkreślenie lub podkreśl zaznaczenie
  • Ctrl+S - dodaj przekreślenie lub przekreśl zaznaczenie

Notacja Klawiszy

  • Alt+K - dodaj notację klawiszy

Fragment kodu bez oznacznika

  • Alt+C - dodaj pusty fragment kodu

Skróty operujące na kodzie i linijkach:

  • Alt+L - zaznaczenie całej linii
  • Alt+, Alt+ - przeniesienie linijki w której znajduje się kursor w górę/dół.
  • Tab/⌘+] - dodaj wcięcie (wcięcie w prawo)
  • Shit+Tab/⌘+[ - usunięcie wcięcia (wycięcie w lewo)

Dodawanie postów:

  • Ctrl+Enter - dodaj post
  • ⌘+Enter - dodaj post (MacOS)