Jak nauczyć się dobrze programować?

0

Witam wszystkich. [C/C++]
Od jakiegoś czasu nurtuje mnie temat taki jak w temacie :D.
Nabazgrałem już parę ładnych linii kodu, ale i tak czuje że nie potrafie czasami rozwiązać nawet prostych problemów.
np. na plikach pracowałem ostatni raz chyba z 2lata temu, i jak sobie pomyśle żeby tu shribnąć coś do pliku to lipa bo nie pamiętam.....muszę otworzyć np. ANSI C i sobie poczytać o fopen.......
W wakacje pisałem sobie taką prostą implementacje ponga ....chciałem poznać SDL'a i użyć w końcu STL'a + jakieś thread'y (nie SDL_Thread) wszystko Slackware + vim + g++
Wszystko ładnie i pięknie <ort>dopuki</ort> jestem na <ort>bieŻąco (Boże, widzisz takie błędy i nie grzmisz)</ort>, ale jak bym miał pare algorytmów napisać teraz z palca to kupa....
Zanim po dłuższym czasie (czyt. miesiąc /dwa) chcę sobie coś napisać, to najpierw muszę strzelić 2,3 proste programiki żeby sobie przypomnieć poprawną składnie np. dziedziczenia, polimorfizmu a czasami nawet jak przekazywać jakieś instancje obiektów do jakichś tam metod.....

Czy kluczem do mojego problemu jest pisanie codziennie??
Proszę o jakieś własne wywody na ten temat, może ktoś kto uważa że programowanie mu idzie w miarę, powie mi ile czasu poswięcał jak zaczynał, ile w trakcie rozwoju i ile teraz jak jest na <ort>bieŻąco (Boże, widzisz takie błędy i nie grzmisz)</ort>, jak się miały jakieś przerwy w programowaniu do ogólnego skill'a??

pozdrawiam

0

Nie ma w tym nic dziwnego. Trzeba przez caly czas cwiczyc, tak jak z jezykiem obcym - nie uzywasz = zapominasz. Jezeli masz z nim stycznosc caly czas stajesz sie coraz lepszy.

Podam Ci przyklad: pare lat temu troche programowalem w Perlu, teraz mialbym problemy z napisaniem 'hello world' ;) No moze troche przesadzam, ale nie jestem pewien co do sposobu deklaracji zmiennych czy tablic.

0

Powiedziałbym, że minimum, to przynajmniej jeden programik na tydzień. Mi schodzi od 5 do 10 godzin dziennie (+forum, które również trzyma w formie ;)) Jak się uczyłem samych początków, to w ogóle kosmos był, siedziałem ile tylko się dało ;)

  1. nie przejmuj się tym, że musisz skakać po manualach i reference'ach. Dobry programista (a i w ogóle każdy specjalista) nie wie wszystkiego, on wie, gdzie wszystko znaleźć ;)

  2. składnię się zapomina, na początku przygody bawiłem się Pascalem, od 6 lat piszę w C++, i Pascala muszę odkrywać na nowo.

  3. ale przypomnienie składni, jeśli ją kiedyś dobrze znałeś, to w najgorszym wypadku kilka tygodni. Od znajomości bibliotek są reference'y. Ważne, żebyś wiedział ogólnie jak sobie radzić z problemem, jak zorganizować logikę działania programu - tego się nie zapomina. Kodowanie to najmniejszy problem, wbrew pozorom ;)

0

Wg mnie co innego pamiętanie składni języka, a co innego umiejętność programowania i rozwiązywanie algorytmów, problemów czy ogólne projektowanie aplikacji. Kiedyś pisałem w Delphi, teraz pisze w C# i zapewne aktualnie miałbym duże problemy w napisaniu programu w Delphi - bo człowiek zapomina składnie, jak wyglądają deklaracje, procedury, klasy itd.

0

Zgadzam sie z Deti, ale dodam cos jeszcze. Swego czasu aplikowalem do pracy jako programista C# majac o C# jako takie pojecie (a tak naprawde to cieniutkie). Mialem tydzien na wdrozenie sie do pracy w firmie. Jako, ze znam kilka jezykow c-podobnych (c/c++, java, php), to nauczenie sie c# takiego do pracy zajelo mi mniej wiecej tyle czasu. Oczywiscie pozniej przyszla praktyka i zderzenie z realnymi problemami - ale znajomosc obiektowosci w praktyce, roznych technologii pozwala na szybkie rozprawienie sie z problemami, nawet w dziwnych jezykach :) Dlatego, nie jezyk jest wazny a to czy sie umie myslec algorytmicznie, i czy rozumie sie jak w ogole dziala komputer i jak w ogole to jest, ze te wszystkie programy maja prawo dzialac :) Jak to bedziesz umial, to przypomnienie/nauczenie sie nowego jezyka bedzie tylko chwilowym zwolnieniem tempa, nie przeszkoda.

0

dzięki za odpowiedzi, widzę że w rzeczywistosci jest tak jak przypuszcalem, zastanawialem się tylko dlaczego niektórzy moi znajomi rzucają kodem z palca i zgrywają full profi programistów że niby takie algorytmy to oni pisali w podstawówce....

Jeszcze jedna kwestia, ponieważ nie mam wśród znajomych żadnych tak naprawde profi programistów ze skill'em którzy, chcieli by przyuczac leszcza (mnie), i odnośni tego 1-2 programu tygodniowo , czy ktoś mógłby mi podsunąć pomysł z kąd przyczaić nowe techniki i metody programowania (projektowanie to osobna sprawa), ponieważ każdy problem mógłbym rozwiązać w ten sam dobrze znany mi już sposób, tym samym nie rozwijając się.
Np. ostatnio poprzeglądałem sobi źródła ndiswrapper'a i stwierdziłem że nie wiem o co chodzi z tymi "attrinutes ...." odopiero zainteresowałem się tematem, ale jak widać doskonale sobie radziłem bez tego, a wydaje mi się że to ciekawa alternatywa dla kompilatora np attrib(depricated).....

Mam nadzieje że ktoś doberze zrozumie o co mi chodzi.....
pzdr (jeszcze raz dzięki za odpowiedzi)

0

kod "z palca" to nie problem pisać jak jesteś w temacie. Właściwie samo programowanie nie jest niczym trudnym, wystarczy się wdrożyć w tryb programisty ciągłego i nie ma najmniejszych problemów...

To jest właściwie tak jak z rysowaniem, jak człowiek rysuje to rysuje coraz szybciej i coraz lepiej, a porównując dawne rysunki których stworzenie zajmowało kilka godzin i było się dumnym z obecnymi szybkimi szkicami na 5 min max człowiek się zastanawia jak mógł być taki mizerny. W programowaniu jest identycznie, człowiek uczy się nowych, lepszych technik, a przez dużą ilość pisania poprawia swoją szybkość.

Wystarczy ćwiczyć, a nie [CIACH!].

0

Z tym ćwiczeniem to orzej jak się pójdzie na studia. W średniej było mnóstwo czasu na naukę programowania, chociażby kosztem większości niepotrzebnych zajęć (biologia, historia itd.). Na studiach już trzeba walczyć żeby w ogóle przetrwać i nie odlecieć. Przez pierwszy semestr napisałem może ze 2 programy i to i tak odbyło się kosztem niższej średniej na koniec. Mam nadzieje że na drugim roku będzie trochę spokojniej bo inaczej to się uwstecznie z programowania ;.
Więc jeżeli chodzisz jeszcze do liceum to programuj ile możesz i olewaj niepotrzebne pierdoły.

0
exnor napisał(a)

Z tym ćwiczeniem to orzej jak się pójdzie na studia. W średniej było mnóstwo czasu na naukę programowania, chociażby kosztem większości niepotrzebnych zajęć (biologia, historia itd.). Na studiach już trzeba walczyć żeby w ogóle przetrwać i nie odlecieć. Przez pierwszy semestr napisałem może ze 2 programy i to i tak odbyło się kosztem niższej średniej na koniec. Mam nadzieje że na drugim roku będzie trochę spokojniej bo inaczej to się uwstecznie z programowania ;.
Więc jeżeli chodzisz jeszcze do liceum to programuj ile możesz i olewaj niepotrzebne pierdoły.

i tu przyjacielu trafiłeś w samo sedno......Polibuda wrocław kierun elektronika IV rok i czasu z każdym rokiem coraz mniej....a miało być coraz lepiej............na 3cim jeszcze oglądałem filmy...teraz już nie mam czasu.....ledwo łupie sobie coś dla siebie na hardwarze....

pzdr..dzięki za przemyślenia....

0

Az wkoncu pojdziesz do pracy... 8h kodowania i nauki nowych technologii... a przy okazji placa Ci za to :)

0

Witam

Wydaje mi się ,że to nawet nie kwestia tego ,żeby dużo programować ,ale żeby nawet pisac mało ale od początku nastwić się na cel jakim jest pisanie "dobrego kodu". Konstruktywna krytyka jest w takim przypadku jak najbardziej mile widziana.Napisz jakiś kawałek kodu, wrzuć na jakieś forum i wysłuchaj opinii , być może tu czy tam możesz coś zrobić lepiej.Następnym razem własnie tak zrobisz.

Natomiast nie ma prostej zalezności ,że jeśli piszesz dużo to znaczy ,że tworzysz dobry kod, dobre rozwiązania.

0

A czy dobry kod masz tak wielkie znaczenie? W końcu pracodawca wymaga, żeby działało, a na wymyślanie błyskotliwego kodu trochę czasu schodzi. Większość moich projektów upadała z tego powodu, że chciałem pisać idealny kod i idealne programy. Projekty były zbyt ambitne i tylko traciłem czas. Lepiej napisać cos nawet bardzo topornie byleby to skończyć.

0

A czy dobry kod masz tak wielkie znaczenie?

Mam ochotę udać, że tego pytania nie zadałeś ;)
Pracodawca wymaga tego, co klient, a klient często nie wie, czego wymaga. Więc musisz wprowadzać zmiany, czasem w połowie projektu na przykład. A modyfikacja i pielęgnacja kodu, który tylko działa, to tragedia. reusability tak samo. To prawda, też wiele moich projektów upadło. Ale co ciekawe, fragmenty tych projektów wykorzystuję do dzisiaj. Bo jakkolwiek całość nie została ukończona, to pewne biblioteki pomocnicze były na tyle dobrze napisane, że korzystanie z nich to przyjemność. Poza tym, sprawdzenie dobrego kodu jest o wiele łatwiejsze pod względem poprawności, niż tego pisanie na kolanie. I argumentów jeszcze sporo innych. Ogólnie: "działającemu" kodowi mówimy NIE ;)

0

Nie pamiętam kto to powiedział/napisał, ale "jeśli chcesz nauczyć się programować, to popraw program, który napisałeś".

Dobry programista to nie taki, który rzuca w towarzystwie skomplikowanymi algorytmami i kodem, jak nawozem po polu...Nie oglądaj się na to, co ktoś umie, tylko czego Ty możesz się jeszcze nauczyć.
Co do pisania "dobrego" i "działającego" kodu, to "dobry" kod musi być zarazem "działający" (odwrotnie już tak nie musi być ;)). Działający kod jest ważny, ale powinien być na tyle elastyczny, by można było wprowadzać ewentualne poprawki "od ręki" bez przebudowywania połowy programu (chyba, że nie zamierzasz nic poprawiać w programie lub zależy ci na czasie). Za elastyczność kodu płaci się czasem i doświadczeniem tudzież znajomością mechanizmów języka, w którym rozwiązujesz dany problem - im mniej tego masz, tym bardziej toporny kod wygenerujesz.
Z własnego (skromnego) doświadczenia mogę powiedzieć, że samo klawiszoklepanie zajmuje ok. 20-25% czasu. Reszta to czas poświęcony na doszlifowywanie logiki programu, tak by osiągnąć rozwiązanie w miarę zgrabnej, elastycznej formie i jak najkrótszymi drogami (najkrótszymi dla komputera oczywiście). To, co z tego wychodzi działa tak, jak działa, ale ponieważ dalej sie uczę, poprawiam błędy, dodaję nowe, ciekawsze rzeczy, przeglądam kod, manuale i inne materiały program staje się lepszy - bo potrafi coraz więcej, ale wcale nie staje się przez to bardziej skompliowany lub niezrozumiały (przynajmniej dla mnie ;)). Druga strona medalu to rozsądny czas, w jakim aplikacja ma uzyskać wymaganą funkcjonalność. Gdyby każdy tylko szlifował kod, dodawał coś, zmieniał, poprawiał, niemal wszystkie aplikacje, które do tej pory się ukazały byłyby w dalszym ciągu w stanie produkcji. Zawsze pojawiają się jakieś poprawki, łaty, uaktualnienia, a część pomysłów na nie (tak mi się wydaje) przychodzi w trakcie pisania poprzedniej wersji/ łaty (inne po testach lub pewnym okresie użytkowania). Dlatego nie ma nic złego w wypuszczaniu "złego", ale "działającego" kodu (kwestia kompromisu), trzeba jednak pamiętać, że 'zły kod boli przez całe poprawianie'.

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