Prostota, czytelność, zwięzłość. Poznaj zalety programowania funkcyjnego

– Podejście funkcyjne wymusza modularność i redukuje przetwarzanie kodu. Promuje też unikanie efektów ubocznych, co czyni kod bardziej zrozumiałym i ułatwia programowanie współbieżne – powiedział w rozmowie z nami Alexander Belyaev, Group Manager w iTechArt Poland.

Wraz z Joanna Kupis, Head of Front-end w iTechArt Poland & Lead Software Engineer 9 czerwca w Warszawie i 23 czerwca w Krakowie opowiedzą o swoim podejściu do programowania funkcyjnego. Namiastkę ich spostrzeżeń znajdziecie w poniższej rozmowie.

Co jest główną zaletą programowania funkcyjnego?

Alexander: Prostota, czytelność, zwięzłość – kod pisany funkcyjnie może być nawet kilkadziesiąt razy bardziej zwięzły niż ten pisany w języku obiektowym. Podejście funkcyjne wymusza modularność i redukuje przetwarzanie kodu. Promuje też unikanie efektów ubocznych, co czyni kod bardziej zrozumiałym i ułatwia programowanie współbieżne. Programy w języku funkcyjnym w ogóle są na wyższym poziomie abstrakcji, przez co prościej je zrozumieć – a wszystkie te cechy razem znacznie ułatwiają utrzymanie kodu i testowanie.

Na ogół przy coraz bardziej skomplikowanym i rozbudowanym oprogramowaniu trudno uniknąć problemów, jakie rodzą się przy stosowaniu wielowątkowości i przetwarzaniu równoległym. Skoro FP nie ma stanów, znikają więc problemy z synchronizacją i współbieżnością.

Joanna: We frontendzie te korzyści są w zasadzie takie same. Funkcyjne podejście do kodu sprawia nie tylko, że jest czytelniejszy i prostszy, jest faktycznie łatwy do testowania. Mockowanie funkcjonalności jest bardzo proste, a przy mniej skomplikowanych funkcjach nawet nie trzeba tego robić. Dzięki programowaniu funkcyjnemu możemy zastosować też takie techniki jak współbieżność – chociaż w JavaScript musimy sobie wielowątkowość stworzyć przy użyciu na przykład workerów. Można skorzystać również z tego, co daje nam kompilator – czyli inliningu, albo z potencjału memoizacji.

Są jakieś przeciwskazania? Co przemawia za tym, żeby nie stosować programowania funkcyjnego?

Alexander: Niekoniecznie jest to argument, żeby nie stosować, ale warto wspomnieć, że sam próg wejścia jest dość wysoki. Dla początkujących zmiana podejścia może być po prostu trudna. Drugą kwestią jest wydajność – z programowaniem funkcyjnym zawsze związany jest jakiś narzut, a krytyczne kawałki kodu powinny być pisane właśnie z myślą o wydajności. Nie wszystkie biblioteki są też przygotowane na podejście funkcyjne – mowa tu na przykład o bibliotekach obsługi I/O. Bywa też, że debugowanie kodu jest utrudnione, ale na to receptą mogą być współczesne IDE.

Joanna: Musimy liczyć się z tym, że świat JavaScript nie jest funkcyjny. Jeśli ściągamy jakieś biblioteki z npm, a robimy to bardzo często, to należy wziąć pod uwagę, że zastosowane funkcje nie będą pure – czyli to, co sami stworzymy, też nie będzie czystą funkcją. Nie wszystko, co napisane funkcyjnie, będzie również wydajne.

Oczywiście, jeżeli myślimy o językach tworzonych z myślą o programowaniu funkcyjnym, kompilator pomoże nam w osiągnięciu odpowiedniej wydajności. Jeśli jednak mówimy o JavaScript, na przykład o algorytmach na dużych tablicach, to takie operacje są dużo mniej kosztowne, gdy przeprowadzamy je w sposób niefunkcyjny. Programowanie funkcyjne to narzędzie do określonych celów i jeśli zaczniemy je stosować do wszystkiego, to kod będzie niewydajny i nie będzie to miało sensu. Trzeba dobrze znać narzędzia, żeby wiedzieć, do czego ich używać.

Umiejętność programowania funkcyjnego jest dziś umiejętnością konieczną?

Joanna: W moim przekonaniu, im więcej konceptów programowania i design patternów znamy, tym większy mamy wachlarz narzędzi i tym łatwiej nam wybrać odpowiednie. Im więcej wiesz, tym lepiej sobie radzisz. Z drugiej strony, można pisać w JavaScript nie znając programowania funkcyjnego. Powiem więcej, można pisać dobry kod w JavaScripcie, nie stosując tego podejścia. Aczkolwiek uważam, że warto poznać jego zalety.

Alexander: Jeśli chodzi o mój obszar – zdecydowanie tak, bo taki jest aktualny kierunek rozwoju Javy. Wcześniej były biblioteki, które wspierały podejście funkcyjne, teraz jest to już część języka.

Zobacz też

News Najpotężniejszy superkomputer na świecie. Ameryka stworzyła potwora

Co jeszcze zamieścilibyście na liście umiejętności, bez których developer nie poradzi sobie na rynku pracy?

Alexander: Przede wszystkim trzeba znać zasady działania języka. Nie chodzi o to, żeby deweloper umiał tylko korzystać z bibliotek, ale żeby wiedział, co jest „pod maską”. W teorii, bez tego można żyć jako „Googlowy programista”, ale dobrze jest mieć orientację. Tego typu pytania często padają na rozmowach technicznych. Musimy wiedzieć, czy ktoś posiada jakieś umiejętności poza czytaniem tutoriali. Dalej – popularne frameworki, zagadnienia wydajności, elementy bezpieczeństwa – znajomość tych kwestii zwyczajnie pomaga być lepszym.

Joanna: Myślę, że Alex wymienił bardzo ważne rzeczy, ale dla mnie dobrym wyznacznikiem jest też to, czy ktoś myśli algorytmicznie i jest w stanie poszukać tego typu rozwiązań. To jest sztuka – przejrzeć tony różnych źródeł w Internecie i znaleźć jakieś fajne, wydajne rozwiązanie. Patrząc na kandydata, lubię wiedzieć, czy coś takiego sprawia mu przyjemność. Bo jeśli nie, jeśli ktoś nie lubi w ten sposób podchodzić do problemów i używać języka jako narzędzia, to też nie będzie dobrym programistą.

Jakie jest Wasze podejście do dzielenia się wiedzą? W jaki sposób podnosicie swoje kompetencje?

Joanna: Lubię dzielić wiedzą i to jest też dla mnie sposób na podnoszenie własnych kompetencji. Bliska jest mi tutaj wypowiedź Alberta Einsteina – „Jeżeli nie potrafisz czegoś prosto wyjaśnić – to znaczy, że niewystarczająco to rozumiesz”. I to jest właśnie to – poznajesz jakiś abstrakcyjny koncept i musisz go przedstawić osobie, która nigdy nie miała z tematem styczności. Zapoznajesz się ze źródłami i uczysz, jak przedstawić go w taki sposób, żebyś był pewien, że sam świetnie znasz jego podstawy.

Mam również dość specyficzne podejście: akademickie tło, pracowałam też na bootcampach, więc po prostu lubię taką formę przekazywania wiedzy. Jako „oldschoolowy” człowiek chętnie sięgam po książki. Niestety, ze względu na szybkie zmiany w JavaScript, czasami nie opłaca się ich kupować, często prościej i lepiej sięgnąć do dokumentacji. Natomiast jeśli chodzi o algorytmikę – zawsze książki. Można sobie kupić książkę z 1968 i wiedza zawarta w niej to wciąż prawda!

Alexander: Meetupy dają zajawkę tematu, ktoś Ci daje ogólną wiedzę, pokazuje, że istnieją obszary, o których nie wiedziałeś. Poznajesz coś nowego i możesz na miejscu o to dopytać. To bardziej inspiracja do nauki. Jeśli chce się zgłębić wiedzę, trzeba sięgnąć po komplementarne źródła. Można korzystać ze źródeł internetowych, ale niestety te darmowe mogą być kiepskiej jakości. Początkujący mogą się przez to nauczyć złych wzorców. Są świetne, sprawdzone kursy, ale najczęściej dużo kosztują.

W jaki sposób dbacie o to, by inni także podnosili swoje kompetencje?

Joanna: Na pewno nie dawać wszystkiego na tacy – czyli jak ktoś ma problem, raczej należy rzucić coś hasłowo. Jeśli ktoś podejmie rękawicę, to też bardzo dużo o nim czy o niej mówi. Na co dzień po prostu dzielę się fajnymi artykułami czy swoimi odkryciami, nawet jeśli są proste. W przypadku mentoringu – dawanie zadań, tłumaczenie teorii. Czasami po prostu pair programming, bo nie ma to jak siadanie i robienie czegoś razem.

Alexander: Mentoring świetnie się sprawdza, ale faktycznie nie na zasadzie pokazywania palcem, co jest do zrobienia, tylko między innymi wskazywania odpowiednich źródeł wiedzy. Dobrym pomysłem może być też wprowadzenie grywalizacji. Wybierasz temat, musisz go sam poznać, a później go przedstawić i za to gromadzisz punkty.

Co Waszym zdaniem wsparłoby promocję programowania funkcyjnego? Co może sprawić, że więcej osób dowie się o nim?

Alexander: To nie tak, że ludzie o nim nie wiedzą. Wiedzą, tylko nie stosują, między innymi ze względu na wysoki próg wejścia. Potrzeba dobrych mentorów, specjalistów, którzy podzielą się swoją wiedzą i upodobaniem do tego stylu, pokażą jego dobre i złe strony, wskażą use cases. To wszystko!

Alexander Belyaev. Group Manager w iTechArt Poland. Zaczynał karierę jako Java Developer ponad 9 lat temu. W 2019 roku objął funkcję Group Managera w iTechArt, gdzie rozbudował swój zespół od 8 do prawie 40 deweloperów. W swojej historii miał do czynienia z różnymi stackami technologicznymi – od programisty Java, poprzez React, aż do rzadkiej umiejętności programowania w Scala.

Joanna Kupis. Head of Frontend iTechArt Poland, Lead Software Engineer. Asia jest w branży IT do dziesięciu lat. Zaczynała jako Java developer, później programowała w Pythonie, a finalnie zajęła językami frontendowymi. Przez 7 lat związana była z Politechniką Łódzką, gdzie pracowała m.in. jako wykładowca Java. Następnie została członkiem zespołu naukowego, który zbudował superkomputer Aruz.