Dlaczego nowicjusze tak psioczą na legacy?

Przecież to najlepsza szkoła przetrwania i nawigacji w kodzie.
Rozwijająca mózg gimnastyka.
Jak chcą zostać profesjonalistami bez doświadczenia z legacy?

bo bycie programista to jest teraz moda, a jak kazda moda ma swoje "narzedzia"(w naszym wypadku) i kazdy chce byc na topie uzywac react/angular na front-end zamiast jquery to tak jakby miec iphone zamiast samsung s3 nie wiem czy da sie zrozumiec porownanie

w sumie to masz racje ze skill robi sie wlasnie na legacy / "spaghetti" code albo ogolnie na czyms kto napisal ktos inny czy byloby to zajebiscie napisane lub bardzo c****** :)

Czym innym jest psioczenie na stary kod, a czym innym na sposób prowadzenia projektu. Na stary kod najbardziej narzekają nowicjusze, a doświadczeni najbardziej zwracają uwagę na sposób prowadzenia projektu.

Siedzenie w legacy kodzie w punktu widzenia nowicjusza się niespecjalnie opłaca, bo nie może sobie wstawić w CV modnych buzzwordów i tym samym jego CV nie będzie popularne.

bo programista przynajmniej 50% czasu poswieca na czytanie cudzego kodu co wcale nie jest latwe i trzeba to umiec. Nowy naklepie jakis szajs bez testow w startapie, za pol roku juz go nie bedzie, a inni beda sie z tym meczyc. peszek

50%? Raczej 90%. Programowanie to głównie czytanie, a nie pisanie kodu.

Narzekać każdy może, sam kiedyś głośno komentowałem.

Inna sprawa, że rzeczywiście to jest niezła szkoła, bo zazwyczaj są to wielozadaniowe monolity, które dużo trudniej się ogarnia niż proste aplikacje będące trochę bardziej skomplikowanymi CRUDami.

Bo doświadczeni widzieli tyle kodu że im szkoda słów na komentowanie czegoś słabego.
A nowicjusz myśli że jak ponarzeka to przyjdzie PM-zbawca i mu każe to przepisać na lepszy kod.

Poza tym nie zapominajmy o podstawowej definicji - "kod legacy to kod który nie ma testów".
Wg tej definicji nie chodzi wcale o narzędzia czy wiek projektu.
Kod legacy można mieć 1 mc po pierwszym wdrożeniu.

Myślę, że bardziej niż na legacy młodzi narzekają na to że w ich projekcie nie ma nowinek.
I im się nie dziwię, pochodzili trochę na konferencje, zdali certyfikaty, błyskają lambdami i streamami w DDD na każdej rozmowie.
A potem przychodzi smutna rzeczywistość - EJB 2.1 osadzony na JDK 8.

Ja mogę się pochwalić, że trafiłem najlepiej jak chyba można było. Moja pierwsza praca, najpierw 5 osobowy zespół, potem zostało tylko 2 (ja junior + team leader), projekt 1,5 letni, bardzo duży, Spring Booty i te sprawy, standardowy Javowy stos. Dlaczego uważam, że najlepiej jak tylko mogłem ? Dlatego, że projekt przeszedł 3 rewolucje architektoniczne, z małej aplikacji jedno WARowej, zrobiło się kilkanaście WARów + SSO, zmiana języka kodowania z angielskiego na polski (ze względu na złożony biznes i brak dokumentacji).

• nauczyłem się nowych, modnych technologii (właściwie to się w nich wyskillowałem bo już wcześniej uczyłem się ich na włoską rękę i opanowałem je dość dobrze)
• nauczyłem się skakania po projekcie. Na początku naprawa bugów zajmowała mi mnóstwo czasu, bo trzeba było szukać i debugować, a po 3 miesiącach byłem w stanie poprawiać je w ciągu kilku godzin.
• i najważniejsze, że byłem świadkiem wspomnianych rewolucji, akurat tylko jednej za mojej pracy w tym projekcie. Pierwsze dwie były przed moim dołączeniem do zespołu

Osobiście uważam start mojej zawodowej kariery jako najlepszy jaki tylko mogłem wymarzyć i polecam każdemu innemu taski start, jeśli tylko mają możliwość wyboru ;)

EDIT: A młodzi psioczą bo są głupi, za parę lat zmienią zdanie. Są też drudzy, gorsi, którzy psioczą i narzekają na firmę, a jak im się powie by odeszli - to wolą zostać. Hajs się musi zgadzać, a wygodne życie i lecenie w kulki podoba się wielu. Ale kiedyś to się zemści :P

Jako że coś o tym wiem :D To wynika raczej z faktu że po prostu dosyć często takie projekty są bardzo trudne w ogarnięciu, zwłaszcza na początku. Tutaj raczej nie chodzi o to że nie ma najnowszej wersji Spring Boot, tylko że łamana jest SRP, klasy z jedną metodą plubliczną mają po 20 pól etc ;)

W zasadzie to dla doświadczonego programisty sukcesem powinno być doprowadzenie poplątanego kodu do porządku, a nie sprawne gmatwanie go jeszcze mocniej. Praca z pogmatwanym kodem będzie cennym doświadczeniem jeżeli poprawimy jego jakość przez upraszczanie, modularyzację (czy też nawet wydzielenie mikroserwisów), zwiększenie pokrycia testami, sensowne ustrukturyzowanie, zmniejszenie złożoności cyklomatycznej (co jest formalną miarą pogmatwania), zastąpienie niepotrzebnie naprodukowanej logiki wykorzystaniem szeroko znanych funkcji bibliotecznych czy też np wprowadzenie idiomatycznych konstrukcji (wzorce projektowe specyficzne dla danego języka) zamiast oryginalnych konstrukcji czytelnych tylko dla autora.

Rzeczywistość jest taka, że niezależnie czy trafiliśmy do legacy monolitu czy nowego projektu trzeba cały czas dbać o jakość kodu. Jeśli tego nie zrobimy to nawet greenfield project szybko zamieni się w brownfield project. Poprawianie jakości kodu można trenować zarówno na starym jak i jeszcze świeżym kodzie, ale przy nowych projektach łatwiej jest jednocześnie dorzucać nowinki technologiczne, co czyni programowanie bardziej interesującym.

Jakieś przykłady kodu przed i po?

@Wibowit: tu masz racje. Ja na przykład jak zaczynałem w obecnej firmie to miałem legacy kod, burdel, tysięczniki z xmlową konfiguracją, a teraz przenosimy sie na mikroserwisy i nawet sie ciesze że mam okazje poprawiac jakość :)

Jak się trafi na taki moment "rewolucji architektonicznej" albo ma się po trochę do czynienia z legacy a trochę z nowym kodem, to fakt, że się można wiele nauczyć. Ale jak taki nowicjusz trafi w samo legacy, to nie sądzę, że się wiele nauczy - raczej zamiast poprawiać ten kod nauczy się pisać podobnie do tego z czym się spotka... A w każdym razie jest spore ryzyko, że tak będzie