Trudne chwile w programowaniu

pytanie zadane 10 maja 2015 w Rozwój zawodowy, nauka, praca przez falauthy Stary wyjadacz (11,550 p.)

Witam,

Wiem, że było wiele tematów "Jak zacząć programować", "Od jakich języków zacząć", "Jak się zmotywować", ja mam podobne, ale z drugiej strony inne pytanie.

Jak można zauważyć jest wiele żartów na temat tego, że "Napisałem program i działa - nie wiem dlaczego. Napisałem program i nie działa - nie wiem dlaczego" i tym podobnych. Jestem raczej początkującym programistą, łatwo pochłaniam wiedzę teoretyczną, ale w praktyce jest inaczej...

Podam na przykładzie robienia zadań ze SPOJa. Często mam tak, że jak widzę zadanie, to w głowie mam już algorytm, wiem co zastosować w programie, biorę się za pisanie i wtedy mam czarną dziurę... Cokolwiek napiszę, to zawsze wyjdzie jakiś error z którym nie daje sobie rady i w większości przypadków jest tak, że szukam podobnego programu, leciutko go pozmieniam, wykomentuje sobie go i teoretycznie go rozumiem, ale gdybym miał pisać od podstaw, to znowu złapałbym zadyszkę...

Moje pytanie do was - jak z tym sobie poradzić? Czytam książkę S. Pratha "Szkoła programowania C++" i dokształcam się jeszcze kursami Pana Mirosława (nie są tutaj skomplikowane zadania i to trochę na minus), umiem sobie poradzić z małoskomplikowanymi zadaniami, ale gdy mam do zrobienia zadania na przykład takie:

http://pl.spoj.com/problems/PRIME_T/ (wiem, że trzeba zastosować Sito Eratostensa, tylko nie wiem jak to przelać na kod)

http://pl.spoj.com/problems/PA05_POT/ (tutaj jest zależnośc w potęgowaniu, wiem jak ona wygląda, ale też nie wiem jak to napisać)

http://pl.spoj.com/problems/FLAMASTE/ (mam na to alogytm, no ale tak jak napisałem wyżej..)

Jak to u was wyglądało? Jak nauczyliście się rozwiązywać takie problemy? Jak załapaliście kiedy stosować dane funkcje?

Pozdrawiam

3 odpowiedzi

odpowiedź 10 maja 2015 przez MrWeb Stary wyjadacz (10,200 p.)
edycja 10 maja 2015 przez MrWeb

Do rozwiązywania problemów najlepsza jest kartka papieru!

Nie ma sensu pisać kodu jeśli i tak nie zadziała lub będzie trzeba go w całości przebudować, lepiej napisać to sobie na brudno i poszukać punktów, które są trudne w zaimplementowaniu a potem te punkty rozpisać na jeszcze mniejsze punkty zasada Divide and conquer

Po napisaniu takiego pseudokodu dużo łatwiej jest zamienić każdą kolejną pseudolinijkę na rzeczywisty kod niż robić to z pamięci. Po pewnym czasie takiego treningu nie będziesz tego musiał rozpisywać bo będziesz miał to wszystko w głowie! Genialna sprawa - magia slight edge.

komentarz 10 maja 2015 przez falauthy Stary wyjadacz (11,550 p.)

Tego nie znałem - fajna sprawa. :)

komentarz 10 maja 2015 przez efiku Szeryf (75,160 p.)

Ja od siebie polecam tablice, mazaki i karteczki!
Bo pierwsze zanim się zabierze człowiek do kodowania to kartka papieru ewentualnie diagramy UML porobi i wtedy koduje.

Ale proponuje tu też zapoznać się z TDD

Robisz testy które nie przechodzą,

piszesz kod

testy przechodzą i wiesz, że Twoja aplikacja robi dokładnie to co chcesz :)

PS: Vote up ode mnie :)

komentarz 10 maja 2015 przez falauthy Stary wyjadacz (11,550 p.)

Będe musiał poczytać o UML i testowaniu, bo jestem całkowicie zielony w tym temacie. :)

komentarz 10 maja 2015 przez MrWeb Stary wyjadacz (10,200 p.)

To ja tylko na szybko streszczę o co chodzi z UML dla osób które tu wpadną poczytać ;) Kiedy tworzy się projekt w większym zespole, warto wyznaczyć dla każdego z pracowników odpowienią rolę którą ma pełnić. Projekt nad którym pracuje wiele programistów może szybko przerodzić się w spaghetti-code, lub po prostu nie będzie działał tak jak należy. Aby temu zapobiec stosuje się wiele technik, gdzie najstarszą z nich jest właśnie kartka papieru - najpierw myślisz, potem robisz. Jednak ta kartka nie sprawdzi się w 100 osobowym teamie ludzi - trzeba wymyślić coś lepszego. I tak powstały metodyki prowadzenia projektu czyli w gruncie rzeczy spis zasad których ekipa programistów ma przestrzegać dla dobra projektu (i ich posady ;P ) Tych metodyk jest oczywiście wiele, i każda z nich ma swoje wady i zalety. Np: zasada "najpierw kartka potem kod" jest skuteczna ale tylko dla jednej osoby. Pracując z kilkuosobowym teamem można użyć systemu iteracyjnego który też opiera się na karteczkach. Nie będę go tu opisywał bo to za dużo, ale odsyłam was do krótkiego streszczenia na yt - https://www.youtube.com/watch?v=eae7qghr3G4&index=8&list=PLFq6ri1W22hwWHaXHsJ1BiRz7l6xH7Ues UML - (Unified Modeling Language) - uniwersalny język modelowania projektów wspierający metodyki tworzenia projektu. Zamiast pisać wielo stronnicowego opisu projektu, zadania, funkcji itd możemy zrobić diagram który wszystko ładnie przedstawi, a opis tekstowy możemy wtedy zastosować dla szczegółowych informacji o danej rzeczy. Np. Tak budowa silnika graficznego w uproszczeniu : https://www.google.pl/search?q=architecture+of+game+engine&client=ubuntu&hs=Wz4&channel=fs&tbm=isch&tbo=u&source=univ&sa=X&ei=rSZPVZyNGcqLsgGw7oHQCQ&ved=0CCUQsAQ&biw=1237&bih=929# UML to poprostu zbiór zasad których warto się trzymać podczas tworzenia takich schematów.

komentarz 10 maja 2015 przez falauthy Stary wyjadacz (11,550 p.)

Super, później obejrzę, bo niestety teraz nie mogę. Dzieki jeszcze raz!

odpowiedź 10 maja 2015 przez Buby Pasjonat (19,590 p.)

Myślę, że nie ma na to jakiegoś magicznego, konkretnego sposobu - tak jak pan Mirosław powiedział, na wszystko potrzeba czasu. Najważniejsze jest samozaparcie i wiara w siebie, a z czasem sam siebie zadziwisz. Dla mnie najprzyjemniejszą rzeczą w tym wszystkim, jest powrócenie do czegoś, co kiedyś wydawało mi się nie do zrobienia, a teraz zajmuje mi to max 15 minut. Dzięki temu wiem, że nie stoję w miejscu. Poza tym zauważyłem, że czym więcej siedzę w kodzie i go widzę, tym bardziej przyjazny mi się staje - po chwili widzę wszystko i po krótkiej analizie od razu przychodzą pomysły co z tym zrobić. No oczywiście zawsze może zdarzyć się kod wykraczający poza zakres moich umiejętności i wtedy szukam, doszkalam się, aby pojąć go w 100 procentach.

Pozdrawiam! :)

P.S

Propsy za książke - ja uważam, że to świetna pozycja [już niewiele mi zostało do końca]. O wiele bardziej mi się podoba niż Symfonia, którą tak wszyscy zachwalają :P

komentarz 10 maja 2015 przez falauthy Stary wyjadacz (11,550 p.)

No tak, tylko jak ja mam kod, to go rozumiem, wszystko fajnie, tylko żeby znów coś podobnego zrobić, to czarna magia...

Symfonia jest trochę stara, ja mam wydanie Prathy z C++11. :)

odpowiedź 10 maja 2015 przez Wiciorny Ekspert (270,690 p.)

Słuchaj, Rzymu nie zbudowano od razu. To jest tak jak z matematyką, niby przeczytasz teorie, masz jakiś wzorem robisz na jedno kopyto zadanie, wszystko fajnie. Przychodzi sprawdzian, troche zmienią dane, trochę zmienią treść i okazuje się, że nie jest to takie proste i się gubisz. Dlaczego? Bo za krótko to robisz...

Daj sobie czas, kształć się rozwijaj rób zadania, tutaj najlepszą rzeczą jest systematyczna praca :) jak z czytaniem im dłużej czytasz tym bardziej jesteś obyty w słownictwie BAA! GRAMATYKE lepiej potrafisz, mimo że się nie uczyłes ale po prostu znasz budowe słowa. :) I tutaj tak będzie, jak koledzy mówią. Pomagaj sobie gotowymi rozwiązaniami, szukaj funkcji podobnych, kombinuj jakby zapisać to własnym algorytmem ( trochę zmienionym, poprawionym lub napisanym tak aby był jaśniejszy dla Ciebie ). Zobaczysz sam, ze z czasem patrząc na kolejne zadania albo juz projekty będziesz wiedział co zastosować, albo przynajmniej do czego się odwołać

Powodzenia! I wytrwałości