Lubię takich ludzi jak Krzysztof (Notatnik Programisty), którzy dzielą się swoją wiedzą nie oczekując nic w zamian. Postanowiłam, więc go przepytać i choć długo czekałam na jego odpowiedzi, nie żałuję. Z resztą, zobaczcie sami.
Marta Bąk, Marketing i Biznes: Krzysztof, skąd pomysł na notatnik programisty?
Krzysztof Jelonek, Notatnik Programisty: Kilka lat temu, w wolnych chwilach grywałem w grę Arma 2 na modzie Dayz Epoch. To taki symulator pola walki rozszerzony elementy survivalowe i craftingowe. Mieliśmy wtedy zgraną grupę kilku trzydziestolatków na jednym z polskich serwerów. Jednym z elementów rozgrywki była możliwość zabezpieczenia swoich obiektów za pomocą kłódek z trzycyfrowym kodem. Klik na jednym z trzech rzędów cyfr powodował ich przesunięcie o jedną pozycję.
Ponieważ najcenniejsze przedmioty można było znaleźć w obiektach przeciwników, niektórzy zaczęli się zbierać w grupy próbując łamać kody metodą brute force. Np. pierwsza osoba przejmowała zakres kodów od 0 do 200, druga od 201 do 300, itd.
W ramach rozrywki postanowiłem zrobić program automatyzujący te operacje. Z symulacją klików myszki nie było problemu, ale trzeba było wykryć kiedy kłódka znikała (w przypadku pięciokrotnego podania nieprawidłowego kodu, lub gdy kod był prawidłowy). Wpadłem wtedy na pomysł, że można to wykonać analizując kolory kilku kluczowych punktów na ekranie i tak oto w jeden wieczór powstał bot napisany w C++ automatyzujący tą operację. Ponieważ stał się on dosyć popularny w sieci, pomyślałem, że mógłbym tego typu ciekawostki programistyczne publikować w sieci. To wtedy założyłem profil NP na Facebooku i kupiłem domeny pod bloga.
W “notatniku programisty” miałem pierwotnie w planach publikowanie właśnie tego typu artykułów, tzn. opisujących realizację nieszablonowych, prostych pomysłów, które być może zachęciłyby kogoś do rozpoczęcia przygody z programowaniem. Z biegiem czasu opublikowałem też kilka wpisów związanych z Arduino i Raspberry PI.
Jak zacząć programować? Pytanie niby proste, ale zdaje się, że nie ma jednoznacznej odpowiedzi. Dużo osób w takiej sytuacji doradza, żeby wybrać język do odpowiedniego projektu, ale co z osobami, które nie są jeszcze ukierunkowane?
Dla osoby chcącej rozpocząć od zera swoją przygodę z programowaniem, to już żaden problem w dzisiejszych czasach. W Internecie znajdziesz wszystko – od tutoriali, przez darmowe ebooki, artykuły na blogach, książki w sklepach internetowych, po kursy video.
Wybór jest ogromny, ale faktycznie może to trochę przytłaczać. Wszystko zależy od tego ile masz lat. Na fali ostatnich komunikatów o zapotrzebowaniu na programistów i informacji o niezłych wynagrodzeniach, zapewne wielu rodziców zastanawia się jak zachęcić swoje dzieci do nauki programowania.
Ja np. zaczynałem od pisania pierwszych programów na Commodore 64 gdy miałem chyba dziesięć lat. Do zestawu była dołączona stu stronicowa, polskojęzyczna książka, w której opisane były podstawy języka Basic. Naprawdę wielką frajdę sprawiało mi zasiadanie do klawiatury i pisanie kodu sprawiającego, że na ekranie telewizora wyświetlało się to, co zachciałem. Tak powstawały np. testy z historii, czy matematyki, które trafiały do kolegów na taśmach magnetofonowych :).
Jak zacząć programować? Jeśli jesteś dzieckiem, lub chcesz zachęcić swoje dziecko, zacznij od serwisu code.org i “godziny kodowania”. Jest to jedno godzinny kurs przeznaczony dla wszystkich grup wiekowych, dostępny w kilkudziesięciu językach, a swoim wizerunkiem promuje go m.in. Bill Gates i Mark Zuckerberg. Jedenastoletni siostrzeniec, którego zachęciłem do zabawy z tą stroną internetową, ostatnio pokazał mi swoją przeglądarkę internetową, którą napisał w C# :).
Ucząc się już prawdziwego programowania osobiście polecam rozpoczęcie od podstaw języka silnie typowanego jakim jest C++. Poznasz składnię, która jest wykorzystywana w większości popularnych języków, a znajomość wskaźników pomoże w przyszłości szybciej zrozumieć zasady przekazywania wartości przez referencje w innych językach.
Opanowanie podstawowej znajomości C++ będzie solidnym fundamentem pod naukę innych języków programowania.
Jakie są najczęściej popełniane błędy, podczas nauki programowania? Które z nich sam popełniłeś?
Jednym z błędów, które sam popełniałem na początku, było np. nie trzymanie się ogólnie przyjętej konwencji kodowania – polskie nazwy zmiennych, stosowanie wcięć, itp. Od samego początku musimy się zaprzyjaźnić z językiem angielskim aby nie przyzwyczaić się do złych praktyk. Warto również w miarę szybko zaznajomić się z podstawowymi wzorcami projektowymi – ich choćby pobieżna znajomość na początku drogi z programowaniem pozwoli zaoszczędzić sporo czasu w przyszłości.
Jeśli dopiero uczysz się programowania i nie pracujesz zawodowo, to prawdopodobnie popełniasz ten błąd: czytasz książkę, przerabiasz tutorial, przepisujesz framgenty kodu, uruchamiasz i koniec. Poświęć kilka godzin więcej i spróbuj go modyfikować, może napisz dany fragment całkowicie od zera, poszukaj w sieci jakie są inne sposoby oprogramowania danego zagadnienia.
Warto stawiać sobie konkretne zadania do wykonania aby ich realizacja prowadziła do powstania działającego projektu.
Nie bój się zadawać pytań w sieci i przyjmuj krytykę jako coś zupełnie naturalnego i pozytywnego dla własnego rozwoju, natomiast szkoda Twojego czasu na wdawanie się w dyskusje ze “wszechwiedzącymi” – zwłaszcza na polskich grupach facebookowych.
Zatem kiedy można powiedzieć, że napisaliśmy dobry kod?
Można powiedzieć, że dobry kod to taki, który realizuje założone cele, jest wydajny, otwarty na rozszerzanie, dodawanie kolejnych zachowań, ale zamknięty na modyfikacje. To tzw. zasada “open / close” – jedna z pięciu z podstawowych założeń programowania obiektowego, dla których R. C. Martin (autor jednej z najbardziej popularnych książek w tematyce pisania poprawnego kodu “Clean code”) zaproponował mnemonik SOLID w celu łatwiejszego ich zapamiętania.
Dobry kod powinien być zrozumiały dla nas samych, gdy wracamy do niego np. po kilku latach, ale i dla członków naszego zespołu – napisany najprościej jak to możliwe (zasada KISS – keep it simple stupid). Nie znajdziemy w nim też zdublowanych fragmentów, ponieważ trzymamy się zasady DRY – don’t repeat yourself.
Można by powiedzieć, że dobry kod, to ten, do którego napisane są testy, jednak pozwalają one jedynie udowodnić to, że nasz program nie działa poprawnie. Nie są one dowodem poprawności – zwłaszcza w przypadku wielowątkowości. Mimo wszystko praktyczne stosowanie metody TDD ułatwi nam rozwijanie programu w przyszłości.
Ale tak naprawdę to pytanie zadałbym inaczej: czy kiedykolwiek można będzie powiedzieć, że napisaliśmy dobry kod? Czy nie jest przypadkiem tak, że to co napisaliśmy choćby rok temu, dziś nie zrobilibyśmy tego lepiej? A może zrobilibyśmy to lepiej już dziś, gdybyśmy posiadali więcej dostępnego czasu?
W pracy zawodowej zawsze można liczyć, że nasze błędy wyłapie code review. Dowiemy się co można poprawić lub ulepszyć. Jak jednak ocenić swoją pracę, jeżeli nie mamy takiego przywileju?
Zmienić pracę 🙂 Tak sobie żartuję, ale code review jest bardzo ważny. W zasadzie to pracodawca powinien dążyć do tego aby kod juniorów był przeglądany i komentowany przez starszych, choćby ze względów czysto ekonomicznych. W każdym teamie jest taka osoba, która zna się na wszystkim. Zawsze na wszystko znajdzie odpowiedź – korzystaj z jej wiedzy, nie obawiaj się zadawać pytań. Nauczysz się wtedy znacznie więcej i w szybszym czasie.
Czytaj książki – to bardzo ważne. Swoje błędy szybko zaczniesz zauważać podczas przerabiania “Czystego kodu” Roberta C. Martina.
Podam Ci przykład z życia wzięty – na samym początku mojej pracy zawodowej zostałem rzucony na głęboką wodę – pierwsze miesiące pracy, dopiero co zacząłem studia, nie miałem doświadczenia, ze wzorcami projektowymi byłem na bakier i miałem od zera napisać większy system webowy. System pisałem jak chciałem, nikt nie weryfikował tego kodu, a ja byłem zadowolony, że działa. Po kilku latach okazało się, że przez to, że nie wykorzystałem odpowiedniej abstrakcji w komunikacji z bazą danych, bardziej opłacalne byłoby jego napisanie od zera zamiast jego poprawa. System już nie działa. Tak, był to mój błąd, ale niewynikający ze złej woli, ale z niewiedzy i braku doświadczenia. Był to efekt braku jakiejkolwiek kontroli kodu przez kogoś bardziej doświadczonego.
Będąc na początku swojej drogi z programowaniem dosyć trudno samemu ocenić swoją pracę.
W Internecie jest mnóstwo materiałów dla początkującego programisty, natomiast dużo z nich zawierają pojęcia, których początkująca osoba może się przerazić. Jakie materiały uznajesz za interesujące, które są napisane w przystępny sposób?
Jeśli jesteś na tyle początkującym, że jakieś pojęcia Cię przerażają, polecam zerknąć do książek z serii “Head First”, wydawanych w polskich tłumaczeniu pod nazwą “Rusz głową”. Są napisane prostym, młodzieżowym językiem, bez zbędnych rozważań teoretycznych. Dzięki zastosowaniu trafnych grafik, dialogów, czy definicji, wiedza jest szybko przyswajania.
Dobrym pomysłem może się okazać przerobienie kilku kursów video. Na polskim rynku mamy takie strony jak strefakursow.pl czy videopoint.pl, a z zagranicznych bardzo popularna ostatnio w branży: udemy.com, na której można znaleźć ponad 50 tys. kursów – również w języku polskim – gorąco polecam. Nie raz jest tak, że gdy poznajemy coś nowego, np. język programowania, czy framework, najtrudniejszy jest pierwszy start. Nie wiadomo którego IDE użyć, jak skonfigurować projekt i napisać pierwszego “hello worlda”. Kursy video mogą się tu okazać nieocenione. Osobiście lubię oglądać dostępne np. na youtubie prelekcje z konferencji programistycznych.
No i na koniec blogi – w ostatnim czasie powstało ich całkiem sporo za sprawą akcji organizowanej przez Macieja Aniserowicza z bloga devstyle.pl. Coraz więcej osób chętnie dzieli się swoją wiedzą.
Czego Ci mogę życzyć w życiu zawodowym?
To jest bardzo dobre pytanie, bo chętnie przedstawię swój punkt widzenia, a jest on zupełnie inny niż w przypadku większości. Standardowa ścieżka w naszym zawodzie może przebiegać następująco: Senior Developer, Technical Lead, Architect i Technical Project Manager, ale czy zawsze tak musi być?
Podczas jednego z podcastów Michała Szafrańskiego z bloga jakoszczedzacpieniadze.pl, wywiązała się ciekawa dyskusja z zaproszonym Maciejem Aniserowiczem z blogu devstyle.pl. Maciek powiedział, że nie zarabia już na programowaniu, bo się już wypalił.
Pamiętam, że mocno się tym wtedy zaskoczyłem – że jak to, po 10 latach? Choć w zasadzie rozumiem, też miałem etapy zwątpienia, chyba z dwa razy chciałem rzucić tą robotę. Stres, goniące terminy, konieczność ciągłego poszerzania wiedzy, itd.
Przez jedenaście lat pracy zawodowej programowałem nowe moduły w systemach ERP i oświatowych, projektowaniem nowe aplikacje, odbywałem spotkania i ustalenia projektowe z klientami, a i również na telefonie spędziłem setki, jeśli nie tysiące godzin. Jednak nic nie sprawia mi tak wielkiej przyjemności jak pisanie kodu. Uwielbiam to. Do tej pory zdarza mi się powstrzymywać przed zostaniem w pracy jeszcze jednej godziny dłużej w piątkowy wieczór i zamykać firmy gasząc ostatnie światła. Nie z żadnego przymusu, czy presji terminów, a ze zwykłej przyjemności.
Myślę, że właśnie tego życzyłbym sobie w swoim życiu zawodowym, tzn. tego, abym nie utracił tej fascynacji pisania kolejnych linii kodu.
Artykuł powstał dzięki:
Coders Lab
Łącząc doświadczenie edukacyjne ze znajomością rynku pracy IT, Coders Lab umożliwia szybkie i efektywne zdobycie pożądanych kompetencji związanych z nowymi technologiami. Skupia się się na przekazywaniu praktycznych umiejętności, które w pierwszej kolejności są przydatne u pracodawców.
Wszystkie kursy odbywają się na bazie autorskich materiałów, takich samych niezależnie od miejsca kursu. Dzięki dbałości o jakość kursów oraz uczestnictwie w programie Career Lab, 82% z absolwentów znajduje zatrudnienie w nowym zawodzie w ciągu 3 miesięcy od zakończenia kursu.
Zostaw komentarz