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.

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 :)