UPDATE: Osoby poczatkujące (i nie tylko) zapraszam również do rzucenia okiem na podcasty o programowaniu/hackingu/RE/etc, które publikuję na YT: http://www.youtube.com/user/GynvaelColdwind
1. Jaki język wybrać?
Jednym z najczęściej pojawiających się pytań jest "jaki język powinienem wybrać?", lub "jaki język będzie dla mnie najlepszy?". Jak można się domyślić, nie ma prostej odpowiedzi na to pytanie, ba, powiem więcej, przez ostatnie 20 lat odpowiedź staje się coraz trudniejsza.
W czasie gdy rozpoczynałem swoją przygodę z programowaniem (niecałe 20 lat temu) sprawa wyglądała bardzo prosto - kupowało się mały komputer marki Atari (np. Atari 800 XL), Commodore (np. C64) lub podobny 8-bitowy sprzęt, uruchamiało go, i pokazywał się interpreter języka BASIC. Tak więc do wyboru był BASIC, ewentualnie Logo które dostawaliśmy na kasecie/dyskietce, i które raczej przypominało zabawkę niż język programowania, oraz ewentualnie assembler jeżeli ktoś był na tyle wytrwały by się dowiedzieć jak dysponując jedynie interpreterem BASIC'a pisać w assemblerze. Oczywiście, czym bardziej zaawansowany był komputer i użytkownik, tym więcej języków miał do wyboru - np. Action!, Pascal, lub Turbo BASIC, ewentualnie C, Fortran, lub kilka innych dostępnych głównie na silniejszych platformach.
Teraz, 20 lat później, nie dość iż początkujący programista ma dużo większy wybór, to jeszcze oprócz wyboru języka musi wybrać środowisko programistyczne które go zadowoli i które będzie działać na jego systemie komputerowym.
Co w takim razie początkujący programista powinien wybrać? Zacznę od tego, że pytanie jest nie do końca dobrze postawione - moim zdaniem powinno brzmieć "jaki język powinienem wybrać na początek?". Różnica, mimo iż minimalna, jest bardzo ważna, a wynika z faktu iż programista nie powinien ograniczać się do jednego języka. Powinien raczej popróbować różnych języków, tak aby poznać różne punkty widzenia, dowiedzieć się jakie mechanizmy istnieją w różnych językach, pomyśleć jak symulować pewne rozwiązania natywne dla pewnych języków w innych językach, nie mających natywnego wsparcia dla danej funkcjonalności, etc. Proszę zauważyć iż nie twierdze, że programista powinien w nieskończoność skakać między językami, wręcz przeciwnie! Każdy programista prędzej czy później znajdzie jakiś swój jeden, jedyny, ukochany język, w którym będzie się specjalizował, i który po pewnym czasie będzie znał na wspak i po rumuńsku. Twierdzę natomiast iż programista który pozna rożne języki, będzie lepiej pisał w swoim ulubionym języku, niż programista który ograniczył się tylko do tego jednego języka, nie poznając innych rozwiązań. Np. zdradzę że moim ulubionym językiem jest C (w dialekcie C99), natomiast przez ostatnie 20 lat miałem przyjemność programować w około 40 różnych języków/dialektów.
Kolejna ważna uwaga: nie ma języków które są "zawsze złe", tak samo jak nie ma języków które są "zawsze dobre". Język to tylko i wyłącznie narzędzie w rękach programisty, narzędzie które do pewnych zadań nadaje się lepiej, a w innych przypadkach sprawdza się gorzej. Oczywiście pewne języki każdy z nas polubi bardziej, a inne wręcz znienawidzi, niemniej jednak pamiętajmy o potrzebie obiektywności, oraz o tym że nawet "znienawidzonego wroga" należy poznać. Zresztą, a nuż polubimy ów język po bliższym poznaniu ;>. Przykładowo, kiedyś nie przepadałem za Javą, uważałem że język jest strasznie wolny i do tego niewygodny. Nie przeszkadzało mi to natomiast przez pewien czas pracować jako programista Java, a później przez pewien okres interesować się wewnętrzną budową VM Java'y i byte codem samego języka, przez co Javę poznałem i nawet polubiłem ;>
Czas w końcu odpowiedzieć na pytanie z tematu - jaki język wybrać na początek, tak aby się nie zniechęcić? Moje osobiste propozycje wyglądają następująco:
- Python - Bardzo prosty do opanowania język, z ogromną liczbą bibliotek, i przy okazji uczący ładnego formatowania kodu, oraz posiadający niezłą dokumentację.
- Java - Java ma w sobie pewną prostotę która może przypaść do gustu sporej części osób. Język, podobnie jak Python, jest obecnie open source (więc w razie czego można rzucić okiem do źródeł - patrz punkt o źródłach wiedzy o programowaniu niżej), jest nieźle udokumentowany (chociaż dokumentacja Javy, moim zdaniem, wymaga przyzwyczajenia się), i posiada masę najróżniejszych bibliotek.
- C# - Trochę się wahałem czy ten język tu umieścić, z uwagi na jego głęboki związek z pewną firmą - proszę nie zrozumieć mnie źle, nie mam nic przeciwko "pewnej" firmie - po prostu przez ów związek język ten jest niejako językiem jednej platformy (mimo iż istnieje implementacja open source .NET - Mono, to jednak jest ona zawszę o krok do tyłu względem oficjalnego wydania .NET, które dostępne jest jedynie na platformę Windows). C# jest językiem obiektowym, odrobinę trudniejszym niż Python, jednak łatwiejszym na początek niż C czy C++. Dokumentacja dostępna jest na MSDN, z którym trzeba się jednak na początku zapoznać, gdyż nie zawsze jest intuicyjny, ale po zapoznaniu się z nim, staje się on niezastąpiony.
Który z powyższych języków wybrać na początek? Jest to w zasadzie obojętne, gdyż po popisaniu trochę w jednym, powinno się zapoznać się z drugim. Oczywiście jeżeli ktoś uważa, że inny język byłby dla niego jednak lepszy na początek, to może spróbować - proponuję jednak zasięgnąć rady doświadczonego kolegi w tym wypadku, gdyż znam niejedną historię o tym jak to np. C czy C++ okazały się za trudne, i zniechęciły potencjalnego programistę do dalszego rozwoju w tej dziedzinie. Oczywiście należy zwrócić uwagę na to czy kolega mówi o języku, czy może mówi czy go lubi czy nie ;>
Co znaczy "trochę popisać" w powyższym stwierdzeniu? To zależy od człowieka. Najlepiej na początku popisać z pół roku, a może i rok, w jednym języku. Dlaczego tak długo? Problemem na początku drogi jest to iż trzeba uczyć się dwóch rzeczy na raz:
- po pierwsze: języka programowania - składni, funkcji, bibliotek, IDE, dodatków (np. preprocesora)
- po drugie: programowania - czyli umiejętności przelewania myśli/pomysłu na kod, czyli takiego korzystania z języka (składni/funkcji/bibliotek/IDE) aby napisany przez nas program robił dokładnie to co chcemy w możliwie najbardziej optymalny (nie koniecznie chodzi tu o optymalną szybkość) sposób
Umiejętność programowania jest niejako niezależna od znajomości języka. Znane są przypadki (szczególnie na różnego rodzaju konkursach programistycznych, czy compo), gdy osoby słabo znające dany język potrafiły stworzyć dużo ciekawszą aplikację niż osoby które dany język znały perfekcyjnie. Pamiętajmy więc, że język to nie wszystko. Należy jeszcze wiedzieć jak go używać - i to właśnie na celu ma nauka programowania.
Popisaliśmy więc trochę w Pythonie i C#, co dalej? Osobiście proponowałbym zapoznanie się z C/C++ i assemblerem (najlepiej równolegle), PHP, Perlem lub Rubym, Javą, oraz z innymi językami które wpadną nam w rękę. Jak pisałem wcześniej, i co będę powtarzał do znudzenia: czym więcej języków poznamy, tym lepiej. Oczywiście w każdy kolejny język wejdziemy łatwiej, gdyż na pewnym poziomie są one bardzo podobne.
Warto również rzucić okiem na inne rodzaje języków programowania - np. na języki funkcyjne jak Lisp, Haskell, języki logiczne jak Prolog, a nawet zabawkowe języki ezoteryczne jak Brainfuck czy LOLCODE.
Ważne jest również aby poznać narzędzie którego się używa - tj. edytor, IDE czy kompilator. Posiadają one zazwyczaj masę pomocnych opcji, które ułatwią tworzenie lub debugowanie programowania. Przykładem opcji które warto znaleźć w swoim IDE/edytorze jest np. skok do deklaracji, skok do definicji, skok do użycia danej funkcji/zmiennej czy szybkie wyszukanie funkcji w podręcznej pomocy. Warto sprawdzić również czy kompilator umie wypisywać dodatkowe informacje na temat błędów lub ostrzeżeń w kodzie (o tym jeszcze będę pisać), lub czy np. można obejrzeć wynik preprocessingu, czy kompilacji do assemblera (nie mylić z kodem maszynowym). Know your tools!
2. Jaką książkę wybrać?
Do drugiej grupy pytań które bardzo często słyszę można zaliczyć "z jakiej książki uczyć się języka XYZ?", "jaki tutorial będzie najlepszy dla języka XYZ?", lub "czy znasz jakieś strony z tutorialami do języka XYZ po polsku?". Bardzo często w takim przypadku osoba początkująca zakłada iż wystarczy przeczytać jakąś książkę lub jakiś tutorial by nauczyć się programować. Nic bardziej mylnego! Oczywiście w żadnym wypadku nie twierdzę, że książki/tutoriale są niepotrzebne, czy że nie warto ich kupować/ściągać. Problemem jest to w jaki sposób się z nich korzysta.
Moim zdaniem, wynikającym z osobistych doświadczeń, książki/tutoriala nie powinno się czytać. Zamiast czytania polecam natomiast wyszukiwanie listingów, i ich przepisywanie (tak, przepisywanie! nie kopiowanie, nie używanie kodu z dołączonej do książki płyty CD, tylko przepisywanie, literka po literce). Przepisując kod programu mamy pewność że nic ważnego z jego treści nam nie umknie, dodatkowo zapamiętujemy składnie, nazwy funkcji i poleceń oraz różne mechanizmy stosowane w języku.
Jednocześnie przepisując kod powinniśmy starać się zrozumieć co się w nim dzieje. Wiem że może to brzmieć jak duże wyzwanie - skąd osoba która nigdy wcześniej nie programowała miała by wiedzieć jak dany program działa? Jednak jest to możliwe, wystarczy zastosować pewną prostą sztuczkę:
W kodzie programu jest pełno wyrazów, które albo są angielskimi słowami, albo zlepkami lub skrótami od angielskich słów. Tak więc słownik w rękę (a raczej w przeglądarkę internetową) i tłumaczymy. Rozważmy np. poniższy kod (pochodzący z losowej strony znalezionej na google):
private void KeyDown(object sender, KeyboardEventArgs e)
{
switch (e.Key)
{
case Key.Escape:
// Will stop the app loop
Events.QuitApplication();
break;
[...]Jak wyraźnie widać powyżej, mamy w kodzie następujące słowa:
- private (ang. prywatny) - czyli coś jest prywatne, (i tu wchodzi wiedza ogólna) czyli nie jest publiczne, nie jest ogólnodostępne
- void (ang. pusty, nieważny, próżnia) - coś jest nieistotne, nie ważne (kolejne pytanie: co ?)
- KeyDown - zlepek słów: Key (ang. klucz, klawisz, przycisk) i Down (ang. pod, w dół, na dole) - czyli "klawisz w dół" - nietrudno się domyślić że chodzi o naciśnięcie klawisza
- object - (ang. obiekt, przedmiot) - czyli mamy do czynienia z jakimś obiektem
- sender - (ang. nadawca) - obiekt nadawca?
- KeyboardEventArgs - zlepek słów Keyboard (ang. klawiatura), Event (ang. zdarzenie, wydarzenie) i Args (i tutaj pojawia się problem! nie ma w słowniku słowa "args" ani "arg", chociaż wybitnie kojarzy się z jakimś piratem rodem z Karaibów ("Argh matee!"); w takim wypadku możemy to wrzucić w google, i zobaczyć podpowiedzi, ewentualnie jakie słowa znajduje; no i proszę, pod koniec pierwszej strony wyników znajdujemy podświetlone słowo "arguments", czyli argument (mój słownik podpowiada nawet że chodzi o"argument funkcji")) - Klawiatura Zdarzenie Argumenty - Argumenty zdarzenia które dotyczy klawiatury! Oczywiście słowo "argumenty" też może być na początku nieznajome - w takim wypadku możemy poszperać po wikipedii czy słowniku wyrazów bliskoznacznych - a nuż się coś nowego dowiemy
Podsumowując, pierwsza linia kodu to: prywatne nieistotne KlawiszNaciśnięty(obiekt nadawca, ArgumentyZdarzeniaKlawiatury e). Nawet jeżeli nie jest nadal do końca jasne co to jest, to wiemy już dużo więcej niż gdybyśmy po prostu rzucili okiem na tajemnicze private void KeyDown(object sender, KeyboardEventArgs e) i od razu polecieli dalej.
Warto zauważyć iż wiedza ogólna i matematyczna również się przydaje - w programowaniu widzimy sporo symboli znanych z matematyki, takich jak choćby + - * =, etc. Często sami możemy wywnioskować o co chodzi (mimo iż zapis programistyczny jest różny od matematycznego). Analogicznie jest z niektórymi nazwami funkcji, takimi jak sin czy log.
Tak więc przepisaliśmy pewien listing, potłumaczyliśmy słówka, ba, udało nam się nawet skompilować i uruchomić (poprawiając wcześniej literówki) program. Co dalej? Teraz modyfikujemy przepisany kod, czyli na chwilę zamieniamy się w naukowców, i zaczynamy przeprowadzać eksperymenty zmieniając pewne rzeczy w kodzie, patrząc uważnie co to zmienia w wykonaniu programu. Np. zamieniamy jakiś + na - i patrzymy co to zmieniło w wykonaniu programu. Usuwamy (lub komentujemy) jakąś linię, i patrzymy co to zmieniło. Zmieniamy jakieś literki tu i tam, i patrzymy czy się nadal kompiluje, ewentualnie jakiego rodzaju błąd wyskakuje (to nam się przyda później). I oczywiście próbujemy zrozumieć jak każda część programu działa.
A teraz, jeżeli nadal widzimy potrzebę, możemy przeczytać tekst w książce/tutorialu towarzyszący listingowi który przepisaliśmy, przeanalizowaliśmy i przerobiliśmy, jednak jest to raczej "bonus" niż konieczność.
Natomiast to nie jedyny pożytek z książki / tutoriala. Książka może służyć jeszcze jako ściąga z mechanizmów używanych w danym języku, oraz jako zestaw przykładów użycia różnych funkcji czy bibliotek. Również jeżeli brakuje nam jakiegoś środka ekspresji, tj. jeżeli zdajemy sobie sprawę że pewna konstrukcja w tym języku prawdopodobnie istnieje i wiemy że by nam się ona przydała - warto przekartkować książkę, i rzucić okiem na różne listingi, tytuły rozdziałów, etc. A nuż trafimy na to czego szukamy ;>
JacuS słusznie również zauważył, że dla niektórych zestaw zadań i pytań znajdujących się pod koniec rozdziału w niektórych książkach również może być bardzo pomocny i pożyteczny.
Podsumowując, początkujący programista nie powinien czytać książki / tutoriala od deski do deski. Przede wszystkim powinien przepisać/przeanalizować listingi, a po za tym powinien próbować z książki korzystać jak z leksykonu lub zbioru podpowiedzi.
Proszę również zauważyć, iż korzystając z tego sposobu uniezależniamy się od języka w jakim jest tekst. Książka może być po chińsku, japońsku, fińsku czy w jakimś innym egzotycznym języku, ale kod i tak będzie w języku programowania którego się uczymy, z nazwami pochodzącymi z języka angielskiego. Tak więc listing i tak bez problemu przepiszemy i przeanalizujemy, nie tracąc czasu na naukę języka chińskiego ;>
Drugą rzeczą godną zauważenia jest fakt, iż tak na prawdę przestaje mieć znaczenie z jakiej książki / tutoriala się uczymy, czy też jak tekst jest napisany (przystępnie? a może dla robotów?). Z każdej książki czy tutoriala możemy przepisać kod.
3. Z czego korzystać przy nauce języka/programowania?
To jest pytanie którego niestety nie słyszę zbyt często, a jest bardzo istotne. Książki i tutoriale nie są oczywiście jedynym źródłem informacji jakim programista dysponuje. Posunę się nawet dalej, i powiem, że moim zdaniem książki i tutoriale są jednym z mniej ważnych materiałów.
Z czego powinien więc korzystać programista podczas nauki? Krótka lista pozostałych możliwości (w kolejności losowej):
- Oficjalna dokumentacja języka oraz bibliotek - Nikt nie zna tak dobrze zakamarków języka programowania jak jego twórca! Dodatkowo, ów tajemniczy twórca bardzo często udostępnia dokumentacje za równo samego języka, jak i standardowych bibliotek dołączonych do języka. Oczywiście oficjalna dokumentacja jest prawie zawsze w języku angielskim, i niestety od tego nie uciekniemy. Owszem, istnieją translatory, i co bardziej uparte osoby będą z nich korzystać, jednak bardzo szybko jasne się stanie, że jeżeli ktoś chce być dobrym programistą, to język angielski musi znać przynajmniej na poziomie umożliwiającym czytanie dokumentacji. Zachęcam jednak do zainwestowania w siebie i zafundowania sobie kursu języka angielskiego, np. przez Internet (wygodna opcja pozwalająca zaoszczędzić sporo czasu jak i pieniędzy).
- Kod źródłowy innych aplikacji - Przeglądając listingi innych programistów również się dużo uczymy, za równo o języku programowania, jego funkcjach, jak i o samym programowaniu. Obecnie, w dobie Internetu, mamy pod dostatkiem stron na których możemy ściągnąć źródła jakiejś aplikacji, i zobaczyć co ciekawego w niej siedzi. A nuż znajdziemy jakąś ciekawą konstrukcje, czy może w końcu dowiemy się jak poprawnie używać jakiejś funkcji. Warto również zapoznać się z wyszukiwarkami kodu źródłowego, takimi jak Krugle czy Google Code Search.
- Artykuły w (e)czasopismach - Gdy zaczynałem uczyć się programować wychodziło pewne czasopismo o nazwie Bajtek. Kosztowało grosze, a całe składało się prawie wyłącznie z listingów kodu (głównie w BASICu lub w Assemblerze). Szczerze przyznaje że wiele nauczyłem się z artykułów zawartych w tym czasopiśmie. Dzisiaj, niecałe 20 lat później, rynek (e)czasopism się trochę rozwinął, chociaż z bólem serca przyznaje iż nic równie taniego czy przystępnego jak Bajtek dawno nie widziałem. Niemniej jednak warto zainteresować się czy czasem na rynku / w Internecie nie ma czasopisma traktującego o języku którego się właśnie uczymy. Warto rzucić okiem również na serwisy związane z demosceną czy gamedev sceną, czy czasem nie ma informacji o jakimś nowym wydaniu e-zina.
- Wnętrze języka i bibliotek - Dokumentacja może być nieprecyzyjna, jednak kod źródłowy zawsze jest precyzyjny (mimo iż nie zawsze poprawny czy czytelny ;>). Tak więc jeżeli mamy dostęp do źródeł danego języka programowania (kompilatora, interpretera, VM), lub/i do źródeł standardowych bibliotek, rzućmy na nie okiem. Źródła te mogą na początku wydawać się dla nas zbyt skomplikowane, jednak czym szybciej nauczymy się z nich korzystać, tym dla nas lepiej. Często również pliki nagłówkowe różnych bibliotek są bardzo pomocne (szczególnie pisząc w C/C++). Oczywiście osoby zaawansowane mogą dodać reverse engineering do tego punktu.
- Fora, listy dyskusyjne - Każdy problem który my mamy teraz, z dużym prawdopodobieństwem ktoś kiedyś już miał, i prawdopodobnie zapytał o rozwiązanie na jakimś forum lub na jakiejś liście dyskusyjnej. Odpalmy więc naszą ulubioną wyszukiwarkę, i poszukajmy. Przejrzyjmy również tematy na różnych forach związanych z programowaniem, skorzystajmy z wyszukiwarki wewnątrz forum, etc. Natomiast starajmy się nie pytać nikogo o rozwiązanie. W momencie kiedy zapytamy kogoś jak rozwiązać dany problem, sami składamy broń, poddajemy się i przestajemy o problemie myśleć. Może to wielu z was zaskoczyć, ale tak jest na prawdę - czym mniej ktoś prosi innych o pomoc, tym lepszym programistą się staje, a czym więcej ktoś prosi o pomoc, tym mniej samodzielny i bardziej uzależniony od innych będzie. Poproszenie kogoś o rozwiązanie za nas problemu jest straconą okazją do nauczenia się czegoś nowego, i straconą okazją do nauczenia się jak takie problemy rozwiązywać. Zapewniam was że samodzielność w rozwiązywania problemów w programowaniu jest bardzo ważna. Po za tym pamiętajcie, że kto pyta, ten błądzi z innymi ;>
- Książki i tutoriale - Mimo iż celowo umniejszam rangę tychże mediów, to w żadnym wypadku ich nie skreślam. Należy pamiętać o ich istnieniu, i korzystać z nich w miarę potrzeby. Tak na prawdę czym dalej w las, tym bardziej książki zaczynają się przydawać, szczególnie książki wysoko specjalistyczne.
- Kursy, szkolenia, videoarty, konferencje - Jeżeli mamy możliwość in real life bądź przez Internet uczestniczyć w jakimś kursie lub szkoleniu, to skorzystajmy z okazji. Być może pewna kwestia stanie się dla nas jaśniejsza, lub dowiemy się nowych rzeczy. Oczywiście koniecznością jest późniejsze przećwiczenie samemu tego co się nauczyliśmy. Celowo videoarty wrzuciłem do tej, a nie poprzedniej kategorii.
- Konsultacje z bardziej doświadczonymi kolegami - Wcześniej pisałem że nie powinniśmy nikogo prosić o pomoc, więc czemu nagle "wyskakuje" z konsultacjami? Ponieważ czymś innym jest proszenie o rozwiązanie własnego problemu, a czymś innym jest proszenie o radę o lub o komentarz dotyczący naszych zaproponowanych rozwiązań. Jeżeli koniecznie chcemy już z kimś porozmawiać o problemie, to wymyślmy kilka rozwiązań, i przedstawmy je osobie którą uważamy za bardziej doświadczoną - wtedy nie "zwalamy" odpowiedzialności za rozwiązanie problemu na nią (bo sami wymyśliliśmy już kilka rozwiązań), a możemy się czegoś ciekawego nauczyć. Po za tym zapewniam was (jako swojego rodzaju konsultant) iż dużo fajniej rozmawia się z osobami samodzielnymi o ich rozwiązaniach, niż rozwiązuje, zazwyczaj błahe, problemy ludzi uzależnionych od pomocy innych.
Podsumowując, mamy przynajmniej 7 różnych grup narzędzi pozyskiwania wiedzy które możemy używać samodzielnie, oraz jedną grupę w której o radę (nie o rozwiązanie!) możemy poprosić osobę z większym doświadczenie.
4. Jak samodzielnie rozwiązywać problemy?
Problemy w programowaniu zasadniczo są dwa:
1. Coś się nie kompiluje (kompilator lub interpreter wypisują błędy)
2. Coś działa nie tak jak powinno
W pierwszym przypadku przede wszystkim przeczytajmy jaki błąd jako pierwszy wypisał kompilator/interpreter! Większość kompilatorów/interpreterów wypisuje zazwyczaj numer linii w której wystąpił błąd, opisuje (zazwyczaj w bardzo skróconej formie) jaki to błąd jest, i czasami cytuje fragment kodu. Każda z tych informacji jest dla nas cenna (w miarę możliwości należy się dowiedzieć w jakim formacie dany kompilator wypisuje błędy, i co w nich zawiera), mimo iż nie zawsze te informacje są prawidłowe (jest to swoista pułapka na początkujących programistów). Krótkie wyjaśnienie jeszcze czemu piszę o czytaniu tylko informacji o pierwszym błędzie: często zdarza się że dostajemy 2 strony ekranowe błędów, ale w 99% przypadków tylko pierwszy błąd jest prawdziwy, a całą reszta jest wynikiem tego pierwszego błędu. Tak że po usunięciu pierwszego błędu może się okazać iż więcej nie było, lub że z 2ch stron ekranowych robi się 5 linii.
By the way...
On 22nd Nov'24 we're running a webinar called "CVEs of SSH" – it's free, but requires sign up: https://hexarcana.ch/workshops/cves-of-ssh (Dan from HexArcana is the speaker).
Co dalej ?
- Po zapoznaniu się z informacją którą dostaliśmy od kompilatora otwórzmy w edytorze linię którą kompilator wskazuje, i rozejrzyjmy się czy nie widać tam nić podejrzanego. Często błędem jest literówka, nadmiarowa spacja (Python), zagubiony średnik, lub inny prosty błąd składniowy.
- Jeżeli nie widzimy nic oczywistego w danej linii, spójrzmy parę linii w górę - często zdarza się iż np. błąd sygnalizowany w linii 40 wynika z niedokończonego wyrażenia w linii 38.
- Kolejnym krokiem jest wrzucenie kodu lub opisu błędu w wyszukiwarki internetowe / oficjalny help - a nuż ktoś kiedyś o to już pytał, i dostał odpowiedź, lub w dokumentacji jest pokazany przypadek wystąpienia takiego błędu.
- W tym momencie zazwyczaj warto sprawdzić czy na pewno kompilujemy plik który nam się wydaje że kompilujemy - nie raz widziałem sytuację w których okazywało się że błąd poprawiliśmy już 10 minut temu, tylko skompilowaliśmy nie ten plik co trzeba.
- Jeżeli to nic nie da, przekopiujmy kilka linii na chwilę do notatnika, i przepiszmy (ręcznie) je z powrotem do naszego programu - eliminuje to niezauważone przez nas literówki (albo je wyłapiemy przy przepisywaniu, albo "przez przypadek" w locie poprawimy) oraz naprawia przypadki w których edytor z jakiegoś niesprecyzowanego powodu dodał jakiś tajemniczy znak w daną linię kodu (zdarza się to np. gdy kopiowaliśmy jakiś fragment kodu z PDF'a, ze strony WWW, lub z komunikatora internetowego).
- Jeżeli żaden z powyższych sposobów nic nie dał, skopiujmy minimalny fragment kodu w którym sygnalizowany jest błąd do oddzielnego projektu, i spróbujmy tam go skompilować - może się okazać że to jakiś inny fragment kodu (np. zapomniana deklaracja preprocesora) powoduje błąd w tym miejscu. Możemy również spróbować w drugą stronę, tj. usunąć z naszego projektu niepotrzebny kod, i zostawić tylko fragment sprawiający trudności.
- Jeżeli i to nic nie dało, ściągnijmy inną wersję kompilatora/interpretera/środowiska, i zobaczmy czy tam problem również występuje. Ewentualnie poprośmy kolegę aby sprawdził czy u niego również się nie kompiluje.
Szczerze mówiąc chyba nie zdarzyło mi się aby po wyczerpaniu powyższej listy kod nadal się nie kompilował ;>
Co natomiast zrobić w przypadku gdy kod się kompiluje, natomiast program nie działa tak jak byśmy chcieli? Zdebugować!
Debugowanie jest bardzo ogólnym terminem, pochodzącym zresztą od pozbywania się prawdziwych (biologicznych ;>) robaków chodzących wśród lamp pierwszych komputerów i powodujących losowe zwarcia. Tak na prawdę debugowanie wcale nie musi oznaczać skorzystania z debuggera, i prawdę mówiąc z debuggera korzysta się może w 1/3 przypadków. Poniżej prezentuje 4 metody debugowania których ja używam (w kolejności losowej, tzn. każdą z poniższych metod należy znać, i wiedzieć jak stosować; żadne nie jest bardziej czy mniej ważna od innej):
UPDATE: Poniższe metody (jak i trochę innych uwag) są dostępne również w formie videocastów na moim kanale na youtube - playlista Gynvael's Videocast: Debug (PL). Zachęcam do rzucenia okiem :>
1. Print it!
Pierwsza metoda polega na powrzucaniu w kod instrukcji wypisujących dodatkowe informacje (najlepiej ów informacje wypisywać na konsolę lub zapisywać do pliku). Umożliwia to kilka rzeczy:
1. Namierzenie dokładnego miejsca występowania błędu. W tym celu wystarczy powrzucać w różne miejsca w kodzie instrukcje wypisania np. numeru linii, albo różne literki. Następnie uruchamiamy program, i patrzymy które wiadomości i w jakiej kolejności zostały wypisane - dzięki temu dowiadujemy się do którego momentu program dochodzi, które warunki są spełnione, i w które funkcje i zagłębienia program wchodzi. Zazwyczaj zaczyna się na najwyższym poziomie zagłębień, i dodaje z 3-5 "printów" w różne miejsca, a następnie na podstawie informacji które uzyskujemy po uruchomieniu, część "printów" przesuwamy w inne miejsca, za każdym razem zbliżając się o krok do zlokalizowania błędu logicznego.
Np. w poniższym kodzie jedna z funkcji "crashuje" program:
FUNC_A();
FUNC_B();
FUNC_C();Aby dowiedzieć się która funkcja zawiera błąd, wrzucamy kilka printów:
PRINT "przed A";
FUNC_A();
PRINT "przed B";
FUNC_B();
PRINT "przed C";
FUNC_C();
PRINT "po";Uruchamiamy i patrzymy co się wypisało:
przed A
przed B
*** CRASH ***Wiemy więc że wykonanie dotarło do "przed B", ale nie dotarło do "przed C", tak więc błąd jest w funkcji FUNC_B. Idąc dalej przenieśli byśmy "printy" wewnątrz FUNC_B, tak aby namierzyć w końcu dokładną linię błędu.
2. Uzyskanie informacji dlaczego błąd występuje. W tym celu dodajemy "printy" wypisujące wartości zmiennych, wyniki warunków. Jeżeli wiemy że błąd jest w FUNC_B, i wiemy że korzystamy tam z 5ciu zmiennych które mogą mieć wpływ na program, wypiszmy te zmienne. Będziemy wtedy dokładnie wiedzieć co się dzieje, i będziemy mogli zadecydować jak poprawić dany kod.
Rozważmy poniższy kod:
def FUNC_B()
A=4;
B=3;
WHILE(A>B)
B=A/B;
B=B-1;Dodajemy "printy":
def FUNC_B()
A=4;
B=3;
PRINT "przed", A, B;
WHILE(A>B)
PRINT "w1", A, B;
B=A/B;
PRINT "w2", A, B;
B=B-1;
PRINT "w3", A, B;Uruchamiamy, i spoglądamy na output:
przed 4 3
w1 4 3
w2 4 1
w3 4 0
w1 4 0
*** CRASH ***Analizujemy wynik, i już wiemy że błąd polega na tym iż B w pewnym momencie osiąga wartość 0, i następuje dzielenie przez 0. Co z tym teraz zrobimy zależy oczywiście od nas, i od tego jak program ma działać ;>
Metoda "Print it!" jest niesamowicie skuteczną metodą debugowania, i można nią z powodzeniem zlokalizować całą masę różnych błędów, w tym takich które np. nie objawiają się przy włączonym debuggerze. Na prawdę zachęcam do stosowania tej metody!
Na koniec jeszcze jedna uwaga (o której przypomniał mi Makdaam) - niektóre języki programowania w niektórych przypadkach buforują tekst przez chwilę przed jego wypisaniem, przez co jeżeli tekst nie został jeszcze wypisany (tj. nadal czeka w buforze), a aplikacja się "wyłożyła" (np. z powodu krytycznego błędu), to ów tekst nigdy nie zostanie wyświetlony. W takim przypadku należy po każdym dodanym "print'cie" dodać również wymuszenie opróżnienia bufora (zazwyczaj komenda od tego ma słowo 'flush' w sobie; przykładowo, w języku C/C++ w przypadku konsoli piszemy fflush(stdout)).
2. "Na pluszowego misia"
Sprawa jest prosta - znajdujemy jakąś cierpliwą osobę (np. pluszowego misia ;>) lub przedmiot, któremu tłumaczymy, dokładnie, od A do Z, jak działa problematyczny fragment naszego kodu, oraz jak objawia się problem. Z bardzo dużym prawdopodobieństwem podczas tłumaczenia przyjdzie nam do głowy na czym problem polega i jak go rozwiązać.
Domyślam się że pomysł brzmi zabawnie, niemniej jednak zaręczam o jego skuteczności. Na koniec dodam że nazwę tej metody usłyszałem na konferencji IGK, podczas prelekcji Adama Sawickiego.
3. Zabawa w procesor
Bierzemy kartkę papieru, lub otwieramy edytor tekstu, wypisujemy sobie zmienne, i ich wartości, używane w problematycznym fragmencie kodu, po czym linia po linii "wykonujemy" program, czyli na chwilę zamieniamy się w procesor/interpreter. Postępując w ten sposób albo natkniemy się na błąd, albo (co zazwyczaj wymaga połączenia z metodą "Print it!") natkniemy się na różnicę w pojmowaniu kodu przez nas i przez interpreter (tj. interpreter inaczej wykonuje kod niż my myśleliśmy że on to robi).
Tą metodę polecam również przy operowaniu na wskaźnikach/referencjach, do testowania zaimplementowanego rozwiązania po jego napisaniu. Nie raz uratowała mnie przed późniejszym debugowaniem ;>
4. Debugger
I w końcu dojechaliśmy do debuggera, czyli wyspecjalizowanego narzędzia pozwalającego na śledzenie przebiegu programu i wartości zmiennych. Debuggery często przerażają początkujących programistów swoją złożonością, niemniej jednak umiejętność korzystania z debuggera często pozwala wyśledzić pewnego rodzaju błędy dużo szybciej niż pozostałymi metodami. Przykładowo, większość debuggerów potrafi z dokładnością do linii kodu wskazać miejsce w którym program się "wysypał" (tj. rzucił nieobsłużonym wyjątkiem i został zabity przez system operacyjny).
Niestety (a może stety) w przypadku niektórych języków i niektórych przypadków, do poprawnej interpretacji informacji przekazanych przez debugger, wymagana jest znajomość języka niższego poziomu, np. assemblera. Szczerze mówiąc, nie taki straszny assembler jak go malują ;>
Prewencja
Często możemy zaoszczędzić czas po prostu starając się stosować pewne środki prewencyjne. Przede wszystkim zalecam zmuszenie kompilatora do wypisywania jak największej ilości informacji o potencjalnych błędach, czy dodatkowych ostrzeżeń. Początkujący programiści mają niestety tendencje do robienia dokładnie na odwrót - tj. wyłączają lub ignorują wszystkie ostrzeżenia, co niestety powoduje iż zamiast poprawić pewne błędy od razu, zaczynają ich szukać gdy nie jest to już takie łatwe. Ostrzeżeń nie usuwa się poprzez ich ukrywanie, tylko poprzez naprawę kodu źródłowego!
Kolejną metodą jest po prostu testowanie kodu co jakiś czas, lub nawet testowanie każdej napisanej funkcji osobno (patrz testy jednostkowe) - napiszmy krótki programik testowy dla danej funkcji, upewnijmy się że dane wyjściowe są tym czego oczekujemy.
Dobrym pomysłem jest również używanie assertów. Assert'y są pewnymi założeniami, które twórca funkcji uważa za oczywiste, i które ma nadzieje że użytkownik funkcji (którym oczywiście często jest po prostu jej twórca) również będzie stosował. Jeżeli użytkownik funkcji nie zastosuje się do założenia, wtedy assert zasygnalizuje błąd. Warto sprawdzić czy dany język ma mechanizm assertów (ewentualnie jak go emulować), i warto z nich korzystać.
Bardzo częstym błędem, za równo początkujących, jak i zaawansowanych programistów, jest ignorowanie tzw. "obsługi błędów". Większość funkcji w każdej bibliotece może z jakiegoś powodu się nie wykonać poprawnie - w takim wypadku funkcja zasygnalizuje błąd, który powinien zostać wyłapany i odpowiednio obsłużony przez program (np. poprzez wypisanie informacji o zaistniałym błędzie). Informacje o tym jak funkcja sygnalizuje błąd, i jakie błędy mogą się pojawić, znajduje się oczywiście w oficjalnej dokumentacji danej funkcji (tj. w dokumentacji języka, biblioteki, czy systemu operacyjnego). Dodam że nie powinno się starać naprawiać takich zgłoszonych-przez-funkcje błędów na siłę - często powoduje to wprowadzenie kolejnych błędów. Czasami lepiej po prostu napisać użytkownikowi że coś poszło nie tak, i pozostawić jemu decyzję co z tym zrobić.
Kończąc temat rozwiązywania problemów dodam jeszcze, ponownie z własnego doświadczenia, że późnym wieczorem, gdy człowiek jest już zmęczony, pewne oczywiste błędy stają się nie do znalezienia. W takim wypadku wystarczy iść spać. Raz, że mózg nadal będzie myślał nad problemem (patrz "wgląd") i być może obudzimy się znając rozwiązanie, a dwa, że wypoczęty umysł może dostrzec oczywistość która nam wcześniej umknęła.
5. Droga ku doskonałości
Każdy początkujący programista prędzej czy później zacznie się zastanawiać czego nowego powinien się nauczyć lub jakie ćwiczenia powinien wykonywać, tak aby stawać się coraz lepszym. Poniżej prezentuje kilka moich przemyśleń:
1. Programuj, programuj, programuj!
Sprawa jest prosta - programowania uczy się programując, tj. jeżeli chcesz być dobrym programistą, musisz stworzyć na prawdę wiele programów/skryptów. Przykładowo, osoby które uważam za dobrych programistów, codziennie coś piszą. A piszą krótkie programiki do przetestowania nowo poznanej funkcji/biblioteki lub zweryfikowania jak język zachowuje się przy zastosowaniu jakiegoś niestandardowego triku, piszą różne funkcje i biblioteki które być może przydadzą się przy następnym projekcie, rozpoczynają nowe małe, średnie i duże projekty, i następnie dłubią przy nich przez kilka dni/tygodni/miesięcy, testują inne języki programowania by następnie zapożyczyć z nich pewne rozwiązania i użyć ich w ich ulubionym języku, próbują modyfikować kody stworzone przez innych, etc. Dzięki temu każdy z nich zdobywa doświadczenie oraz łatwość w posługiwaniu się językiem, oraz uczy się programować (a tego człowiek uczy się całe życie).
Tak więc jeżeli chcesz zostać dobrym programistą - pisz! Napisz codziennie kilkadziesiąt-kilkaset (a może i kilka tysięcy!) linii kodu.
Ludzie oczywiście są różni - jedni mają tyle pomysłów "co by tu napisać" że muszą wybierać za co się wezmą, a inni mają problem z wymyśleniem jednej rzeczy którą chcieli by napisać. Ci pierwsi mają łatwiej, natomiast ci drudzy muszą starać się poszukać jakiś inspiracji. Źródło inspiracji jest oczywiście kwestią indywidualną. Czasami wystarczy wyjść do parku (np. mnie zawsze po wizycie w parku strasznie ciągnie żeby napisać jakiegoś MMORPG ;>), przejrzeć screeny z gier tworzonych przez innych programistów (polecam http://gamedev.pl), czy otworzyć książkę o programowaniu na losowej stronie. Zachęcam do poszukania własnych źródeł inspiracji ;>
Dodam że warto wyznaczać sobie cele które przekraczają nasze możliwości - tak uczymy się najwięcej. Nawet jeżeli w końcu nie skończymy danego projektu, to i tak dużo się nauczymy w ten sposób. Przy okazji, ważna uwaga - dużo osób rozpoczyna jakieś projekty, które po jakimś czasie porzucają, i nie biorą się za nic nowego, ponieważ męczą ich wyrzuty sumienia że porzucili poprzedni projekt, i chcieli by go dokończyć. To że nie kończymy własnych projektów jest jak najbardziej normalne (czy też "jak najbardziej ludzkie), i najgorszą rzeczą jaką możemy zrobić to pogrążyć się w wyrzutach sumienia. Zamiast się zamartwiać że nie skończyliśmy tamtego projektu, weźmy się za następny - tracimy tak dużo mniej czasu, a i być może po kolejnym projekcie wrócimy do poprzedniego. Oczywiście mimo to należy starać się kończyć projekty, ale gdy już projekt padnie, powinniśmy po prostu wziąć się za następny, i spróbować jeszcze raz ;>
2. Poznawaj!
Przy okazji wyboru języka pisałem już o potrzebie poznawania nowych rzeczy. Jako programiście powinniśmy uczyć się następujących rzeczy:
1. Nowych funkcji i bibliotek
2. Algorytmiki i struktur danych
3. Nowych języków
4. Nowych narzędzi ułatwiających programowanie i debuggowanie (debuggerów, profilerów, systemów wersjonowania, IDE, systemów automatycznego generowania dokumentacji, systemów budowania aplikacji, etc)
5. Nowych "specjalności" programistycznych - np. programowania sieciowego, programowania aplikacji webowych, programowania gier, proceduralnego tworzenia grafiki, systemów operacyjnych, pisania pluginów, etc
6. Systemu operacyjnego - API systemowego, oraz tego jak działa i jak jest zbudowany
7. Nowych metod rozwiązywania różnych problemów programistycznych
8. Słów związanych z programowaniem - na początek wymienię choćby: deklaracja, definicja, prototyp, argument funkcji - ale tych słów jest dużo więcej ;>
9. Etc.
Programowanie to ciągła nauka (to stwierdzenie jest prawdziwe dla każdej działki w której chcemy się specjalizować ;>).
3. Dziel się wiedzą!
W środowiskach akademickich krąży taki jeden dowcip (który postaram się w dość luźny sposób zacytować):
Profesor opowiada koledze:
- Tłumaczyłem ostatnio studentom pewną rzecz. Tłumaczę pierwszy raz, nie zrozumieli. Tłumaczę drugi raz, znowu nie zrozumieli. Tłumaczę więc kolejny, nadal nic. Tłumaczę czwarty raz, sam zrozumiałem, a oni nadal nic...
Dowcip ten zawiera bardzo ważną wskazówkę - pomagając rozwiązać problem innym, sami uczymy się go rozwiązywać. A nawet jeśli wiedzieliśmy już jak to zrobić, to często dowiadujemy się czegoś nowego, lub po prostu utrwalamy sobie trochę informacji. Proszę zauważyć, że jest to dokładnie odwrócenie tego o czym pisałem przy okazji for internetowych - nie prośmy o pomoc, sami pomagajmy - tak uczymy się najwięcej.
Jeżeli uważamy że staliśmy się wystarczająco silni z jakiejś dziedziny, możemy spróbować również napisać jakiś artykuł, kurs czy tutorial. Przy okazji tworzenia takich rzeczy bardzo często musimy przeprowadzić trochę dodatkowych badań jak coś działa, czy poszperać w dokumentacji by upewnić się że faktycznie jest tak jak piszemy - i dzięki temu uczymy się nowych rzeczy, jak i utrwalamy sobie to co już wiedzieliśmy. Dodatkowo, taki artykuł może przydać się w przyszłości jakiemuś mniej lub bardziej początkującemu programiście ;>
Przy okazji tego punktu jednak bardzo ważna uwaga: od braku informacji gorsza jest dezinformacja. Tak więc wypowiadając się na forum czy liście dyskusyjnej, pisząc artykuł czy tutorial, pamiętajmy o tym że jesteśmy przez czytelnika traktowani z dużą dozą zaufania, i że prawdopodobnie wszystko co napiszemy zostanie potraktowane jako "na pewno prawdziwe". Przez to spoczywa na nas duża odpowiedzialność za prawdziwość, prawidłowość i aktualność informacji. Możemy na prawdę dużo zamieszania narobić puszczając w obieg nieprawdziwe informacje, lub po prostu możemy opublikować coś za co później, za 5-10 lat, będziemy musieli się wstydzić.
Pamiętaj, że nie chodzi o to by opublikować artykuł, tylko o to by go napisać. Nawet nieopublikowany artykuł uczy bardzo dużo ;>
4. Znajdź jakieś wyzwanie
Niektórzy ludzie, głównie mężczyźni, bardzo lubią wyzwania. Bardzo motywuje ich współzawodnictwo, konkurowanie z innymi, etc. Jeżeli jesteś takim człowiekiem, wykorzystaj to! Na różnych scenach/forach/serwisach programistycznych często organizowane są różne konkursy (zwane często "compo"), często organizowane po prostu przez nudzących się ludzi (tj. bez nagród). Bierz udział w takich konkursach, dużo można się w nich nauczyć, a także poznać wielu bardzo ciekawych ludzi.
Często również możliwość pochwalenia się innym swoim programem wpływa bardzo motywująco ;>
Koniec, a w zasadzie dopiero początek!
Jeżeli doczytałeś/łaś do tego miejsca, gratuluje wytrwałości i cierpliwości! Dodam że cieszę się podwójnie z tego, gdyż cierpliwość i wytrwałość to bardzo ważne cechy dla programisty ;>
Na koniec chciałbym życzyć Ci powodzenia i wytrwałości!
HF GL!
Gynvael Coldwind
team Vexillium
http://gynvael.coldwind.pl
Notka na temat kopiowania "Poradnika Początkującego Programisty": Niniejszym udzielam zgody na kopiowanie, rozpowszechnianie i publikowanie niniejszego artykułu, pod warunkiem iż forma i treść pozostanie niezmieniona, prawdziwy autor jasno określony, a artykuł będzie prezentowany nieodpłatnie, w pełnej postaci. W przypadku wątpliwości można się ze mną skontaktować, nie gryzę ;>
Comments:
Nie zgodzę się jednak z "szukaniem błędów". Początkujących trzeba od początku przyuczać do korzystania z debuggera. Dlaczego? Bo inaczej zamiast debugować w swoim IDE, debugują oni programy na forum. :) Przy czym wiadomo -- 4 linijki jakiegoś matematycznego algorytmu można załatwić na kartce/z użyciem misia, ale jakiś kod naszpikowany wywołaniami f-cji bibliotecznych/systemowych już nie bardzo.
Co do jezykow na poczatek - mysle ze po dlugiej przygodzie z Pythonem i C#, nauka C/C++ moze byc juz naprawde "hardkorem", niestety z wyzszego na nizszy (nieco) poziom droga jest po gorke IMO... A C++ nie sklada sie z samych wskaznikow, szablonow, wyjatkow i wielodziedziczenia, nauka C++ nie jest IMO wcale o wiele trudniejsza niz innych jezykow, bo nietrzeba wykorzystywac wszystkich mozliwosci jakie daje. A jezeli ktos sie juz nauczy w miare C++, to C#, Python i wszystko inne bedzie mu niestraszne :) Baa, bedzie prawdopodobnie tez lepszym programista w tych nowych jezykach niz ci co siedza z nimi pare latek. O wiele latwiej zrozumiec ze "nie musisz juz sam zarzadzac pamiecia" niz "o, ziomek uwaga teraz sam musisz zwalniac pamiec!", prosciej zrozumiec pojecie referencji znajac ja z C++ i znajac wskazniki, itd... etc...
Hehe z tego co widzę to jednak zgadzasz się z tym co napisałem ;>
Zauważ że debugger jak najbardziej jest wymieniony w tekście ;>
Co do 'debugowania na forum', to o tym pisałem w punkcie apropo for i list dyskusyjnych.
@Jurgi
Thx za linka, nie znałem tego arta ;>
@vashpan
Ad debugger - patrz wyżej ;>
Co do C/C++ etc, to się częściowo zgodzę, a częściowo nie. Zgadzam się że najlepiej byłoby rozpocząć naukę od jak najniższego poziomu, tj. od C lub od Assemblera. Z drugiej jednak strony, na najniższym poziomie jest taki natłok informacji i rzeczy o których trzeba pamiętać, że jeżeli osoba nie jest prowadzona przez bardziej doświadczonego kolegę, to może mieć na prawdę duże problemy żeby przez to przejść. Na 100 osób przypuszczam że 5ciu się to uda zrobić samodzielnie.
Druga sprawa jest taka, że nie można zapomnieć o samomotywacji. Jeżeli programista widzi, że jego aplikacja działa, to go to motywuje. Ucząc się Pythona czy C# programista dużo szybciej będzie więc (moim zdaniem) robił postępy, niż ucząc się assemblera i C.
Kolejna sprawa jest taka że w C i C++ bardzo często przeszkodą są w pewnym momencie wskaźniki - które są na tyle abstrakcyjnym tworem dla początkujących, że często nie obywa się bez pomocy z zew, a tego jak pisałem lepiej na początku unikać ;>
Podsumowując - zgadzam się że z logicznego punktu widzenia lepiej zacząć od C, assemblera czy C++, jednak imho więcej radości i mniej frustracji na początku dadzą programiście Python czy C#. Na C/asm/C++ przyjdzie czas później ;>
BTW. polskojęzyczne LOGO to było coś :D No i grafika żółwiowa :D
Jako zrodlo przydatnych informacji, prezentacji roznych technik czy mechanizmow jezyka, biblioteki lub wspolczesnych popularnych rozwiazan, jak najbardziej.
Sam mam kilka ksiazek, ale nigdy nie kupilem ich z zamiarem nauki, ale raczej jako cos do poczytania w wolnych chwilach, badz poznania spojrzenia i metod wykorzystywanych porzez innych, czy w roli drukowanego manuala ;)
PS:"kto pyta, ten błądzi z innymi" - dobre :-)
Ilu ludzi, tyle poglądów dotyczących uczenia się programowania. Złotego środka nie ma (całe szczęście).
Osobiście książka (jej wersja papierowa), jak dla mnie - jedyna strawna forma wiedzy. Zdaję sobie sprawę, że to "drogie" zabawki, ale...
Popieram Autora w kwestii, że jedynie samodzielne (nawet pod dyktando) pisanie, klepanie, przepisywanie kodu - to doskonała metoda.
A czasy, gdy były wszelkiej "maści" Bajtki - cóż, minęły bezpowrotnie. Gdyby Autorowi udało się w takim samym tempie, stylu, konsekwencji utrzymać stronę, szczególnie solidne podstawy dla początkowych programistów - to byłby strzał w dziesiątkę. Pozdrawiam.
zacząłem od c++, no ale troszkę za wysokie progi to były :P, więc poszedłem do sieci (PHP), po czym wróciłem do C++ i wszystko zrobiło się znacznie łatwiejsze :)
co do jezykow na malym atari - we wspomnianej przez Jurgiego gazecie byl tez kurs fortha, dzieki ktoremu zakochalem sie w odwrotnej notacji polskiej ;)
Opisane prosto i można rzec łopatologicznie, czyli tak w sam raz dla początkującego, który nie wie jak to wszystko się kręci.
A ogólnie to pamiętam jak zaczynałem moją przygodę z programowaniem w interpretowanym języku jakim jest PHP.
Późniejsza przesiadka na C/C++ stała się łatwa, ponieważ jakby nie mówić oba języki są podobne.
Najbardziej mi się podobał sposób szukania błędów na pluszowego misia ;).
Używam go czasami, ale to jakoś samo z czasem się mi wykształciło i nie wpadłbym żeby to tak nazwać.;)
Życzę więcej tak udanych artów.;)
Dodatkowo co mogę napisać, to to, że na konferencji Informatyka w Edukacji, prof. Diks przybył razem ze swoją małą ekipą studentów i opowiadali o uczeniu programowania i właśnie tam pokazali fragment pythona jako język, którego można uczyć bez większej znajomości składni itp. Na UW robią aplikację do ładnego i szybkiego pisania w tym języku (raczej do uczenia się, np. fragment funkcji i na dole pasek do uruchamiania jej). Dodatkowo ta aplikacja miałaby podobnie działać, ale z wykorzystaniem języka C++. Niestety nie pamiętam jak ta aplikacja ma się nazywać.
Konferencja była skierowana głównie do nauczycieli szkolnych i polegała bardziej na próbie rozwiązania problemu zmotywowania uczniów do pisania programów i nie poddawania się od razu z myślą "programowanie jest trudne". Twój artykuł wydaje się, jakby był skierowany do osób już zmotywowanych, ale i tak może się przydać każdemu zapewne (chociaż długi :P).
I na koniec słowo bezpośrednio ode mnie (tzn. podzielę się z wami moimi przemyśleniami :P): jest jedna książka, którą bardzo sobie cenię, która uczyła mnie nauki programowania w Turbo Pascalu. Jej tytuł to: "Turbo Pascal w zadaniach z komentarzem" (Danuta Glaza, Elżbieta Krasowska). Opisuje ona w przystępny sposób, w sumie podobnie do tego co Ty pokazałeś Gynvaelu, działanie programu - kod programu po lewej, a po prawej wytłumaczenie co dana linia robi. To jest chyba najlepsza książka, która UCZY programować, jaką miałem w ręku. Drugą książką jaką mógłbym polecić to "Zrozumieć Asembler" (Jeff Dunteman). Ta druga książka bardzo pomogła mi zrozumieć działanie komputera od podstaw (kilka pierwszych rozdziałów), co bardzo, ale to bardzo mocno, przydało mi się w nauce/rozumieniu/opanowywaniu innych języków :).
/* Wywaliło mi poprzedni komentarz, czy są one moderowane? */
@funny images
Rotfl ;D Nie spodziewałem się 'takiego' odkrycia jednego z ukrytych obrazków ;D
Moje zastrzeżenia (uwagi):
Wg mnie za mały nacisk jest na projektowanie programów.
Należało by zaznaczyć, iż algorytmy i struktury dany są wręcz fundamentami programowania (słowo algorytm zauważyłem dopiero w pkt 5.2. "Poznawaj").
Większość ludzi myśli, iż poznawszy dany język programowania umie wiele (lub będzie umiała).
Innym ważnym aspektem (godnym podkreślenia w artykule) jest rozpisanie problemu na kartce, analiza i podział na mniejsze części.
Osoby początkujące zazwyczaj rzucają się do pisania kodu ledwo oderwawszy wzrok od kropki na końcu zdania opisującego problem.
Chciałbym takżę dodać (wg mnie!), iż dobrym rozwiązaniem mimo wszystko było by przyswojenie Pascala na poziomie chociażby podstawowym.
Uwagę tą wysunąłem z powodu, iż wielu autorów książek, kursów implementuje dany algorytm w Pascalu.
Nic innego nie wpadło mi do głowy ;)
Jedyna rzeczą jakiej mogę załować to, to, iż dopiero teraz moim oczom ukazał się taki ciekawy i ważny artykuł, a nie wtedy gdy zaczynałem przygodę z programowaniem.
Jeszcze raz muszę podkreślić i docenić Twoją pracę włożoną w ten poradnik. :)
Super art!
Keep on!
albo fflush).
Poza tym poradnik godny polecenia :)
Do każdego programu który napisaliśmy, musiał być dołączony schemat. Muszę przyznać, że nienawidziliśmy faceta za to. A on sam mówił, że dostrzeżemy zalety tego na długo po tym jak opuścimy tą szkołę. I miał kurde facet rację. Dzięki temu podejściu dość szybko nauczyliśmy się projektować program od ogółu do szczegółu.
Po takim przeszkoleniu, już na studiach, nauka C, a potem C++ nie stanowiła problemu. bardzo szybko zacząłem traktować język programowania jako narzędzie - schemat działania programu (przynajmniej do pewnego stopnia szczegółowości) jest prawie zawsze taki sam - niezależnie czy jest napisany w C/C++, C#, asm, czy czymś innym.
PS. Nie ma ktoś chwili wolnej? Przydałby mi się jakiś fachowiec, który mógłby mi wytłumaczyć w miarę sensownie te %&!*$% wskaźniki ;P
Zddecydowanie się z Tobą zgadzam. Prowadząc już prawie 3 lata warsztaty techniczne, np. redhatowe, bardzo często na kursach zdarza się, że sam dowiaduję się czegoś nowego, bądź dochodzę do jakiejś nowej funkcjonalności - tylko przez to, że student zadaje np. niezbyt przemyślane pytanie - na pierwszy rzut oka wydawałoby się wręcz bezsensowne...
Wtedy na twarzy pojawia się zdziwienie - bowiem człowiek myśli, że co nieco wie na dany temat, a tu się okazuje, że można wiedzieć więcej i więcej i więcej ;)
Pozdro!
p.s. skąd ty bierzesz tyle czasu na pisanie tak długich i zarazem konkretnych tekstów dla społeczności? :D
p.s.2 "Profesor opowiada koledze:
- Tłumaczyłem ostatnio studentom pewną rzecz. Tłumaczę pierwszy raz, nie zrozumieli. Tłumaczę drugi raz, znowu nie zrozumieli. Tłumaczę więc kolejny, nadal nic. Tłumaczę czwarty raz, sam zrozumiałem, a oni nadal nic..." - ekstra :D na pewno kiedyś zapodam na szkolonku :D
Trzy drobne zastrzeżenia:
1. Wspominasz często o czytaniu dokumentacji, ale nie zachęcasz do jej tworzenia. Brak, mała ilość lub nie-aktualna dokumentacja jest często problemem, zarówno dla firm jak i przy tworzeniu projektów, którymi mamy zamiar się dzielić z innymi. :)
2. Kładłbym duży nacisk na pisanie kodu łatwego do serwisowania/rozbudowy. Kod programu jest częściej czytany i modyfikowany niż tworzony od zera. Programiści rzadko pracują samodzielnie nad całym projektem. Tworzenie czytelnego i zrozumiałego kodu jest pierwszym krokiem do nauki pracy w grupie. Ten punkt można utożsamić z dzieleniem się wiedzą, o czym pisałeś.
3. Należałoby uprzedzać ludzi przed tworzeniem na początek kombajnu robiącego wszystko. Z mojego doświadczenia wynika, że dobrze jest zacząć od oczywistego rozwiązania, a optymalizacją, uogólnieniem itd. kiedy mamy już żyjący organizm, który pozwoli nam zrozumieć lepiej problem jakim się zajmujemy.
Na koniec link opisujący ciekawe metody wyłapywania błędów w Pythonie:
http://aymanh.com/python-debugging-techniques
Pozdr.
ad.1 Patrz tytuł: "Poradnik Początkującego Programisty". Wyobrażasz sobie, żeby początkujący tworzyli dokumentację? Chciałbyś z niej korzystać? Na pisanie dokumentacje przyjdzie czas.
@Gyn
Poradnik dla początkujących jest bardzo dobry. Może nareszcie zmotywuje mnie to do nauki.
A co do Pythona na początek, to równie dobrze może być to Perl.
Wyobrażam sobie, że jeżeli nie zaczną uczyć się pisania dokumentacji teraz to będę z niej musiał korzystać kiedy zaczną się *uczyć* ją pisać podejmując pracę.
A mając do wyboru, projekt początkującego programisty bez dokumentacji w stosunku do takiego z istniejącą ale bardzo niskiej klasy. To bez zastanowienia wybiorę ten drugi wariant.
Źle zrozumiałem o co Ci chodziło z tą dokumentacją. Mój błąd.
Masz jak najbardziej rację, żeby tworzyć dokumentację :).
„Natomiast starajmy się nie pytać nikogo o rozwiązanie. W momencie kiedy zapytamy kogoś jak rozwiązać dany problem, sami składamy broń,”
Tak, ale jest tutaj cienka granica po której przekroczeniu popadamy w syndrom który ja nazywam „syndromem Zosi Samosi”. Taki syndrom prowadzi do tego, że jeżeli dana osoba nie jest w stanie rozwiązać zagadnienie sama to je po prostu po jakimś czasie zniechęcona porzuca. Oczywiście z takim podejściem wiele stracimy, bo być może wystarczyło jedno zdanie w ramach podpowiedzi i sprawa była by jasna ;). Ja bym proponował zastosować następujący mix:
starać się rozwiązać wyzwanie (tak tak wyzwanie ,problemy zostawmy systemowi edukacji :P ) samemu, aż do wyczerpania własnych pomysłów , jeżeli się nie uda ,powróci do sprawy na drugi dzień i spróbować ponownie. Gdy nasza starania okażą się nie wystarczające warto wtedy sięgnąć po poradę kolegi/forumowiczów itd. prezentując im swoje dotychczasowe metody i sposób rozumowania. Oczywiście zawsze prosimy o wędkę nie o rybe! ;).
"C czy C++ okazały się za trudne, i zniechęciły potencjalnego programistę do dalszego rozwoju w tej dziedzinie.
Oczywiście należy zwrócić uwagę na to czy kolega mówi o języku, czy może mówi czy go lubi czy nie ;>"
Wychodząc poza kontekst nauki wybranego języka programowania, uważam że określanie czegokolwiek w kategoriach łatwe/trudne jest tragedią. Oczywiście zdarza mi się słyszeć takie hasła bardzo często od ludzi którzy z nauką mają nie wiele wspólnego lub są po prostu pseudo nauczycielami w sensie ogólnym. Takie rozumowanie może rzeczywiście blokować na starcie. Zdrowszym podejściem jest rozróżnianie kwestii w kategoriach bardziej lub mniej złożonych i wtedy wręcz logicznie implikuje nam się, że kwestie złożone będą wymagały od nas większej ilości czasu, a te o mniejszej złożoności analogicznie mniej. IMO taki sposób rozumowania daje większy komfort psychiczny ;) ,
a przecież potęga tkwi w sposobie postrzegania…no niektórzy nazywają to talentami ;).
"Podsumowując, początkujący programista nie powinien czytać książki / tutoriala od deski do deski.
Przede wszystkim powinien przepisać/przeanalizować listingi,
a po za tym powinien próbować z książki korzystać jak z leksykonu lub zbioru podpowiedzi."
Heh metoda przepisywania listingu jest jak najbardziej ciekawa, chociaż przyznam szczerze, że jej nie stosowałem, ale !!!Śmiać mi się chcę teraz, bo obecnie na laboratorium z Web app’ow DR wyznaje identyczne podejście :D. No gdybym je miał stosować jakieś 5 lat temu to by było ok. dzisiaj jestem po prostu zażenowany.
Jak najbardziej zgodzę się, że nie należy na początku czytać ksiązki od deski do deski
, zresztą wiele mądrzejszych autorów wspomina o tym i proponuje opuścić dany rozdział czytelnikowi, który dopiero rozpoczął swoją przygodę z programowaniem czy też czyta tę książkę po raz pierwszy. Warto natomiast tak jak zresztą wspomniałeś traktować książkę jako
leksykon do którego warto zerkać. Czyż nie jest to odmienne podejście w większości przypadków stosowanych w szkołach :D? Przeczytać ! Zapamiętać! Wyrecytować! Hahahha..
Po to masz książkę pod ręką żeby z niej skorzystać, a przy sukcesywnym i regularnym korzystaniu z niej wiedzą w niej zawarta „przyswoi się sama”. Baw się!
"Dodam że warto wyznaczać sobie cele które przekraczają nasze możliwości - tak uczymy się najwięcej."
Zgadza się, ale warto uważać żeby nie przesadzić. Znamy przecież przypadki gdzie człowiek który startuje tak naprawdę rozpoczął przygodę z programowaniem ,poznawaniem systemu stwierdza, że napiszę własny system operacyjny czy np. rootkit’a. Czy tak można? Można!
Wszystko można, bo wszystko jest kwestią czasu ;). Pytanie jest czy już na starcie masz zdrowe odpowiednie podejście do bardziej złożonych projektów? Bo jeżeli nie, to będziesz się motał, wiercił zanim jeszcze wystartujesz i starał się od razu ogarnąć całość, co w przypadku kwestii złożonych jest podejściem po prostu błędnym. Polecam tutaj podejście prezentowane przez filozofię kaizen: http://pl.wikipedia.org/wiki/Kaizen .
" Przez to spoczywa na nas duża odpowiedzialność za prawdziwość, prawidłowość i aktualność informacji.
Możemy na prawdę dużo zamieszania narobić puszczając w obieg nieprawdziwe informacje,
lub po prostu możemy opublikować coś za co później, za 5-10 lat, będziemy musieli się wstydzić."
Jak najbardziej jestem za tym żeby nie szerzyć herezji. Bywa tak, że ktoś po przeczytaniu (nie koniecznie z całkowitym zrozumieniem) pewnej literatury czuje się na siłach żeby szkolić innych wyrządzając im tak naprawdę tylko krzywdę.
Jeżeli chodzi o wstyd to jest to straszna choroba :D Proponuję na nią nie chorować.
„za 5-10 lat, będziemy musieli się wstydzić."
Jak już to niech się wstydzi ten który był i napisał to 5-10 lat temu a nie ten który jest dzisiaj, TERAZ! To już inny człowiek :D.
A ja nie polecam perla - zwlaszcza ze bardzo latwo zrobic sobie zle nawyki.
Duzo prosciej programuje sie w perlu znajac pythona/php niz w pythonie/php znajac perla.
Pozatym kod w perlu bardzo czest jest niezrozumialy ( jak sie uzywa "magicznych elementow perla" )
W firmie niedawno zostal przepisany glowny framework na pythona z perla - ale przez prrogramistow perla ( na nieszczescie )
Po jakism czasie zatrudniono maniaka pythona - nie dosc ze skrocil kod o 40% to przyspieszyl o 50% - poprate testami wydajnosciowymi ( mamy do tego klaster trzech DL360 z jmetterem :] ) :) :)
W perlu jest bardzo duzo pulapek - np testowanie na istnienie klucza w zaglebionym hashu - jesli cala taka galaz nie istnieje to zostanie stworzona - sic!
dzięki
Przykład kodu:
HAI
CAN HAS STDIO?
I HAS A VAR
GIMMEH VAR
IZ VAR BIGGER THAN 10?
YARLY
BTW this is true
VISIBLE "BIG NUMBER!"
NOWAI
BTW this is false
VISIBLE "LITTLE NUMBER!"
KTHX
KTHXBYE
jeżeli pozwolisz to podlinkuje go na swoim blogasku :)
Oczywiście tekst bardzo ciekawy jak dla mnie - początkującej programistki :)
Poza tym chciałem serdecznie podziękować za podzielenie się swoją wiedzą.
Przy nauce programowania jak zresztą przy każdej czynności najważniejsza jest motywacja i to ona potrafi czasem zrobić więcej niż wszystkie książki czy kursy razem wzięte. Nie daje, co prawda gotowej wiedzy na tacy, jednak przy odpowiedniej motywacji wiedzę tą już posiadamy, tylko, że za jakiś czas w przyszłości :)
Połącz hobby z nowym tematem, chociażby programowaniem i masz wydajny silnik napędowy do dalszego rozwoju.
Dla mnie momentem przełomowym była sytuacja, w której padł mi stary dobry Segate 1.2GB. Odzysk danych przy otwartym talerzu przyklejonym na super glue, (bo się obluzował) i zrobienie z części danych płytki bootujacej z ramdrive (32mb! :)). Zmieścił się quake1 (tak, to tamte czasy) chyba tasm, dos nawigator, hiew. Później z kafejce namierzyłem archiwum z kodami źródłowymi wirusów + Ralf Brown's interrupt list = orgazm gałki ocznej. Tak zacząłem przygodę z asm i językami programowania. Motywacja może mało szlachetna natomiast zainteresowania z czasem się zmieniają a wiedza zdobyta pozostaje do wykorzystania w lepszych okolicznościach.
Wszystkim zainteresowanym nauką programowania życzę wytrwałości i odnajdywania motywacji w otaczającej rzeczywistości.
Dr. House takiej uzywal, gdy mu sie team rozsypal, role pluszowego misia pelnil tutaj wozny pracujacy w szpitalu, 'Doktor Zmywak' ; p
chociaz on nie wspominal nic o bledach wywalanych przez kompilator, a usilnie staral sie dopasowac tocznia do danych objawow ; )
Najbardziej do mnie przemówiły te słowa : "kto pyta, ten błądzi z innymi". Nie wiem Gynvael czy to są Twoje słowa czy kogoś innego, ale zacytowanie ich w tym poradniku było genialnym pomysłem ;) Aż sobie je wypisałem na kartkę i nakleiłem na monitor :] Ogólnie najlepszy tekst o nauce programowania jaki czytałem, z pewnością wielu młodych programistów znajdzie w nim oparcie, zupełnie jak ja ;)
(ps poprzedni był dobry więc czemu?)
Trochę mi brakuje kilku zdań o środowisku programistycznym. Zdaję sobie sprawę, że to zależy od języka, ale może jakieś sugestie, np. maksymalnie prosty czy właśnie od razu przyzwyczajać się do "kombajnu"?
Co komentujący poleciliby początkującemu w c++?
Zacznę od tego, że źle robią na studiach, zaczynając od czystego c, potem asm, cpp i dopiero języki wyższych poziomów - sporo studentów zraża się wtedy do programowania do tego stopnia, że przestaje w ogóle próbować programować, rzuca studia albo zalicza na cudzym kodzie lub przypisując się do innej grupy tych, którzy kawałek kodu mają- ocena wspólna, wiadomo. To, że warto zacząć od czegoś lżejszego, jest dobrą uwagą.
Ad pythona - nie przebrnęłam nawet przez tutorial (wywaliłam się na princie^^), javą zaczęłam rzygać na studiach ale c# - no cóż, wyraz młodzieńczego buntu przeciw kościołowi javy przerodził się w moje zamiłowanie do tego języka (jeśli można tak powiedzieć). Idzie pisać "na pałę" nie martwiąc się niczym, a potem - w ramach coraz większego poznawania z czym się je - poprawiać aż... aż się będzie jeszcze chciało.
Mam nadzieję, że się nie obrazisz tego, że się przyczepię paru rzeczy, ale sądzę, że mogą się młodym przydać.
"mimo iż istnieje implementacja open source .NET - Mono, to jednak jest ona zawszę o krok do tyłu względem oficjalnego wydania .NET, które dostępne jest jedynie na platformę Windows". Piszesz o Mono, bo jest od Oracle, a o Roslyn (również darmowy- nawet opensource i również c#) to już nie, bo głęboki związek z pewną firmą? :) Z resztą w międzyczasie cały .net stał się open source (nieco ponad rok temu).
Dokumentacja dostępna jest na MSDN, z którym trzeba się jednak na początku zapoznać, gdyż nie zawsze jest intuicyjny, ale po zapoznaniu się z nim, staje się on niezastąpiony <-- jak się jest początkującym, rzadko się siedzi na MSDN, serio. Codeplex tak, stack overflow, dotnetperls czy codeproject - czasami na polskim codeguru czy coś. Zwykle wystarczy zmodyfikować to, co się tam znajdzie i nie trzeba się uciekać do MSDNa który przykłady do niektórych elementów platformy ma długie, zawiłe i trzeba się wgryźć by wybadać o co chodzi.
Pisałeś o przepisywaniu kodu. Moim zdaniem (a jestem c#-owa) nie ma sensu go przepisywać literka po literce - IDE podpowie, resharper podpowie jeszcze więcej i zacznie to nawet wyglądać. Więcej idzie się nauczyć po prostu klepiąc. Chociażby właśnie podskubać kawałki kodów z wymienionych portali, zmodyfikować do swoich celów, zobaczyć jak jaka modyfikacja działa, podebugować trochę (bo nie zawsze zadziała), nauczyć się że komunikaty bywają mylne i często się szuka nie tam gdzie trzeba... Może nie będzie to Twój sposób (poznać jak wszystko działa zanim jeszcze zacznie działać), ale z pewnością jest efektywny - a jak wiadomo- im szybciej ktoś zobaczy, że "to działa" tym bardziej prawdopodobne, że się nie zniechęci tak szybko (u nas często się mówi o tzw. efekcie WOW).
Ad książek - dobre książki w tych tematach to kilkutysięczne krowy - wiadomo że ich napisanie trwało długo, więc zanim je wydano już były lekko przedawnione, a więc można spokojnie powiedzieć, że książka techniczna to ładny prezent i świetna pozycja na półkę ale w praktyce zagląda się do nich rzadko. Swoją drogą - jak świetnie zauważyłeś - "początkujący programista nie powinien czytać książki / tutoriala od deski do deski" - prawda jest taka, że tego się nie da robić. Pierwsze 80 stron to zwykle historia języka, jakieś pierdu pierdu, potem zaczyna się ciekawa część - ta gdzie są listingi - i tylko to jest fajne;P Podpatrywanie, że "można jeszcze tak". ", ale kod i tak będzie w języku programowania którego się uczymy, z nazwami pochodzącymi z języka angielskiego" -- uwierz, ostatnio widziałam język do programowania kontrolerów (wewnętrzny) z keywordami po niemiecku (nightmare alert)
Przepisywanie jest nużące (a skoro coś nuży nawet ludzika z autyzmem, to ADHDowiec pewnie by walnął to wszystko w cholerę w przeciągu pierwszej połowy godziny), szybko staje się mechaniczne i bezmyślne- już lepszy efekt daje skopiowanie krótkiego gotowca z www i próba popsucia go w każdym możliwym miejscu, wywołania go w każdy możliwy sposób i robienie z nim cudów wianków.
Ad "Wnętrze języka i bibliotek" - święty ignucy, serio wysyłasz ludzi do czytania source kompilatora albo chociaż nagłówków? O matko, jak dobrze że za mnie to robi edytor na tyle, że widzę czego i gdzie mogę użyć. Swoją drogą - z open source'ówek polecam przepuścić kod przez doxygen - szybko dowiemy się (nawet jak w komentarzach nie było helpa) co jest w której klasie bez przeglądania ogromu kodu (nawigacja po wygenerowanych htmlach na przykład).
.NET jest od pewnego czasu oficjalnie opensource, może warto poprawić ten wpis?
https://referencesource.microsoft.com/ <- oficjalny kod źródłowy .NET
Pozdrawiam.
Z BOGIEM
Add a comment: