Czego można nauczyć się w projekcie legacy? Projekt legacy to często najszybsza droga, żeby zostać programistą. Nie zasze jest to dobra opcja dla początkujacego programisty, ale często jest to jedyna opcja. W takim projekcie też można nauczyć się wielu rzeczy, ale często niestety jest to droga przez mękę.
Poniżej znajdziesz link do playlisty z vlogiem:
Zapraszam także do moich warsztatów o architekturze warstwowej i architekturze heksagonalnej
I do kursu Hibernate i JPA
Vlog w wersji Audio:
Inne platformy podcastowe:
https://open.spotify.com/show/5HQFAJg0N4o9mDEze8WVvi?si=cc72277bbd834760
https://podcasts.apple.com/us/podcast/vlog-programistyczny/id1606703834
https://podcastsmanager.google.com/show?hl=pl&show=show:f0FRKrpSJZuEP1UQgm73vw
https://castbox.fm/channel/Vlog-Programistyczny-id4743197?country=us
https://podcastaddict.com/podcast/3783474
Transkrypcja
Ostatnio dostaje sporo wiadomości typu, dostałem swoją pierwszą pracę, ale niestety trafiłem do bardzo starego i bardzo słabego projektu, gdzie jest bałagan i widzę, że nic tu się nie nauczę. Co zrobić? Zostać i złapać trochę doświadczenie na papierze, czy jednak szukać od razu nowej pracy?
Cześć witam Cię w kolejnym vlogu na moim kanale. Ja nazywam się Mateusz Dąbrowski. A dzisiaj porozmawiamy sobie o projektach legacy.
Jeśli jeszcze nie subskrybujesz mojego kanału to oczywiście zachęcam do subskrybcji. Przypominam także, że vloga można słuchać, na platformach podcastowych takich jak Spotyfy czy Apple Podcast i także na wielu innych popularnych platformach. Linki znajdziesz w opisie pod odcinkiem.
A zacznę od tego co to jest projekt legacy, albo jak rozumiem projekt legacy, bo w sumie nie ma jakiejś specjalnie dobrej definicji takiego projektu.
I ja rozumiem projekt legacy jako stary projekt, który powstał 5-10, 15 lat temu, często w starych i już praktycznie nieużywanych technologiach. I charakterystycznymi cechami takiego projektu są zwykle niechlujny, bardzo kiepsko napisany kod, i zwykle duża jego ilość.
I najstarszy projekt, z jakim pracowałem w momencie kiedy go opuszczałem miał 18 albo 19 lat, dzisiaj ten projekt ma już ponad 20 lat. I było w nim bardzo dużo kodu, i też było dużo kodu, który powstał dosyć dawno i nie był w ogóle dotykany przez wiele lat i też w wielu miejscach był to kod bardzo słabej jakości.
Ale też było wiele nowo powstającego kodu, który już był dużo lepszej jakości i wyglądał naprawdę bardzo dobrze. Wiec był to projekt legacy, gdzie trzeba było niestety grzebać w starym kodzie, ale także powstawało bardzo dużo nowego i dobrego kodu.
I w tym projekcie pracowali prawie sami seniorzy, z dosyć dużym doświadczeniem i ja też już wtedy byłem bardzo doświadczonym programistą, więc praca w takim projekcie nie był dla mnie trudna.
Wręcz przeciwnie, traktowałem to jak wyzwanie. Zagłębianie się w ten cały kod było dla mnie dosyć interesujące. Mogłem także wykazać się swoją wiedzą, mogłem sugerować pewne zmiany w projekcie, które poprawiały pracę z tym projektem, wiec dla mnie było to ciekawe doświadczenie. Ale ja byłem już wtedy bardzo doświadczonym programistą.
A jak to wygląda w przypadku juniora i czy junior powinien w ogóle trafić do projektu legacy?
Wielu z początkujących programistów niestety trafia właśnie do takich projektów. Gorzej, że większość jest w takim projekcie pozostawiana sama sobie.
Dzieje się tak dlatego, że większość programistów nie chce pracować w takich projektach, zwłaszcza jak są to jakieś mało istotne projekty, z których korzysta niewielu użytkowników.
Jednak często w takich projektach potrzebne są poprawki i nowe funkcjonalności, więc ktoś to musi robić.
Moim zdaniem początkujący programiści nie powinni trafiać do takich projektów, zwłaszcza jak kod w nich zawarty, jest naprawdę słabej jakości, bo prowadzi to do wyrobienia złych nawyków, które często bardzo trudno jest wyeliminować.
Poza tym jest to trochę zabijanie potencjału młodych ludzi i wręcz zniechęcanie do programowania.
Ale świat nie jest idealny i dzisiaj z racji tego, że próg wejścia do IT, czy też do programowania jest dosyć duży, to takie projekty są czasem najszybszą drogą do zostania zawodowym programistą. I oczywiście wszystko się zgadza, jest to duża szansa, ale też jest to pewnego rodzaju pułapka.
[Dlaczego projekty legacy są pułapką?]
I dlaczego jest to pułapka? Po pierwsze zwykle jesteś jedynym programistą w tym projekcie, nie wiesz, co masz robić i jak masz robić. W razie problemów zostajesz sam z tymi problemami i jest to bardzo trudna sytuacja, zwłaszcza jak jest to twoja pierwsza praca.
I w takiej sytuacji możesz jedynie pytać, bo być może w firmie są osoby, które wcześniej pracowały w tym projekcie, ale zostały przeniesione do innego.
I zwykle te osoby nie chcą się ujawniać, ale jak pociągnie się je trochę za język, to okazuje się, że mogą pomóc, mimo ze na początku trochę są niechętne do współpracy.
Kolejna rzecz, która sprawia, że takie projekty to pułapka, to technologie, które są tam używane.
W ostatnim vlogu mówiłem o technologiach, których nie warto się już uczyć, bo po prostu są trochę przestarzałe. Link do tego vloga znajdziesz na karcie.
I wiele projektów legacy jest zbudowana na tych technologiach. I cóż niestety trzeba będzie je trochę poznać, jak chcesz przetrwać w takim projekcie.
Problem jest o tyle duży, że jeśli myślisz o rozwoju i pracy w kolejnym projekcie z nowoczesnymi technologiami, to tak naprawdę musisz uczyć się dwóch rzeczy naraz.
I starych technologii, które są w projekcie i nowych, żeby za jakiś czas przejść do lepszego projektu. Niestety wymaga to sporo wysiłku i poświęcania dużo dodatkowego czasu. I oczywiście taka nauka jest mniej efektywna.
I jak przetrwać w takim projekcie?
Przede wszystkim, trzeba dużo pytać, właściwie o wszystko.
Bo jak nawet jesteś sam w tym projekcie, to zawsze jest jakaś osoba, która zleca Ci zadania. Jakiś Project Manager, jakiś kierownik i oni zwykle mają jakąś wiedzę na temat projektu.
I być może ta wiedza nie dotyczy samego kodu, ale może Ci pomóc zrozumieć, jak działają pewne funkcjonalności i dlaczego działają tak, a nie inaczej. I rozmawianie ze wszystkimi, osobami w projekcie i dookoła niego, pomaga się trochę w tym projekcie odnaleźć, wtedy trochę łatwiej jest przeglądać kodu.
Co do kodu, to tak jak już wspominałem, trzeba pytać wszystkich dookoła, bo być może nie są już w tym projekcie, ale kiedyś byli i coś tam wiedzą na temat.
Co do starych technologii to jest wiele grup wsparcie, chociażby na Facebooku, gdzie jest wiele osób, które coś tam wiedzą na temat różnych technologi, więc zawsze znajdzie się ktoś chętny do pomocy.
[Czego można się nauczyć w projekcie legacy?]
Gdy już jesteś w projekcie legacy, to czego można się z takiego projektu nauczyć. Bo to nie jest tak, że w takim projekcie są stare technologie i niczego się nie nauczysz. Jest cała masa rzeczy, których można się nauczyć w takim projekcie i te rzeczy będą Ci się przydawać w całej twojej karierze.
I pierwsza rzecz, która zawsze przychodzi mi do głowy to SQL. Ponieważ wiele z projektów legacy korzysta właśnie z czystego SQLa. Jak jest sql to też jest baza danych. I w takim projekcie znajdziesz bardzo dużo przykładów zapytań sql.
I warto uczyć się sqla poprzez przeglądanie tych przykładów, poprzez pisanie swoich podobnych zapytań. Także warto zajrzeć do bazy danych, jak tworzone są tabele, czy są stworzone odpowiednie relacje, czy mają klucze obce, czy mają pozakładane indeksy, na kolumny, które są często wykorzystywane w warunkach where.
Czy mają założone klucze unique w odpowiednich miejscach?
Więc warto zagłębić się w temat baz i sqla. I ogólnie trochę zagłębić się w temat projektowania relacyjnych baz danych, bo generalnie większość aplikacji korzysta z relacyjnych baz danych i z mojego doświadczenia wynika, że ten temat jest zawsze na czasie.
Kolejna rzecz to JPA, jak nie jest wykorzystywany sql, to zwykle jest JPA i np. jakiś ORM zwykle jest to Hibernate. I JPA i Hibernate jest dzisiaj używana dosyć powszechnie. Z tym że teraz do tego można dołożyć Spring Data i operacje na danych stają się jeszcze prostsze.
Kiedyś zwykle wykorzystywało się obiekty DAO, czyli Data Access Object, czyli takie klasy, które pozwalały wykonywać operacje na bazie danych. I tutaj w przypadku DAO było trochę więcej kodu, natomiast wykorzystanie Hibernate, było dosyć podobne do tego co robi się teraz.
Teraz mamy więcej ułatwień.
Natomiast jeśli chodzi o zapytania JPA, to jest podobnie jak z sqlem. W takiej aplikacji legacy, będziesz mieć bardzo dużo ciekawych przykładów, dzięki, którym możesz się nauczyć użycia JPA i ta wiedza może przydać Ci się na lata.
Kolejna rzecz To takie aplikacje, mają zwykle ubogi design, ogólnie kod w nich zwykle wygląda słabo, tak jakby został po prostu naklepany, bez jakiegoś większego zastanowienia.
I w takim projekcie możesz taki kod refaktorować, w sposób autoamtyczny, lub pół automatyczny, wydzielając metody prywatne z danego kodu, dzieląc w ten sposób duże metody na mniejsze.
I większość IDE ma skrót klawiaturowy, który pozwala wydzielać fragmenty kodu z istniejących metod do metod prywatnych. Wystarczy zaznaczyć jakiś fragment kodu i nacisnąć skrót, w IntelliJ jest to skrót CTRL+ALT+M, można też wydzielać kod do osobnych klas.
I taki refaktoring jest bezpieczny, bo właściwie nie zmieniasz działania kodu, a tylko przeorganizowujesz jego strukturę, co poprawia jego czytelność i ułatwia pracę z nim.
Kolejna sprawa, to taki projekty, często nie mają testów jednostkowych, więc możesz je zacząć pisać jeśli znasz temat testów jednostkowych. Jeśli nie to warto poznać temat i zacząć go stosować w praktyce, właśnie w takim projekcie legacy.
Jedną z technik refaktoryzowania kodu legacy, jest wcześniejsze bardzo dokładne otestowanie go testami jednostkowymi, dzięki czemu, gdy mamy już taki kod ostestowany, to możemy go zmieniać dosyć swobodnie, bo samo działanie jest sprawdzane przez testy.
Oczywiście nie jest to prosta technika zwłaszcza dla początkujących programistów, ale warto się nią zainteresować, bo dzięki temu możemy, nauczyć się bardzo wiele na temat pisania testów i pisania kodu.
Więc generalnie można wiele nauczyć się na temat refaktoryzacji w projektach. I refaktoryzacja jest zwykle potrzebna praktycznie w każdym projekcie. Jeśli rozwijamy projekt, to zawsze jest taki moment, że trzeba coś dodać, coś zmienić i potrzebny jest jakiś refaktoring.
Kolejna rzecz, której możesz się uczyć w takim projekcie to sama Java. Bo jak dostajesz pierwszą pracę, to znasz tak naprawdę tylko podstawy, znasz składnię, coś tam umiesz zrobić z kolekcjami, być może znacz strumienie i lambdy.
I tych rzeczy warto się uczyć i warto je doskonalić. Bo każdy już napisany kod, można zwykle napisać trochę lepiej. I tutaj jeśli chodzi o naukę samej Javy i pisanie kodu w niej, to tak naprawdę jest to kilka lat nauki, jeśli chcesz osiągnąć jakiś bardzo dobry poziom.
I wielu programistów uczy się używać różnych narzędzi, mimo że wielu z nich nigdy nie będzie używać produkcyjnie, a nie uczy się pisania w Javie.
Znają tylko podstawy, a często i z tym jest problem. A Java to podstawa.
I jak długo zostać w takim projekcie legacy?
Sam kilka razy, gdy nie trafiłem dobrze z projektem, miałem taki dylemat, czy zostać, czy po miesiącu, czy dwóch zmieniać pracę.
I jeśli to twoja pierwsza praca to tak naprawdę trudno powiedzieć. Bo zawsze chodzi o twoje umiejętności. Jak masz duże umiejętności i w takim projekcie legacy, całkiem dobrze sobie radzisz tylko, niestety, widzisz, że za wiele się jednak nie nauczysz,
to warto się rozglądać za nową lepszą pracą, bo w projekcie legacy łatwo się zasiedzieć, robisz ciągle to samo, ciągle spotykają cię podobne problemy.
I jak po kilku miesiącach ogarniesz się, to praca może się okazać całkiem znośna i możesz zostać na lata, tylko że po kilku latach, gdy zdecydujesz się na zmianę, to może być ciężko, ze względu na brak doświadczenia w nowszych technologiach.
A jeśli na początku radzisz sobie słabo, to raczej pozostań do momentu, gdzie zaczniesz radzić sobie lepiej, gdzie już będziesz poruszać się swobodnie przy realizacji nowych zadań.
Tak czy inaczej, w obu przypadkach nie polecam pozostawać długo w projekcie legacy jeśli to twoja pierwsza praca i projekt jest dosyć słaby, i nie wiele się tak naprawdę uczysz.
Bo będzie to negatywnie oddziaływać na twoją karierę. I pozostanie w takim projekcie więcej niż rok, zwłaszcza jak jesteś na początku swojej ścieżki, nie jest dobrym pomysłem.
Kluczowe tu będzie twoje radzenie sobie z zadaniami, jeśli radzisz sobie dobrze i czujesz się pewnie, to nie warto czekać, bo być może nic dobrego już Cię w tym projekcie nie spotka.
Oczywiście co innego jak masz już 5-10 lat doświadczenia i widzisz, że w projekcie są szanse na zmiany, na poprawienie pewnych rzeczy i wprowadzanie nowych technologii.
Wtedy to trochę inna historia. I ja też w takim projekcie pracowałem jako już doświadczony programista, ale wiedziałem, że projekt jest rozwijany, są szanse na nowe technologie i ogólnie idzie ku lepszemu.
Ale Pamiętaj, że nowa lepsza praca wcale nie musi być lepsza, na pewno będzie nowa, ale lepsza niekonieczne, tutaj bywa różnie.
A jak na częstą zmianę pracy patrzą rekruterzy? Jak będą to widzieć, gdy zmienisz swoją pracę po 3 miesiącach?
Trudno powiedzieć, na pewno będą o to pytać, pewnie część będzie trochę krzywo na to patrzeć, ale spróbuj być z nimi szczery, powiedz, że chcesz się rozwijać, a w tym projekcie nie ma na to szans, że są stare technologie, które nie do końca cię interesują na tym etapie kariery, że chcesz pracować w zespole z dobrymi developerami, żeby więcej się uczyć a w obecnym projekcie np. pracujesz sam i robisz tylko bugfixing. To normalne, że chcesz się rozwijać i większość rekruterów zrozumie.
Ja w swojej karierze miałem, dwa projekty, czy też dwie firmy, z których uciekłem po 3 miesiącach i co prawda to nie były moje pierwsze firmy, ale i tak musiałem się z tego tłumaczyć. Ale po prostu mówiłem, jak było.
Zawsze chciałem pracować w projektach, które dawały mi szanse wykorzystać swoją wiedzę i umiejętności. Jak trafiałem do projektu, który okazywał się jakimś nieporozumieniem, to nie zostawałem tam. Bo po prostu bym się tam męczył.
A to, że musiałem się później tłumaczyć, dlaczego byłem gdzieś tylko trzy miesiące, cóż to po części był wynik moich złych decyzji i złego rozeznania w kwestii nowej firmy, nowego projektu.
Mówiłem też o tym we vlog “Jak przygotować się do rekrutacji na programistę” Link zamieszczę gdzieś tutaj na karcie.
A w tym vlogu to już wszystko, mam nadzieję, że Ci się spodobał jak zwykle zachęcam do zasubskrybowania mojego kanału jeśli jeszcze tego nie robisz, zostawienia łapki w górę i podzielenia się swoją opinią w komentarzu. Dzięki i do zobaczenia w następnym materiale.
