Jak powinny wyglądać realne wymagania dla Junior Java Developer’a?
Patrząc na oferty pracy oraz wymagania dla Junior Java Developer’a można utonąć w morzu technologii i narzędzi, które młodszy programista musi znać już na samym początku. W tym artykule przedstawię minimalne wymagania, które musi spełniać kandydat na stanowisko Junior Java Developer. Lista wymagań, którą przedstawię wynika z mojego doświadczenia oraz ze współpracy z moimi uczniami.
Numer jeden #1, jeszcze przed przedstawieniem technologii i narzędzi. Jednym z najważniejszych wymagań są szeroko rozumiane kompetencje miękkie, np.: praca w zespole, komunikacja z innymi pracownikami w firmie, samodzielność oraz rozwiązywanie problemów.
Kiedy już wiemy, co jest numerem jeden wśród wymagań dla młodszego programisty możemy zająć się równie istotnymi elementami, takimi jak technologie i narzędzia.
Technologie: Język Java (min. wersja 8, 11), Spring Framework, Hibernate ORM, JUnit5, HTML, HTTP.
Narzędzia: IntelliJ, Maven/Gradle, git/GitHub (PullRequest).
Powyższy zestaw wymagań dla Junior Java Developer’a pozwoli sprawnie poruszać się w pracy jako młodszy programista. Dodatkowo moim zdaniem powyższe wymagania dla młodszego programisty powinny mieć następujące priorytety: Java, git, Maven/Gradle, JUnit5, HTTP, REST, HTML, JSON a na samym końcu Spring Framework oraz Hibernate ORM. Dlaczego takie, a nie inne technologie i narzędzia w konkretnej kolejności? Wszystko to opiszę podając przykład „jednego dnia z pracy Junior Java Developer’a”.
- Znajomość języka programowania, np.: Java umożliwi nam pisanie kodu źródłowego.
- git – współdzielenie i praca nad kodem źródłowym z innymi członkami zespołu.
- Maven/Gradle – automatyzacja procesu wytwarzania oprogramowania, np.: budowanie, testowanie, uruchamianie.
- JUnit5 – weryfikacja poprawności działania istniejącego i/lub nowego kodu za pomocą testów.
- Znajomość HTTP, REST, HTML, JSON.
- Spring Framework – wsparcie programisty przy tworzeniu złożonych aplikacji, np.: aplikacji web, cloud.
- Hibernate ORM – obiektowo relacyjne mapowanie klas Java na tabele w bazie danych i/lub odwrotnie.
Spis treści
1. Znajomość języka programowania, np.: Java umożliwi nam pisanie kodu źródłowego
O wymaganiu dotyczącym znajomości samego języka Java nie muszę pisać. Należy pamiętać, że język to tylko narzędzie służące do realizacji wymagań dotyczących tworzonego oprogramowania. Przed przystąpieniem do kodowania zachęcam do zapoznania się z moim artykułem Stop! Zanim zaczniesz pisać kod zastanów się, co chcesz kodować? Analiza, projekt i implementacja.
2. git – współdzielenie i praca nad kodem źródłowym z innymi członkami zespołu
Jeżeli już otrzymaliśmy komputer do pracy, uprawnienia do zasobów firmy oraz zostaliśmy przydzieleni do konkretnego projektu, to po za dokumentacją powinniśmy otrzymać link (adres URL, np.: https://github.com/juniorjavadeveloper-pl/weatherman) do repozytorium z kodem źródłowym projektu nad którym będziemy pracowali. Tutaj pojawia się wymaganie umiejętności korzystania z narzędzia git. Otrzymany link pozwoli nam pobrać kod źródłowy aplikacji, nad którą będziemy pracować, pobrać ze zdalnego repozytorium i utworzyć swoje lokalnego repozytorium.
Następnie zgodnie ze sztuką powinniśmy utworzyć własną gałąź, dodać wymagany kod źródłowy, a następnie zrobić Pull Request z prośbą o przegląd naszego kodu. Więcej szczegółów z przykładami na temat pracy z narzędziem git można znaleźć w moim artykule Wprowadzenie do git z wykorzystaniem IntelliJ IDEA. Realny przypadek użycia.
3. Maven/Gradle – automatyzacja procesu wytwarzania oprogramowania, np.: budowanie, testowanie, uruchamianie
Pobrany kod źródłowy projektu należy zbudować i uruchomić. W większości projektów nie będzie to łatwa sprawa, bo projekty są rozbudowane z dużą ilością kodu, zależności oraz modułów. Na szczęście proces budowania projektów jest zautomatyzowany, ale tutaj pojawia się wymaganie umiejętności korzystania z narzędzia Maven lub Gradle.
Pamiętam jeden projekt, którego proces budowania trwał jedną godzinę, a zależności i moduły musiał się budować w odpowiedniej kolejności oraz czasie. Opisałem tutaj proces lokalnego budowania projektu na potrzeby pojedynczego developera, ale na tym nie koniec, bo obecnie projekty są automatycznie budowane przez różne narzędzia tzw. Continuous Integration (CI) takie jak np. Jenkins lub narzędzia dostępne bezpośrednio na GitHub i/lub Gitlab.
4. JUnit5 – weryfikacja poprawności działania istniejącego i/lub nowego kodu za pomocą testów
Kiedy mamy już pobrany działający kod aplikacji możemy przystąpić do tworzenia własnego kodu źródłowego zgodnie z wymaganiami odnośnie nowej funkcji w aplikacji lub poprawki dla istniejącej funkcjonalności. Kiedy skończymy pracę nad naszym kodem należałoby sprawdzić poprawność działania naszego kodu, robiąc to w sposób zautomatyzowany i nie naruszając spójności danych klientów korzystających z aplikacji produkcyjnie.
Wyobraźmy sobie, że dla systemu bankowego dodaliśmy prowizje przy przelewach dla kont VIP. Nikt nie da nam dostępu do rzeczywistych danych klientów, a tym bardziej możliwości przelewów prawdziwych pieniędzy. Tutaj pojawia się wymaganie umiejętności tworzenia testów z wykorzystaniem biblioteki JUnit5. Dzięki temu będziemy mogli przetestować przelewy i prowizje bez posiadania dostępu do danych klientów oraz ich środków pieniężnych.
5. Znajomość HTTP, REST, HTML, JSON
Obecnie tworzy się aplikacje działające przez przeglądarkę, a ściślej rzecz ujmując, aplikacje korzystające z protokołu HTTP w oparciu o architekturę klient-serwer. Na temat samej komunikacji klient-serwer napisałem oddzielny artykuł, zachęcam do lektury Komunikacja front-end www z back-end Java. Aplikacje oparte o protokół HTTP mogą komunikować się „w trybie” użytkownik (człowiek) <-> aplikacja (komputer) lub „w trybie” aplikacja (komputer) <-> aplikacja (komputer).
W dużym uproszczeniu, w pierwszym trybie użytkownik korzysta ze stron www, które są napisane w HTML i/lub JavaScript, w drugim trybie aplikacje komunikują się same ze sobą korzystając z architektury REST. Tutaj pojawia się wymaganie znajomości takich elementów jak HTTP, REST, HTML, JSON. Aplikacje tworzone w chmurze również korzystają z protokołu HTTP i architektury REST.
6. Spring Framework – wsparcie programisty przy tworzeniu złożonych aplikacji, np.: aplikacji web, cloud
Kiedy mamy już zbudowaną aplikację z kodu źródłowego, który pobraliśmy z repozytorium git, dopisaliśmy nową funkcjonalność do aplikacji oraz przetestowaliśmy jej działanie, to przyszedł czas na Spring Framework. Dlaczego dopiero „prawie na samym końcu” Spring Framework? Pisałem już o tym w moim artykule Najczęstsze błędy młodszych programistów i jak sobie z nimi radzić: „4. Nadmierne używanie framework’ów – Zauważyłem, że większość młodszych programistów Java, traktuje Spring Framework jak remedium dla wszelkich zadań do wykonania oraz problemów do rozwiązania. Owszem, Spring jako framework jest bardzo przydatny, obecnie bez niego trudno sobie wyobrazić tworzenie projektów. Nie zwalnia on jednak programistów z myślenia nad tworzonym kodem”.
Oczywiście zdaję sobie sprawę, że w trakcie budowania aplikacji jak również podczas pisania nowej funkcjonalności wraz z testami mogą wystąpić problemy ze Spring Framework. Tutaj pojawia się wymaganie znajomości Spring Framework. Pisząc o tym framework’u na samym końcu chcę kolejny raz podkreślić fakt nadużywania framework’ów oraz potrzeby pisania ze zrozumieniem czystego kodu.
7. Hibernate ORM – obiektowo relacyjne mapowanie klas Java na tabele w bazie danych i/lub odwrotnie
Zacznę od tego, że tak jak w przypadku Spring Framework, tak Hibernate ORM nie zwalnia programistów z myślenia nad tworzonym kodem. Ten framework jest przyczynkiem do rozmowy o modelu dziedziny, który w telegraficznym skrócie jest słownikiem głównych pojęć używanych w projekcie, aplikacji, np.: dla systemu bankowego modelem dziedziny będą pojęcia: Bank, Client, Account, Transfer. Hibernate ORM dla klas Java stworzy tabele w bazie danych wraz z ograniczeniami i relacjami, poniekąd zwalnia, to programistę ze znajomości języka SQL i pozwala skupić się na tworzeniu właściwego modelu dziedziny.
Moim zdaniem poprawny model dziedziny jest kluczem do sukcesu dla projektu, jest on tym samym, co solidne fundamenty dla budowy domu. Na początku nauki Junior Java Developer’a zachęcam do korzystania z tego framework’a i tutaj pojawia się wymaganie znajomości Hibernate ORM. Dodam jeszcze, że nie widziałem dużego komercyjnego projektu, który produkcyjnie do obsługi setek tysięcy klientów używałby Hibernate ORM, do prototypowania oraz proof-of-concept owszem, Hibernate ORM ma ogromne zastosowanie i jest bardzo użyteczny.
Podsumowując, pomimo że oferty pracy dla Junior Java Developer’ów są przepełnione wymaganiami odnośnie znajomości technologii, moim zdaniem najważniejsze, to znajomość poniższych elementów:
- Znajomość języka programowania, np.: Java umożliwi nam pisanie kodu źródłowego.
- git – współdzielenie i praca nad kodem źródłowym z innymi członkami zespołu.
- Maven/Gradle – automatyzacja procesu wytwarzania oprogramowania, np.: budowanie, testowanie, uruchamianie.
- JUnit5 – weryfikacja poprawności działania istniejącego i/lub nowego kodu za pomocą testów.
- Znajomość HTTP, REST, HTML, JSON.
- Spring Framework – wsparcie programisty przy tworzeniu złożonych aplikacji, np.: aplikacji web, cloud.
- Hibernate ORM – obiektowo relacyjne mapowanie klas Java na tabele w bazie danych i/lub odwrotnie.
Zapraszam do regularnego odwiedzania mojej strony, będą pojawiać się kolejne artykuły oraz do kontaktu przez email kontakt(at)juniorjavadeveloper.pl.
Zdjęcie główne artykułu pochodzi z unsplash.com.