Co myślicie o starszych technologiach w ofercie pracy, jak np JSF?

1

Większość pewnie zna firmę Assecco. Obecnie widzę że mają taki stack w ogłoszeniu:

Doświadczenie w pracy przy realizacji projektów komercyjnych
Dobra/bardzo dobra znajomość Java 8-11
Doświadczenie w pracy z Spring/Spring Boot, Hibernate
Znajomość SQL i zagadnień związanych z relacyjnymi bazami danych
Znajomość systemów kontroli wersji
Znajomość wzorców projektowych
Bardzo dobra znajomość Git
Znajomość JEE, JSF, JPA
Umiejętność pisania testów jednostkowych JUnit
Umiejętność pracy w zespole

Większość standardowa. Jednak zastanawiam się jak się zapatrujecie na takie leciwe technologie jak JSF?

2

Ja takie ogłoszenia omijam, bo dla mnie to furtka do wrzucenia cię w stary projekt na utrzymanie. Nie musi od razu być na full time, tylko na przykład na 30% i potem 70% czasu dłubiesz w Springu i nowej dżawie, a 30% czasu bawisz się w archeologa. Może być też tak że ci powiedzą sorry stary, start projektu się opóźnia więc żebyś się nie nudził to mamy tu taką starą apkę, którą trzeba utrzymywać. Potem projekt startuje a ty zostajesz w starym projekcie.

1

legacy + dużo AbstractBeanFactoryFacadeSingletonHandlerProvider

1

Unikaj Asseco.

2

ogólnie stare projekty nie są złe, robiąc refaktor i patrząc jak bardzo te zmiany nie działają można się sporo nauczyć. Legacy zazwyczaj już jest na produkcji więc nie bedzie AbstractFactoryFacadeSingletonHandlerProviderForThingsSomebodyThinksAreNeededAndOtherBriliantIdeaForNonExistingUser

aczkolwiek JSF brzmi groźnie a w połączeniu z JEE może być bardziej projektem do edycji xml'i łączących biny i kontenery niż do edycji kodu

2

No pytanie, ile tak naprawdę jest firm które nie mają de facto jakiegoś legacy, a przynajmniej starych projektów, które trzeba utrzymać. :)

6

Stare technologie i legacy projekty nie zawsze są takie złe. Jeśli to projekty, które przynoszą dużo kasy to utrzymanie może być całkiem spoko (dobrze płatne + czas na pisanie dobrego kodu). Ważne, żeby móc robić swoje i nie musieć robić nowego kodu staro.
Nie miałbym problemu z poprawieniem jakiegoś IFa w JSF, ale jakby się okazało, że mam pisać kolejny serwis w tym gównie to już bym protestował.

Niestety z tak bezdennie głupimi technologiami jak JSF (to nie jest problem, że jest stara, problem że jest głupia) - dostaje się zwykle "architektów", którzy dbają o to, żeby pisać kod możliwie idiotycznie. I to potrafi męczyć.

3

Wg mnie bardzo istotne jest — istotniejsze nawet od samej technologii — co z tym projektem robimy. Zupełnie inaczej się pracuje, gdy mamy stary projekt, który działa i trzeba go utrzymywać; inaczej, gdy przepisujemy stary na nowy; i jeszcze inaczej, gdy ten stary projekt trzeba przerobić na coś, do czego nie był zupełnie przystosowany.

A potem jeszcze liczy się to, jak do tego zadania podchodzi szef zespołu — czy mamy pisać „po staremu”, „żeby było spójnie” (spójnie źle, znaczy…), czy „starego nie ruszać, ale nowy kod pisać dobrze”.

Z samych użytych technologii tego, niestety, nie wywnioskujesz. Możesz mieć przyjemną, bardzo sensowną pracę z utalentowanymi ludźmi, a możesz mieć kręcenie bicza z piasku i rzeźbienie w ekskrementach.

3

Jak zawsze to zalezy. Lubie prace ze starymi projektami bo przewaznie laczy sie to z bardzo spokojna praca. Przy czym bedac zadowolonym w aktualnym projekcie z w miare swiezymi rzeczami, nie widzialbym powodu zeby zmieniac na cos takiego.

Najwiekszy minus - zdobywamy doswiadczenie w starych technologiach a poniewaz rekrutacja w IT jest z**** to gdy pozniej chcemy zmienic prace jestesmy w lesie, bo nie dostaniemy pytan z JSF tylko z Javy 21 wiec trzeba sie dodatkowo samemu ksztalcic i fajnie jakby pensja to uwzgledniala.

0

Jako kontraktor zatrudniony przez pośredników nie zainteresowałbym się takim projektem ale bezpośrednio dla jakiegoś stabilnego klienta na pewno bym rozważył.

1

Asseco to między innymi dawny Prokom. Panowie zbudowali system dla ZUSu który kosztuje tyle, co misja sądy kosmicznej na granice układu słonecznego. Nie wiem czy w tej części świata ktoś pobił ich rekord.

Asseco bierze projekty z dolnej półki. Sektor publiczny, małe banki. Kilka projektów temu miałem w zespole zawodnika po ośmiu latach w Asseco. Sam nie wiedział kim chce być. Czy backendowcem, fullstackiem, frontendowcem, a może weźmie się za data science. Gość miał ewidentne braki w wiedzy. Ratował go fakt, że w projekcie był bałagan, że mieliśmy zepół kilkunastu osób, że nikomu nie chciało się zaglądać do cyferek.

Co do projektów legacy. Na pewno jest to spokojna robota. Na pewno wielu klientów wyrazi wdzięczność. Na pewno jest to doby temat jako drugi projekt. Na pewno jest to sposób na wygone życie za sensowną kasę. Pytanie tylko co dalej bo wszystko prędzej czy później się kończy.

3

Może jeszcze samo JSF nie jest najgorsze - da się w tym w miarę normalnie pisać - problem w tym, że mało komu się chce czego efektem są posrane zagnieżdżenia w szablonach html, pomieszane ze sobą include i exclude, które da się zrozumieć tylko jeśli samemu się to pisało. To wszystko natomiast blednie w porównaniu z kretyńskimi technologiami ciągnącymi się za JSF jak smród za stadem bawołów. Najgorzej wspominam bibliotekę do mapowania dozer, która mapowała w runtime a podczas kompilacji nie sprawdzała nawet typów (bo wszystko ładowane było przez settings w xmlu). Z tego smutnego okresu w moim życiu wyniosłem jednak wiedzę, że jeżeli istnieje piekło dla programistów to dozer jest tam obowiązkowo.

1

Pracowałem parę lat przy projekcie legacy. Doszliśmy do limitu otrzymania oraz rozbudowy całej apki. Rozpoczęliśmy migrację na mikroserwisy. Była to niezła szkoła. Jak szukasz odpoczynku to myślę, że jest to jakaś opcja. Mi starczyło czasu na robotę, na szykowanie się do rekrutacji w fangu, na nowe hobby, na rodzinę która się powiększyła. Klient doceniał, że nie marudzę, nie narzekam, że nie robię im pod górę. Owszem mieliśmy trochę spin z architektem ale typ zwyczajnie nie ogarniał i wyleciał w sumie zanim zdążyłem się zwolnić.

Moim zdaniem jeśli ktoś chce się rozwijać to legacy jest ok na dwa czy trzy. Potem stajesz się mniej konkurencyjny.

0

Jeśli znasz daną technologię, to czy jest leciwa, czy nie, dla mnie ma drugorzędne znaczenie. Jak nie znasz, to szkoda wchodzić.

Gorzej jak trafisz na projekt, w którym owe technologie stanowią najmniejszy problem, np. rozwiązania dla takiego ZUSu mogą być mega złożone biznesowo i integracyjne, wówczas obecność JSF w jakimś komponencie nie robi znaczącej różnicy.

1

Osobiście unikał bym wchodzenia w geriatrię programistyczną. Panuje ageism, daj zarobić kolegom 55+...

1

yarel napisał(a):

rozwiązania dla takiego ZUSu mogą być mega złożone biznesowo i integracyjne

Po internetach wala się dokument o systemie zusu zwanym ksi (komeksowy system informtyczny). Biorąc nawet pod uwagę technologie nawet dwie dekady temu to ktoś mocno popłynął. Instytucje które mają takie potrzeby powinny posiadać własny pion od rozwijania aplikacji, a nie brać z zenątrz coś co jest posklejane na klej i taśmę.

tutaj dokument z asseco https://pl.asseco.com/files/public/uploads/case_study/Asseco_Case_Study_KSI_ZUS.pdf