Legacy projekt jako junior

Cześć,
Od jakiegoś czasu męczy mnie moja aktualna sytuacja w firmie. Zacząłem karierę w tamtym roku i właśnie prawie rok czasu jestem w projekcie który jest starą utrzymaniówką. Składa się z parunastu serwisów, ja jako programista .NET głównie odpowiadam za ...Jenkinsa, Azure i Confluence i czasem zadania maintenance typu zmiana czegoś w bazie. Krótko mówiąc - rzeczy DevOpsowe, programowania brak. Robię progres prywatnie, uczę się nowych rzeczy (design patterny, ci/cd, bazy danych już umiałem, asp.net core mvc czy webapi nie sprawa mi problemów) i wiem że wciaż długa droga przede mną zanim będę się swobodnie czuł w tych technologiach, ale co mi po nauce ich skoro komercyjnie nie moge tego wykorzystać. Co byście zrobili na moim miejscu?

Nie, jak masz Azure, to nie masz legacy.
Tak, zmień pracę, skoro robisz nie to, czego chcesz.
I pamiętaj, że doświadczenie przy utrzymywaniu większego systemu, który działa i ma użytkowników jest warte więcej niż klepanie nowego kodu, którego nikt nie widzi i nie używa.

Rozważałeś pogadać z przełożonym?

Projekt z Azure i CI/CD to legacy? :P Myślałem że legacy to raczej webformsy, jQuery, logika w procedurach T-SQL, push do mastera jako sposób pracy, no i oczywiście ręczne deploymenty przez rdp :)

Ale po co nas pytasz o zdanie? Już podjąłeś decyzję, że to legacy i w tym pracować nie chcesz, no to sprawa jest prosta - zmiana firmy

nobody01 napisał(a):

Projekt z Azure i CI/CD to legacy? :P Myślałem że legacy to raczej webformsy, jQuery, logika w procedurach T-SQL, push do mastera jako sposób pracy, no i oczywiście ręczne deploymenty przez rdp :)

ci/cd i azure nie istnieje od 2 lat tylko dobrę parę/parenaście :D

somekind napisał(a):

Nie, jak masz Azure, to nie masz legacy.
Tak, zmień pracę, skoro robisz nie to, czego chcesz.
I pamiętaj, że doświadczenie przy utrzymywaniu większego systemu, który działa i ma użytkowników jest warte więcej niż klepanie nowego kodu, którego nikt nie widzi i nie używa.

Nie mogę się z tym zgodzić (ze swojego braku doświadczenia mogę się mylić oczywiście), bo programista programujący w nowych projektach, robiący development jest jednak więcej warty niż programista mający tyle samo lat doświadczenia ale nie programujący nic, tylko odpowiedzialny za utrzymanie

@MichuLFC:

bo programista programujący w nowych projektach, robiący development jest jednak więcej warty niż programista mający tyle samo lat doświadczenia ale nie programujący nic, tylko odpowiedzialny za utrzymanie

nie wiem, ciężko dyskutować nt. takich ogólników, a jako że "robiący development" oraz "odpowiedzialny za utrzymanie" właściwie mogą znaczyć wszystko, to jeszcze ciężej.

To inaczej - innych rzeczy uczysz się gdy nagle trafiasz do projektu gdzie jest react i redis których nigdy nie używałeś, a innych gdy 2 lata pisałeś projekt, od pół roku siedzi na prodzie i nagle pojawiają się "dziwne problemy" - ktoś przekopiował dziwny znaczek z łorda do pola tekstowego i wyszło że encoding w całej appce jest skopany :D

klient się skarży że coś długo mieli, a tu jakieś query będące zwykłym N+1 lub może nawet czymś ciekawszym

bugi pokroju "u jednego usera nie działa"

może jakiś wyścig?

a może nagle klient chce przerobić jakiś core_feature i wychodzi jak wszystko jest ze sobą pohakowane trytytkami i ifkami

Ja oczywiście nie twierdzę że nie masz racji co do swojego przypadku i może faktycznie powinieneś uciekać.

Warto też pamiętać że development to często klepanie crudow. Jeśli nie trafisz do jakiegoś projektu z zaawansowaną architektura, skomplikowana domena i mocnymi ludźmi w zespole, to z tym rozwojem raczej nie będzie lepiej.

MichuLFC napisał(a):

Nie mogę się z tym zgodzić (ze swojego braku doświadczenia mogę się mylić oczywiście), bo programista programujący w nowych projektach, robiący development jest jednak więcej warty niż programista mający tyle samo lat doświadczenia ale nie programujący nic, tylko odpowiedzialny za utrzymanie

Dziwnym trafem jednak jak już to więcej płacą za pracę przy "legacy", niż przy fancy super hiper nowym greenfieldzie. ;) I też jednak umiejętność developmentu w istniejącym kodzie na produkcji, bez dorzucania tony bugów jest bardziej pożądana, niż doklejanie na ślinie kolejny featurów do nieprodukcyjnej apki.

Powiedzmy sobie to jasno - legacy nie jest wprost powiązane ze starością projektu. Może być projekt 10 letni który jest odpowiednio utrzymywany i być nie legacy (mimo że nie ma najnowszej wersji frameworka i Kafki) i może byc projekt napisany pół roku temu kijowy, nie utrzymywalny spaghetti i w ogóle. Człowiek który ma trochę ekspa już (na ogół) nie jara się tym ktora wersja frejmłorka jest w aplikacji.

Lepsze stabilne legacy, niż greenfield w pośpiechu i nerwach.

MichuLFC napisał(a):

Nie mogę się z tym zgodzić (ze swojego braku doświadczenia mogę się mylić oczywiście), bo programista programujący w nowych projektach, robiący development jest jednak więcej warty niż programista mający tyle samo lat doświadczenia ale nie programujący nic, tylko odpowiedzialny za utrzymanie

Ok, a z czego ta większa wartość miałaby wynikać?

MichuLFC napisał(a):

Nie mogę się z tym zgodzić (ze swojego braku doświadczenia mogę się mylić oczywiście), bo programista programujący w nowych projektach, robiący development jest jednak więcej warty niż programista mający tyle samo lat doświadczenia ale nie programujący nic, tylko odpowiedzialny za utrzymanie

Trochę dziwne założenia robisz w tym zdaniu.

• W kontekście tego, co piszesz w pierwszym wątku, wpadłeś w jakieś dev opsy i je nazywasz "utrzymaniem". I teraz tak - co do devopsów, to nie chcę się wypowiadać ile są warte (to już by trzeba sprawdzić patrząc na widełki dla devopsów), natomiast w tym momencie przestajesz de facto pełnić obowiązki programisty, jeśli jedyne, co robisz, to Jenkins
• Natomiast "utrzymanie" może również polegać na pisaniu kodu (i czytaniu! Bo to jest często większym wyzwaniem i więcej czasu zajmuje. Gdzie spędzasz godziny na czytaniu kodu, żeby raptem parę linijek zakodzić swoich), więc jak najbardziej programista odpowiedzialny za utrzymanie może programować.
• bo programista programujący w nowych projektach, robiący development jest jednak więcej warty niż programista mający tyle samo lat doświadczenia ale nie programujący nic, tylko odpowiedzialny za utrzymanie - fikołek logiczny trochę jak u Matiego, ale zasmucę cię, żaden z nich nie będzie członkiem elity narodu polskiego ;) to, ile ktoś będzie warty na rynku zależy od wielu czynników (rzeczywiste umiejętności, wpasowanie się w potrzeby rynku, umiejętność sprzedania się, umiejętności negocjacyjne itp.), tym niemniej utrzymanie jest z reguły trudniejsze. Napisać greenfield każdy umie, bo skala jest mniejsza i mniej ograniczeń. To utrzymanie istniejącego projektu jest trudne.

Moim zdaniem w takim legacy jakbyś chciał to byś się więcej rzeczy nauczył aniżeli zmiana pracy i pójście na greenfield. Pomyśl nad automatyzacją powtarzalnych zadań, na refactoringiem kodu, jakością, skanowaniem pod podatność na ataki, nad usprawnieniem środowisk, monitoringiem/alertami, dobrą dokumentacją. Podejrzewam że tam jest robiony co niemiara. Ja bym pracy nie zmieniał.

@scibi_92 i @LukeJL mają dużo racji.

Dodam swoje trzy grosze.

Sam kilka lat temu myślałem, że czym nowszy frejmłork, tym lepszy projekt. Przecież w ogłoszeniach wymagają znajomości takich rzeczy! Potem raz czy dwa zdarzyło mi się trafić do ekipy, która do komunikacji asynchronicznej brała Kafkę, bo tak, a koncepcja partycji w tejże była dla nich czarną magią. Podobnie jak takie podstawowe rzeczy, jak: monitorowanie pól wątków i liczby otwartych deskryptorów albo ustawianie timeoutów w klientach do komunikacji synchronicznej po HTTP (socket, request, connection timeout, itd.). Nie żebym ja był jakimś wybitnym fifa-rafa.

Człowieku, a kto tak robi?! Przecież działa.

:)

może byc projekt napisany pół roku temu kijowy, nie utrzymywalny spaghetti i w ogóle

Potwierdzam. Warto mieć to na uwadze. Różne są greenfieldy. Jedne typu rewrite, inne typu rośnie nam biznes lub platforma i potrzeba coś z tym zrobić.

Jeśli rewrite, to dobrze trzymać się z dala od produktów, gdzie nie ma w ekipie analityków i programistów, którzy znają bolączki tego, co jest do przepisania. Mnie nigdy nie sprawdziła się rewolucja. Za to sprawdzała się ewolucja.

Jeśli rośnie biznes lub platforma i potrzeba coś z tym zrobić, to dobrze, jeśli w ekipie jest ktoś kto zna istniejący biznes lub platformę. Słabo, jeśli cały zespół przychodzi z zewnątrz.

Z mojego doświadczenia, żeby greenfield po poł roku nie skończył jako spaghetti, potrzeba minimum:

• CI,
• statycznej analizy kodu, która na poziomie CI będzie wykrywać code smells, wymuszać formatowanie oraz pilnować złożoności cyklomatycznej czy przestrzegania reguł, na które umówił się zespół,
• automatycznych testów architektury spiętych z CI (np. ArchUnit), żeby ustalenia co do konwencji w kodzie były automatycznie egzekwowane,
• monitoringu i systemu alertowania spiętego z Pager Duty,
• dziennika ważnych decyzji, żeby te był podejmowane świadomie,
• pokory w ekipie,
• mądrego i zaangażowanego lidera, który będzie ogarniać ludzi, którzy:
  -- ciągną w dół,
  -- proponują wyłączyć alerty w Pager Duty,
  -- są interesariuszami i chcą przekonać do fake it till you make it.

Niemniej, może to tylko mój jednostkowy przypadek i możesz to potraktować jako dowód anegdotyczny.

Znajdziesz wiele legacy, w którym te rzeczy są. Znajdziesz też wiele legacy, gdzie tego nie ma. Podobnie z greenfieldami.

Jeśli jesteś Juniorem i szukasz dla siebie dobrego miejsca, to zamiast pytać o to czy dużo programują reaktywnie, lepiej zapytać o to jak ekipa rozwiązała problem logowania z MDC programując reaktywnie. Dobrze jest też poprosić, żeby pokazali Ci jak wdrażają zmiany na produkcję. Czy mają testy, automatyczny provisioning... Już samo to dużo mówi.