Codzienność projektowa okiem Lead Software Engineera

O pracy w Future Processing słów kilka. Dariusz Sowada pracował zarówno w małych jak i dużych firmach, w sektorach prywatnych i publicznych. W poniższym wywiadzie przeczytasz m.in. o jego standardowym dniu pracy w projekcie, Javie i motywatorach w pracy.

Z Javą jesteś związany dosyć długo. Jaki, Twoim zdaniem, jest kierunek rozwoju tej technologii?

W przypadku języka Java należy spojrzeć nieco szerzej niż na sam język i kolejne wydania JDK. Właściwie od wersji 8, w której zostały wprowadzone wyrażenia Lambda, interfejsy funkcyjne oraz strumienie – nie pojawiły się zmiany poważnie wpływające na sposób tworzenia kodu. Zostały jeszcze wprowadzone takie ułatwienia w tworzeniu kodu i poprawiające jego czytelność jak klasa Optional, Var dla zmiennych lokalnych, wyrażenie Switch czy ostatnio Record. Oczywiście, nie zamierzam opowiadać o wszystkich zmianach wprowadzonych w Javie w kolejnych dystrybucjach, ponieważ takie informacje są np. w dokumentacji.

Dużo istotniejsze jest to, że kiedy mówimy o Javie, to musimy mieć na uwadze cały ekosystem, który urósł wokół tego języka, wiele społeczności rozwijających open source’owe projekty oraz tysiące gotowych bibliotek rozwiązujących znane i nieznane problemy 😊. Powstały również kompletne frameworki ekstremalnie przyśpieszające i ułatwiające tworzenie nowych projektów. Na tym polu w chwili obecnej dominujący jest Spring Boot.

Istnieją również gotowe rozwiązania/biblioteki, pozwalające minimalizować zjawisko boilerplate code, za które wiele osób neguje ten język. W tym zakresie najpopularniejsza jest biblioteka Lombok, jednak sam język również powoli ewoluuje w kierunku ograniczania tego zjawiska. Przykładami rozwoju języka m.in. w tym kierunku jest np. wprowadzenie metod domyślnych w interfejsach, co pozwala na wykluczenia tworzenia klas abstrakcyjnych pomiędzy interfejsem, a jego implementacją. Wprowadzenie Vara, które pozwala nie wypisywać wprost typów zmiennych, bo przecież wiadomo jaki typ zostanie tam przypisany. Wyrażenie Switch bazujące na wyrażeniach Lambda znacznie ułatwiające i skracające kod. 

Dzięki za wyjaśnienie i pokazanie Javy z szerszej perspektywy. Powiedz nam z jakich narzędzi i technologii korzystasz na co dzień w swoich projektach?

Spektrum technologii, z jakimi mam styczność w projekcie jest bardzo szerokie. Może zacznę od dołu. Zasadniczo pracuję z użyciem Javy, która jest wykorzystywana do tworzenia serwisów backendowych, osadzonych we frameworku Spring Boot i są to serwisy REST-owe, opisywane za pośrednictwem OpenAPI Specifications.

Kolejnym elementem są bazy danych, gdzie warstwa komunikacyjna jest realizowana za pośrednictwem Hibernata. Do tego dochodzi Elasticsearch i kod pisany w Scala. Do testów jednostkowych i integracyjnych wykorzystujemy Grovy oraz Spocka. Natomiast testy E2E są realizowane za pomocą typescriptu. Projekty są budowane na Jenkinsie, pakowane do obrazów Dockerowych i uruchamiane na Kubernetesie w ramach Azure’a za pomocą skryptów Helma. W projekcie, w którym obecnie pracuję, występują również serwisy backendowe, napisane w Node.js oraz frontend tworzony w Angularze. Jednak są to technologie, w których się nie udzielam, przynajmniej na razie 😉.

Stos technologiczny w ramach tylko jednego projektu jest dość spory i trudno być specjalistą w każdej z tych technologii, co wydaje się zrozumiałe. Dlatego też mamy w zespole osoby, specjalizujące się w: Javie, Scali, frontendzie, testach i DevOpsie. Dzięki temu, mamy swobodny przepływ wiedzy, ponieważ jeśli ktoś w projekcie jest ciekaw, co dokładnie robią koledzy, to zawsze może zaznajomić się z nową technologią czy nawet obszarem działań, które są w projekcie.

Jak wygląda Twój dzień w FP w kontekście pracy w projekcie i współpracy z klientem?

W zasadzie trudno opowiedzieć o standardowym i powtarzalnym dniu pracy, gdyż życie w projekcie toczy się wg Scruma 😊. Łatwiej mi będzie powiedzieć, jak wygląda sprint.

Jasne. Opowiedz nam w takim razie o sprincie.

Jako architekt nie pracuję w ramach żadnego dev-teamu, a raczej nadzoruję prace programistyczne z wyższego poziomu, więc nie bywam na teamowych dailies, ale zamiast tego jestem na Nexusowych SoS-ach . Mamy wdrożonego Nexusa, gdyż bez tego w projekcie, gdzie pracuje ponad 70 osób tylko ze strony FP (plus osoby ze strony klienta), ogarnięcie tego, co się dzieje byłoby niemożliwe. W ustaleniach z klientem biorą udział głównie analitycy biznesowi – to na nich spoczywa odpowiedzialność ustaleń biznesowych, a architekci na tym etapie służą wsparciem technicznym i pilnują, aby plany na rozwój systemu były możliwe do realizacji z technicznego punktu widzenia.

Kiedy już znamy oczekiwania klienta, BA w porozumieniu z architektem opisuje to w stories. Następnie na refinementach z zespołami jest prezentowana koncepcja biznesowa, a architekt przedstawia, czego oczekuje od strony technicznej. Zasadniczo w Future Processing, pozostawiamy programistom dużą swobodę i możliwość wykazania się. Proaktywne podejście jest bardzo pożądane, gdyż przy ograniczonej liczbie architektów w projekcie nie ma możliwości, aby wszystko przygotować do ostatniej śrubki. Poza tym, według mnie, jest to niewskazane, ponieważ developerzy to przecież artyści, którzy chcą tworzyć własny kod, własne dzieło, a nie tylko odtwarzać wcześniej przygotowany schemat.

Gdy dzieło jest już skończone – przychodzi czas na code review. Każdy z projektów ma dedykowanych opiekunów i repozytorium. Jednak przy dużych i poważnych zmianach zalecane jest, aby architekt również zrecenzował kod, zwłaszcza jeśli wcześniej przedstawił czego oczekuje. Czasem, jeszcze podczas testów, trzeba wesprzeć QA, jeżeli są jakieś wątpliwości. Tak naprawdę to wszystko zależy od stopnia skomplikowania wprowadzanych zmian i ich zależności od innych części systemu. Na koniec trzeba jeszcze dopilnować, aby wszystkie wprowadzane zmiany były ze sobą kompatybilne, wdrożone w odpowiedniej kolejności i zaprezentowane klientowi na koniec sprintu. No i oczywiście pomiędzy tym wszystkim trzeba jeszcze znaleźć czas na kawę ;).

W Future Processing jesteś architektem oprogramowania. Czym różni się to stanowisko od pracy Software Developera w Twojej firmie?

Według mnie, bycie architektem wymaga zupełnie nowego spojrzenia na to, co się robi w ramach projektu. Opowiem, jak to wygląda w FP i dodam, że pokrywa się to z przekonaniem, jakie sobie wyrobiłem w trakcie wielu lat pracy na temat tego, jak ta rola powinna wyglądać. Na tym poziomie konkretna technologia, w której jest realizowany projekt, schodzi na drugi plan. Oczywiście, bardzo ważne jest wiedzieć co i jak da się zrealizować z użyciem danego języka; czy wykorzystać bazę SQL, czy NoSQL; czy usługa powinna wystawiać API REST-owe, czy może jednak SOAP-owe; jak zrealizować autoryzację oraz wiele innych elementów, które są wymagane do uruchomienia projektu. Jednak to są tylko narzędzia.

Gdy się jest architektem, trzeba patrzeć na całość projektu z dużo wyższego poziomu niż podczas realizacji pojedynczych potrzeb klienta w postaci nowych ficzerów. Architekt musi aktywnie współpracować z klientem, poznawać jego potrzeby, pomóc mu zaplanować rozwój systemu, pilnować pryncypiów architektury, a także nadzorować, w jakiej kolejności są realizowane zadania tak, aby zależności pomiędzy nimi nie blokowały ich realizacji w czasie.

Masz bogate doświadczenie zawodowe. Czym praca w Future Processing różni się od innych miejsc, w których je zdobywałeś?

Moje doświadczenie zawodowe jest związane zarówno z pracą w małych firmach, jak i tych naprawdę dużych, w sektorze prywatnym i publicznym. W niektórych z nich pracowałem stosunkowo krótko, w innych naprawdę długo. W FP pracuję relatywnie krótko, bo od maja 2021. Jednak jest to już na tyle długo, aby poznać lepiej firmę i wyrobić sobie o niej zdanie. Również o atmosferze i kulturze, jakie tu panują i są promowane.

Rzeczą, która skłoniła mnie do zmiany pracy i przyjścia do FP był sposób rekrutacji. Był on bardzo przyjazny, gdzie poza rozmowami “miękkimi”, odbyła się weryfikacja techniczna i kompetencyjna. Wspominam ją bardzo dobrze, gdyż osoby, z którymi rozmawiałem chciały się dowiedzieć jak najwięcej o mnie, nie wytykając mi w żaden sposób braków, a oczywiście takie na pewno mam jak każdy. Dla mnie było to zupełnie nowe doświadczenie, tym bardziej, że wcześniej bywałem wielokrotnie po tej drugiej stronie. Niechętnie, ale muszę przyznać, że rozmowy z kandydatami polegały zazwyczaj na pokazaniu im, ilu rzeczy jeszcze nie wiedzą.

Jednak wracając do FP, to pierwsze dobre wrażenie o firmie i jej podejściu do pracownika nie zmieniło się do tej pory. Z punktu widzenia mojej wieloletniej pracy w branży IT, to jest chyba pierwsza firma, która traktuje wszystkich pracowników jak swój największy kapitał. Przekłada się to na warunki pracy, przyznawany sprzęt, przestrzenie przeznaczone do relaksu. Doceniam również podejście przełożonych do zespołu, propagowaną kulturę współpracy oraz możliwość integrowania się w trakcie organizowanych eventów.

Z jednej strony, ktoś może pomyśleć, że jest to kontrowersyjne w czasach jakie mamy, jednak z drugiej – to bardzo potrzebne, by ludzie współpracujący ze sobą, mieli możliwość poznania się również na gruncie prywatnym. W obecnych czasach, gdy mamy coś na miarę kultu pracy zdalnej, ta potrzeba jest moim zdaniem nawet większa niż kiedykolwiek wcześniej.

Skoro już mowa, o pracy zdalnej, to gdy się zatrudniałem jasno określiłem, że moim docelowym modelem pracy jest praca zdalna i nie było z tym żadnego problemu. Jednakże, po kilku wizytach w firmie stwierdziłem, że zasadniczo lubię przyjeżdżać do niej. Nie robię tego zbyt często, ale jak już jestem, to jest to zawsze udany dzień.

Sprawdź najnowsze oferty pracy w Future Processing!