Czytając artykuły doradzające, jak uczyć się programowania dochodzę do wniosku, że ich autorzy początkującymi programistami już od dawna nie są i stąd nie pamiętają często problemów, z którymi ja, początkujący programista, borykam się na co dzień. Postanowiłem więc opisać sprawę z mojej perspektywy.
Programowanie może być sztuką bardzo frustrującą. Malarz namaluje obraz i tyle. Pisarz napisze książkę i tyle. Nawet inżynier może źle wyliczyć siły, a wciąż most zostanie wybudowany. Oczywiście obraz może zostać skrytykowany, książka zalegać na półkach, a most się zawalić. Program jednak, oprócz tego, że może jednocześnie: zostać skrytykowany, słabo się sprzedawać i się zawalić („scrashować”, spowodować poważną awarię), to jeszcze wiąże się z dodatkowym problemem programisty: bugi.
O pluskwach można by mówić dużo - ja na przykład kiedyś przez dwa tygodnie (z przerwami, bo ile można) walczyłem z Heisenbugiem, a w końcu okazało się, że bug był spowodowany przez Adobe (mowa o Actionscript) – to trochę tak, jak w plotce, której nie udało mi się potwierdzić: w wyniku pomyłki geodetów, rury tunelu La Manche nie zeszły się, przez co geodeci popełnili samobójstwo, po czym okazało się, że to tablice nie były wystarczająco dokładne, a winy geodetów w tym żadnej nie było.
Do czego zmierzam? Programowanie może być bardzo frustrujące. Ze względu na dużą konkurencję, programowanie polecam tylko osobom z zapałem, dla których rzeczą normalną będzie zacząć od programowania, a nie czytania jak programować dobrze (czy urodzony rajdowiec zaczął przygodę z wyścigami od czytania encyklopedii o samochodach?). Ponadto lepiej nie znać dobrych praktyk w ogóle, niż stosować je, ale nie wiedzieć z czego wynikają. Ważne jest, aby z dobrych praktyk korzystać, zamiast być przez nie ograniczanym.
Na tym ten artykuł mógłbym zakończyć, bo wszystkiego co poniżej programista prędzej czy później dowie się na pewno. Jednak jako bonus dla tych, którzy chcą uczyć się na cudzych błędach:
Wielu potencjalnych programistów pyta się o to, jaki język programowania jest najlepszy, po czym, nie uzyskawszy konkretnej odpowiedzi, traci zapał. Moja rada: wybierz jakikolwiek język programowania, a jeżeli Ci się nie spodoba, to spróbuj z kolejnym. Nie korzystaj z frameworków, nie szukaj dobrych praktyk i poprawnych rozwiązań.
Technologii i rozwiązań do wzięcia pod uwagę przed rozpoczęciem danego projektu jest tyle, że żaden nowy programista sobie z tym nie poradzi. Natomiast zmiana języka programowania dla osoby początkującej jest trywialna (taka migracja może być bolesna dopiero dla programisty zaawansowanego, który już mocno przyzwyczaił się do nazw funkcji, zewnętrznych bibliotek, społeczności itd.; przynajmniej tak słyszałem, bo ja jestem początkujący)
Z perspektywy Polaka są dwa Internety: polski i światowy. Ten drugi posługuje się językiem angielskim, jest zawsze na czasie, a ze względu na większą ilość użytkowników, serwuje również bogatszą i, w wyniku konkurencji, lepszą jakościowo treść. [żaden wyjątek od reguły nie przychodzi mi do głowy, choć mogą takie istnieć]
Bolączką polskich źródeł wiedzy są też problemy z tłumaczeniem, jak tłumaczenie nazw własnych (np. stage --> stół montażowy).
Niewątpliwie każdy musi nauczyć się podstawowych koncepcji, jak pętle, instrukcje warunkowe itp., ale w trosce o swoją motywację, po przeczytaniu jednej książki/kursu, powinieneś zerwać z konwencją przepisywania kodu z książki i zacząć programować samodzielnie.
Zastanów się nad tym, co już potrafisz i co z tych narzędzi potrafisz stworzyć. Nie rób kalkulatora czy gry platformowej, tylko dlatego, że są to rzeczy, które każdy programista powinien kiedyś wykonać. Wymyśl projekt czegoś, z czego chciałbyś skorzystać (czy w to zagrać) ograniczając się tylko do dwóch rzeczy:
Kto wie, być może Twój pierwszy projekt okaże się wielkim sukcesem na miarę Flappy Birds (gra wyjątkowo prosta, a jednak się sprzedała).
Zapewne każdemu programiście zdarzyło się zabrać za coś, aby w pewnym momencie odkryć, że jest to niewykonalne, głupie, albo zajmie za dużo czasu. Niektórzy też zabierają się za programowanie swojego pomysłu, po czym stwierdzają, że program nie działa i nie wiedzą jak to ugryźć.
Wyobraź sobie, lub narysuj jak wyobrażasz sobie swój gotowy projekt od strony jego użytkownika: jak ma działać, jak ma wyglądać interfejs (przyciski, pola wprowadzania itd.) do czego ma służyć, jakie będą jego ograniczenia i jakie będą największe problemy podczas tworzenia tego programu. Wtedy rozplanuj modułową strukturę programu i sprecyzuj konkretnie, co dany moduł ma przyjmować na wejściu, i jaki będzie algorytm, przekształcający wejście na wyjście. Wtedy, w razie problemów, możesz po prostu wykonać tzw. „unit test”, czyli sprawdzić po kolei, który z modułów nie wykonuje swojej pracy jak należy. („Dziel i zwyciężaj”)
Wiele osób, czytając powyższą radę z punktu 5. wpada w pułapkę tworzenia zaawansowanego planu swojej aplikacji. Pamiętaj, że Designdoc tworzy się, w dużych firmach i/lub aby przedstawić pomysł potencjalnemu inwestorowi, który nie przeznaczy pieniędzy dla kogoś, kto w swoim mniemaniu ma fajny pomysł i nie oferuje nic więcej. Jest cała filozofia, walcząca z przeprojektowywaniem.
Moim zdaniem najlepszy designdoc to po prostu wykonany na szybko, prowizoryczny program z obrazkami zastępczymi. To najprostszy sposób uzmysłowienia sobie zagadnień opisanych w pkt 5.
Komentarze tak samo jak designdoc, są w Internecie zbyt często chwalone. Spotykałem się nawet z opiniami, że komentarze w ogóle powinny być zabronione, bo powinno się programować tak, aby kod programu był wystarczająco czytelny. Myślę jednak, że początkujący programista jest skazany na to, że po kilku miesiącach czy latach będzie już rozumował całkiem inaczej (dzięki programowaniu) i nie będzie w stanie zrozumieć swojego starego kodu. Komentarze są więc dla niego dobrą rzeczą, o ile pamięta, żeby nie pisać komentarzy z myślą o obcej osobie, bo najprawdopodobniej kodu źródłowego jego pierwszych programów nikt nie będzie czytał. W punkcie tym nie chodzi mi o to, że komentarze w jakiś sposób pogarszają kod, ale zabierają początkującemu programiście sporo czasu, energii i uwagi.
Plaga wśród początkujących programistów. Łatwiej dodać po linijce kodu do istniejących funkcji, niż stworzyć nową funkcję (w sumie nie rozumiem dlaczego, chociaż sam tak robiłem). Taki kod ciężko się przegląda, ciężko debuguje i ciężko zmienia. Dla swojego dobra naucz się dzielić program na pliki, klasy, funkcje.
Wielu początkujących programistów pisze swój program w notatniku, a następnie odpala kompilator (albo otwiera stronę WWW w przeglądarce). Jeżeli program nie działa (lub nie kompiluje się), to wystarczy skasować ostatnią zmianę i podzielić ją na mniejsze fragmenty, które dodaje się sukcesywnie, obserwując, który fragment powoduje błąd. Da się tak programować, ale bugi okażą się bardzo demotywujące. Jednak wystarczy wygooglować jak debugować w wybranym przez siebie języku programowania, aby zmienić swoje doświadczenia z piekiełka na zabawę.
Optymalizacja powinna być ostatnim etapem tworzenia kodu, chyba, że w celu optymalizacji planujesz istotną zmianę sposobu działania modułu, albo jeżeli nie wiesz, czy uda ci się moduł zoptymalizować, a w razie niepowodzenia cały projekt trafi do kosza.
Niektórzy wpadają w pułapkę zbędnej optymalizacji, co wynika z przestarzałych kursów, albo stosowania wobec pojedynczych zmiennych, czy małych tablic, rad dotyczących dużej liczby zmiennych - np. ktoś może doradzać używanie zmiennych typu TINYINT w bazie danych dla oszczędności miejsca, podczas gdy w przypadku pojedynczych zmiennych w programie doprowadzi to tylko do oszczędności kilku bajtów, kosztem błędów przekroczenia zakresu (out of range), niezgodności typów lub niepotrzebnych kombinacji w celu zmniejszania wartości. Przykra prawda jest taka, że kiedyś z ciekawości zainstalowałem w Chrome wtyczkę, która reklamowała się tym, że nic nie robi. Faktycznie, nie robiła absolutnie nic, a zajmowała 5 MB pamięci (co prawdopodobnie jest winą Google, a nie twórcy wtyczki). Powinno to skłonić początkujących programistów do zastanowienia się nad swoimi optymalizacjami.
Autorem publikacji jest Adam Jesionkiewicz
Hej, jesteśmy na Google News - Obserwuj to, co ważne w techu
![[Od Czytelnika] Jak wypełnić kontrakt i strzelić sobie w stopę pokazuje T-Mobile](https://antyweb.pl/img/359/204/fit/content/uploads/2014/10/wifi.jpg)
