Nasza strona używa cookies. Dowiedz się więcej o celu ich używania i zmianie ustawień w przeglądarce. Korzystając ze strony, wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki. Rozumiem

Programowanie w 2019: trendy czy podstawy?

Adam Kukołowicz CTO / Bulldogjob
W 2019 nadal liczą się mocne podstawy, dzięki którym szybko można dogonić każdy nowy trend.
Programowanie w 2019: trendy czy podstawy?

Rozpoczął się sezon na listy tego, co zobaczymy w 2019. W IT często przybiera to formę zestawienia trendów na nadchodzący rok, listy technologii, języków, narzędzi czy frameworków, które zyskają na popularności. Od przynajmniej 2-3 lat te wyliczanki zawierają dokładnie to samo - blockchain, AI, machine learning, VR, cloud, IoT, CD, DevOps itd. itp.

Może się wydawać dziwne, że w tak szybko rozwijającej się dziedzinie, jak IT, trendy nie zmieniają się z roku na rok. Co więcej, jest bardzo wiele elementów, które są kluczowe i pozostają ciągle takie same. Owszem, zmienia się kierunek działania czy narzędzia, ale podstawy są niezmienne.

Dlatego właśnie chciałem się podzielić listą tego, co moim zdaniem zawsze będzie trendy (disclaimer: nie dotyczy to okresu po wynalezieniu silnej sztucznej inteligencji). Dzięki tym umiejętnościom, bez względu na to, co aktualnie jest modne, łatwo sobie poradzić w roli programisty.


Rozumienie i umiejętność zastosowania różnych paradygmatów

Paradygmat to sposób patrzenia na przepływ sterowania i wykonywanie programu komputerowego. Pewnie na co dzień wykorzystujesz miks kilku z nich, jako że większość współczesnych języków czerpie z wielu. Nie jest to jednak równoznaczne z ich dobrym zrozumieniem i umiejętnością wyciągania z nich jak największych korzyści.

Przede wszystkim, paradygmat to sposób myślenia, a ten ciężko zmienić, jeżeli używa się ciągle jednego języka. Nawet jeżeli czerpie on z wielu paradygmatów. Trzy najbardziej popularne to paradygmat obiektowy, funkcyjny i proceduralny, jednak jest ich znacznie więcej i tworzą całą hierarchię. Warto poznać dobrze kilka z nich, by na problemy móc patrzeć z różnych perspektyw.


Poznawanie różnych paradygmatów, oprócz nauki teorii, warto zestawić z praktyką, czyli nauczeniem się różnych języków programowania (np. obiektowego, funkcyjnego czy nawet logicznego) i przy okazji stać się poliglotą.


Znajomość wzorców projektowych i architektonicznych

Ważnym elementem, który ułatwia pisanie dobrego softu, jest znajomość wzorców projektowych i architektonicznych. Zapobiega one przede wszystkim wymyślaniu koła na nowo. Zapewniam, że 99% z Was (ja też) pracuje nad problemami, dla których dobre rozwiązania wymyślili już inni programiści i informatycy. Jeżeli jest to problem ze strukturą aplikacji, to odpowiedzią będą wzorce projektowe. Warto tu sięgnąć po książki takie jak Wzorce projektowe. Elementy oprogramowania obiektowego wielokrotnego użytku czy Architektura oprogramowania w praktyce. Dokładnie tak, jak zauważyli autorzy pierwszej książki - są pewne elementy, których można używać wielokrotnie w różnych kontekstach.

Wzorce to nie tylko klocki. To również abstrakcje, dzięki którym łatwiej myśleć o systemie, co jest bardzo ważne przy większych projektach. Te abstrakcje można stosować bez względu na język programowania czy framework (czasem łatwiej to zrobić, czasem trudniej, czasem da się je zastąpić konstrukcjami samego języka), więc to wiedza zupełnie uniwersalna.


Praktycznie każdy nowy framework czerpie w jakimś stopniu z już istniejących wzorców architektonicznych, a poszczególne podsystemy wewnątrz są realizowane za pomocą wzorców projektowych. Dlatego kolejny framework nie będzie czymś totalnie nieznanym, a remiksem już istniejących idei.


Struktury danych (i algorytmy)

To jest to, co słyszymy na polskich uczelniach - algorytmy i struktury danych to podstawa, bez której ani rusz. To prawda, że nowoczesne języki programowania i ogólnodostępne biblioteki niemal kompletnie zniosły potrzebę pisania algorytmów sortowania, przeszukiwania drzew czy grafów. Sam używałem drzewa jakieś kilka lat temu, a z listy ostatni raz korzystałem na studiach (mówię o przypadku gdzie sam musiałem zdecydować, że w tym konkretnym miejscu jest potrzebna taka struktura).

Jednak tu zupełnie nie o to chodzi. Na co dzień używamy wielu algorytmów, wrzucając w nie wybrane przez nas struktury danych. Dużo rzeczy dzieje się „automagicznie” i bez zrozumienia tego, co dzieje się pod spodem, efektem może być bardzo słaba wydajność. Właśnie tu pomaga podstawowe zrozumienie struktur danych i algorytmów - daje ono pojęcie, jak daleko jesteśmy od optymalnego rozwiązania. Dodatkowo notacja dużego Ο pomoże zrozumieć, jak funkcja zachowa się wraz ze wzrostem ilości danych.

Użycie właściwej struktury danych w odpowiednim miejscu oszczędza mnóstwo kłopotów i czasu (zarówno programisty, jak i procesora).


Inżynieria oprogramowania

Stanowisko Software Engineer powinno zobowiązywać. Inżynieria oprogramowania to całość procesów, które składają się na zaprojektowanie, rozwój i utrzymanie oprogramowania. Jest wielu programistów, którzy chcieliby dołożyć swoją cegiełkę tylko w malutkim wycinku tego procesu - to jest w projektowaniu i implementacji oprogramowania. Najlepiej w projekcie, którego nie trzeba długofalowo wspierać, by można było pracować zawsze nad czymś nowym.

Bardzo często jakość procesów wokół tworzenia oprogramowania przekłada się na jakość produktu. Przykłady? Dobre zebranie wymagań, skonfrontowanie ich z tym, co już jest napisane, przetestowanie rozwiązania, dobra strategia releasów, wsparcia i wersjonowania.


Komunikacja

Temat wałkowany wielokrotnie i do znudzenia. Jednak od tego się nie ucieknie. Komunikacja zarówno wewnątrz zespołu, jak i z tym, co na zewnątrz, jest bardzo istotna. Bez tego nie ma mowy o dobrym softwarze.

W zespole duża część komunikacji to kod i trzeba pamiętać, że jego czytelność jest ważna. Stąd to całe zamieszanie z wybieraniem nazw, wcięciami, konwencjami w kodzie czy z dokumentacją projektową.


Umiejętność komunikacji z ludźmi - technicznymi i nie - jest tym ważniejsza, im dalej się jest na swojej ścieżce zawodowej. W końcu senior developer to ma być osoba, która potrafi przekazać wiedzę o systemie współpracownikom czy ludziom z biznesu. Musi umieć wytłumaczyć swoje decyzje i łączyć to z umiejętnością dawania jasnego i konstruktywnego feedbacku.


Umiejętność wybierania dobrych kompromisów

Widzieliście prezentacje z konferencji, które reklamowały taką czy inną technologię jako najwspanialszą rzecz na świecie bez omówienia ich wad? Ja widziałem kilka takich np. o mikroserwisach czy Kubernetesie. Sam też próbowałem pisać kod bezkompromisowy - czyli dokładnie spełniający takie czy inne założenia, które postawiłem sobie bardziej dla idei, niż z rzeczywistej potrzeby. Okazało się, że spełnienie tych założeń było okupione dłuższym niż zwykle czasem implementacji i wcale nie przyniosło oczekiwanych korzyści. Finalnie i tak musiałem przystać na pewnego rodzaju kompromis.

Każde rozwiązanie ma swoje wady, a często jego zalety mogą pojawić się tylko w specyficznych warunkach. Dlatego umiejętność świadomego zarządzania wadami i zaletami jest bardzo istotna. W teorii każdy chciałby napisać system, który jest niezwykle wydajny, łatwo się skaluje, którego kod jest super czytelny, w którym debugowanie to pestka, a jego rozwój to bułka z masłem. W rzeczywistości nie można mieć wszystkiego. Konieczny jest kompromis. Sztuką jest znalezienie właściwego, co jest bardzo trudne.


Podsumowanie

Byłoby bardzo szkoda, gdybyśmy w pogoni za trendami, porzucili podstawy. Bez nich będziemy skazani na powtarzanie ciągle tych samych błędów i odkrywanie w kółko tego samego, a na to szkoda czasu. Sądzę, że w 2019 warto spędzić trochę czasu nad rozwojem w 6 obszarach, o których napisałem - co sam też zrobię.

Lubisz dzielić się wiedzą i chcesz zostać autorem?

Podziel się wiedzą z 120 tysiącami naszych czytelników

Dowiedz się więcej