3 rzeczy które powinieneś wiedzieć jako programista
Cześć,
jakiś czas temu, przyglądając się swojej „karierze” zauważyłem, że świadomość pewnych zależności mi bardzo pomagała. No i właśnie te przemyślenia, skłoniły mnie do napisania tego wpisu – o trzech rzeczach, jakie moim zdaniem, powinien wiedzieć każdy programista.
To co napiszę tyczy się programisty na każdym etapie „wtajemniczenia”, aczkolwiek jeśli jesteś juniorem i nie czujesz wagi tych słów to się nie martw, wszystko przed Tobą.
No to zaczynamy…
Świadomość jest ważna
Znaczy się… Że co?
Znaczy się, że to że dobrze wiedzieć jak działają rzeczy których używasz.
Tyczy się to np. zagadnień sieciowych – jeśli Twoje komponenty komunikują się via HTTP to powinieneś wiedzieć co tym zyskujesz i co tracisz. Powinieneś mieć świadomość tego jakie cechy ma ten protokół. I to nie na zasadzie wyrecytowania definicji z Wikipedii – a faktycznego rozumienia protokołu.
Każdy sposób komunikacji niesie za sobą jakiś niezerowy narzut z nią związany a wiedza na temat tego jak on działa – pozwala Ci być znacznie lepszym programistą.
Ale odchodząc od tematu protokołów – programując, bardzo często posiłkujemy się gotowymi kawałkami kodu (czy to z github’a czy stackoverflow – nie ma znaczenia) aby uzyskać jakiś efekt – nie ma nic w tym złego.
Natomiast, jeśli bierzemy sobie gotowe rozwiązanie problemu ze stackoverflow, wklejamy, działa i lecimy dalej to jest to błędem.
Wykorzystaj tę sytuację lepiej! Ktoś z Internetu rozwiązał Twój problem, weź więc jego rozwiązanie i przeanalizuje je tak by rozumieć co dokładnie się tam stało – dzięki takiemu podejściu nie tylko rozwiązujesz swój aktualny problem ale też zyskujesz coś bezcennego – wiedzę i świadomość.
Idąc dalej, podobnie sprawa ma się np. do tego jak uruchamiany jest Twój program – jeśli np. jest to Java to znając sposób jej uruchomienia (opisany np przeze mnie tutaj) wiesz że nie musisz przejmować się jakoś super wydajnością i energię tę możesz wykorzystać do napisania kodu, który się łatwo czyta.
Najlepiej to co chcę przekazać widać chyba jak ludzie korzystają z tutoriali z Internetu – po prostu bezmyślnie robią ctrl+c, ctrl+v, enter, zapętlone aż do ostatniego polecenia. Robiąc kolejne ctrl+v zastanów się co właściwie robisz, co te polecenia robią, np. załóżmy że masz zainstalować psycopg – prawdopodobnie dostaniesz błąd informujący o braku pliku Python.h – rozwiązanie znajdziesz bardzo łatwo, ale przeanalizuj dlaczego go brakowało i jak wygląda rozwiązanie problemu.
Czekaj, stop!
Podoba Ci się to co tworzę? Jeśli tak to zapraszam Cię do zapisania się na newsletter:Jeśli to Cię interesuje to zapraszam również na swoje social media.
Jak i do ewentualnego postawienia mi kawy :)
Dogłębna świadomość jak działają poszczególne elementy pozwoli Ci podejmować lepsze decyzje architektoniczne, bo będziesz wybierał rozwiązania lepiej pasujące do problemu który rozwiązujesz, dzięki czemu będziesz po prostu lepszym programistą.
Mam nadzieję że udało mi się wyjaśnić co mam na myśli.
Uczmy się programowania a nie języków
Mam tu na myśli, że warto zrozumieć programowanie dogłębnie, czyli to jakimi zasadami się rządzi i jakie elementy składowe dostarcza. Można się tego nauczyć na przykładzie prawie dowolnego języka (o ile paradygmat jest obiektowy).
Dzięki temu znacznie obniży się koszt wejścia w kolejny język – ponieważ będziesz już miał wiedzę jak działa programowanie, zostanie tylko nauczenie się składni. I ewentualnie, specyficznych dla konkretnego języka, rozwiązań.
Bo jeśli np. poznasz dobrze Pythona to wiesz że możesz w innych językach oczekiwać czegoś na wzór pipa i tak łatwo dochodzisz do npm’a w nodejs, maven’a w javie czy mix’a w Erlangu. Podobnie jest z biblioteką standardową, bo z dużym prawdopodobieństwem np. funkcja reduce w każdym języku zwróci ten sam typ danych.
Warto poznawać też rzeczy które są „ponad” językami – algorytmy, protokoły, wzorce itp.
Po pewnym czasie dostrzega się że język to tylko narzędzie i w sumie to obojętne jest nam w którym z nich piszemy – bo umiemy programować a nie tylko pisać w konkretnym języku.
Skala
Jakkolwiek byś nie zaprojektował architektury, jakkolwiek dużo czasu dział zachowania jakości nie poświęci – prawdopodobnie i tak po dostarczeniu na produkcję kompleksowego rozwiązania – przywita nas przyjaciel (lub wróg, bo to zależy od tego z której strony się spojrzy) który jest znany każdemu programiście – skala.
Pisząc skala mam na myśli obciążenie generowane przez osoby korzystające z Twojej aplikacji.
Dopiero skala odpowiada nam na pytanie „jak dobrze napisaliśmy tę aplikację”, bo wtedy wychodzą najmniejsze niedociągnięcia. I nie tylko te czysto techniczne jak niezwolnione kilkunastu KB pamięci, które pod obciążeniem urosło w godzinę do kilku GB i serwer zaraz się udusi ale też te architektoniczne typu „ta kolejka tutaj to nie jest dobry pomysł” czy „ten serwer http nam się nie wyrabia, trzeba zmienić protokół komunikacji”.
Wydaje mi się że nie zawsze jesteśmy w stanie przewidzieć wszystko, więc zostaje nam iteracyjnie rozwijać aplikację w modelu „zauważam brak wydajności -> opracowuję rozwiązanie alternatywne -> dostarczam nowe rozwiązanie -> obserwuję” i tak do wyłapania wszystkich wąskich gardeł systemu.
Zmierzając do brzegu
Zdaję sobie sprawę z tego, że w sumie wszystkie trzy elementy o których wspomniałem wyżej w jakiś sposób się ze sobą przeplatają – ale w gruncie rzeczy to tylko zwraca uwagę na to jak wiele przychodzi wraz z doświadczeniem.
A może czegoś brakuje na tej liście? Uzupełnij moją wypowiedź, pisząc komentarz :)
Mateusz Mazurek
„Można się tego nauczyć na przykładzie prawie dowolnego języka (o ile paradygmat jest obiektowy).”
Programowanie obiektowe nie jest jedynym słusznym podejściem do programowania. Ma swoje zalety, ale ma i swoje wady. Niektórzy, jak Djikstra, głośno i dobitnie krytykowali takie podejście do tworzenia oprogramowania. Więc stawianie obiektówki jako wzór też jest trochę nietentego
Cześć, wiesz to mój blog więc i moje zdanie:) napisz swoje zdanie z argumentami zamiast „źle, bo źle” :)
Rozumiem, co chcesz przekazać w tym paragrafie i absolutnie się z Tobą zgadzam, to bardzo słuszne spostrzeżenie. Myślę, że Jakub chciał zwrócić uwagę no to, że to spostrzeżenie jest bardziej generalne, a nie jedynie specyficzne dla OOP. Przechodząc między dwoma językami, które wspierają OOP, niekoniecznie wykorzystasz potencjał nowego języka trzymając się wiedzy z pierwszego. I nie chodzi tutaj tylko o składnię czy rzeczy specyficzne dla danego języka, ale pewne ogólnie przyjęte normy, praktyki, coding style, ekosystem, etc. Przykład z mojego doświadczenia: z Javy poszedłem w Pythona, w Pythonie nie programowałem obiektowo, nauczyłem się wykorzystywać lambdy, map, reduce, filter i inne… Czytaj więcej »
Ależ ja jestem za wyjściem poza paradygmat obiektowy!
Każde wyjście poza znany schemat rozwija Cię jako programistę w tempie wykładniczym:) wspominając o paradygmacie miałem na myśli że jakby największy zysk z wiedzy masz właśnie w językach w obrębie jednego paradygmatu. I jasna sprawa że składni nadal się musisz nauczyć, ale cały mindset (tak to nazywam) jest nadal aktualny:)
W sumie przed Python’em też pisałem w Javie:P
W mojej pracy często jest tak, że nie ma idealnie pasującego kodu ze Stacka czy Githuba, który pasowałby do charakteru problemu z jakim się zmagam. Nawet jeżeli coś przekopiuję, to są fragmenty całości i zawsze wymaga to dostosowania do kontekstu i analizy :)
No chyba, że jako junior zajmujemy się tworzeniem CRUD. Wtedy może zdarzyć się tak, że gotowy fragment znaleziony w sieci pasuje w 100% do naszego zadania.
Pozdrawiam, Mateusz Rus.
Zgadzam się z Mateuszem w każdym punkcie tego artykułu. Świadomość pisanego kodu oraz uniwersalność tej umiejętności, to jest bardzo ważne. Dlatego właśnie lubię się uczyć matematyki a także Pythona jako języka back-endowego.
Matematyka za dużo się nie zmienia na przestrzeni czasu. Back-end zmienia się ale nie tak szybko jak front-end.
Szkoda by mi było czasu na naukę czegoś co za parę lat nie będzie już aktualne.
Pozdrawiam :-).