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?
- Rejestracja:ponad 2 lata
- Ostatnio:prawie 2 lata
- Postów:2


- Rejestracja:około 17 lat
- Ostatnio:3 dni
- Lokalizacja:Wrocław
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.
- Rejestracja:prawie 7 lat
- Ostatnio:ponad 2 lata
- Lokalizacja:Gdańsk
- Postów:647
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 :)


Michael Feathers introduced a definition of legacy code as code without tests, which reflects the perspective of legacy code being difficult to work with in part due to a lack of automated regression tests.
Ale znowu Wikipedia podaje: Legacy code is old computer source code. It could simply refer to an organization's existing code base which has been written over many years, or it could imply a codebase that is in some respect obsolete or supporting something obsolete.
- Rejestracja:ponad 2 lata
- Ostatnio:prawie 2 lata
- Postów:2
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

- Rejestracja:około 9 lat
- Ostatnio:29 minut
- Postów:5105
@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ć.
- Rejestracja:prawie 7 lat
- Ostatnio:ponad 2 lata
- Lokalizacja:Gdańsk
- Postów:647
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.


Ale chyba lepiej mieć doświadczenie przy pracy przy złożonych domenach?
jeżeli ma być złożona domena, a od technicznej strony bieda, to nie widzę jakiejkolwiek wartości w czymś takim.
Bo o ile nie poświęcisz na to bardzo dużo czasu/wysiłku lub nie będziesz pracował w niej wiele lat, to prawdopodobnie tej domeny dobrze nie ogarniesz i/lub ta wiedza będzie ci po prostu zbędna.
Jeżeli ci się podoba dana domena albo możesz się coś ciekawego dowiedzieć, co zwykły śmiertelnik spoza tej branży nie wie, to spoko.

- Rejestracja:ponad 9 lat
- Ostatnio:12 miesięcy
- Postów:57
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.
- Rejestracja:około 4 lata
- Ostatnio:około 2 lata
- Lokalizacja:Warszawa
- Postów:1092
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.

- Rejestracja:ponad 8 lat
- Ostatnio:ponad 2 lata
- Postów:116
Lepsze stabilne legacy, niż greenfield w pośpiechu i nerwach.

- Rejestracja:około 17 lat
- Ostatnio:3 dni
- Lokalizacja:Wrocław
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ć?


pisanie od 0 wymaga wiecej wysilku
- wątpię. Nie ma bugów, nie ma problemów z wydajnością, nie ma brakujących logów, nie ma żadnych wyzwań ani realnych problemów.


- Rejestracja:około 11 lat
- Ostatnio:minuta
- Postów:8397
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.

- Rejestracja:ponad 8 lat
- Ostatnio:ponad 2 lata
- Postów:116
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ł.

- Rejestracja:ponad 4 lata
- Ostatnio:4 miesiące
- Postów:15
@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.
- Rejestracja:prawie 7 lat
- Ostatnio:ponad 2 lata
- Lokalizacja:Gdańsk
- Postów:647
@MichuLFC: jakie konkretnie technologie masz w projekcie? Wspomnienie o Azure i ci / cd spowodowało zamieszanie.