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
0
edytowany 1x, ostatnio: MichuLFC
zimna pitulka
Można zmienić pracę ale czy to coś zmieni?
Jeśli produkt działa, jest żywy to siłą rzeczy głównym zajęciem jest utrzymanie go przy życiu.
Productionserver
apka ma ile lat?
Uśpiony wiosenny but
Zmieniłbym pracę, teraz tyle pracy nawet dla juniorów.
- Rejestracja:około 17 lat
- Ostatnio:2 dni
- Lokalizacja:Wrocław
17
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.
Ale on z tego Azure'a to ma pewnie Azure DevOps Server, także legacy soft przeniesiony na to coś dalej jest legacy :(
- Rejestracja:prawie 7 lat
- Ostatnio:ponad 2 lata
- Lokalizacja:Gdańsk
- Postów:647
6
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 :)
edytowany 1x, ostatnio: nobody01
Zobacz pozostałe 2 komentarze
No częściowo tak :P Ale się uczepiliscie. Jeśli ktoś wziął i wrzucił to legacy na azure, to znaczy, że są świadomi że legacy jest i trzeba coś z tym zrobić. OP wymienił tylko 2 technologie w stacku i żadna z nich nie jest legacy. Do tego dla niektórych legacy oznacza API w .net framework plus nie najnowszy angular. Pomijam jakość kodu
Czyli "Legacy code" == "przestażałe zależności", niezależnie od tech debtu?
Czyli np kod z funkcjami na 1000 linijek, 0 testów, jednoliterowy nazwy zmiennych, w projekcie gdzie są najnowsze zależności to już nie jest "Legacy"?
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
0
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:około 4 godziny
- Postów:5105
0
@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ć.
edytowany 3x, ostatnio: WeiXiao
- Rejestracja:prawie 7 lat
- Ostatnio:ponad 2 lata
- Lokalizacja:Gdańsk
- Postów:647
0
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.
Zobacz pozostałe 21 komentarzy
ale nie zawsze potrzebuje się zapoznać z jakąś ogromną specyfikacją na 500 stron, bo czasem domena jest relatywnie łatwa.
Chodzi mi cały czas o to, że złożoność domeny sama w sobie nie musi oznaczać niczego fajnego
No ok, można mieć wymagająca technicznie apke o prostej domenie. Ale chyba lepiej mieć doświadczenie przy pracy przy złożonych domenach? I to chyba kwestia organizacji pracy. Gdzie w tym wszystkim miejsce na analityków biznesowych? Dlaczego developer ma czytać 500 stron dokumentacji żeby dodać jakiegoś ifa? Mamy chyba jakieś testy napisane i można zmieniać kod bez obawy, że na prod pójdzie błąd. Do tego zmiana będzie też przetestowana przez testerów i innych ludzi znających dokładnie domenę.
@nobody01:
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.
I miałem okazje doświadczyć obu tych przypadków - domena dla mnie ciężka i bezużyteczna, a innym razem ciekawa, ale też bardzo obszerna.
- Rejestracja:ponad 9 lat
- Ostatnio:12 miesięcy
- Postów:57
3
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
12
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.
Zobacz pozostałe 4 komentarze
Zgodzę się co do czytelności projektu oraz większych kosztów jego utrzymania bo niestety niesie to za sobą np. konieczność dodatkowych aktualizacji baz danych, a nie tylko aplikacji. Natomiast w procedurze przechowywanej możesz zastosować dość złożone konstrukcje np. wykorzystując tabele tymczasowe, które pozwalają na znacznie szybsze wykonywanie zapytań. Z punktu widzenia użytkownika czekanie na wyniki zapytania np. 30s, a nie 5 min robi ogromną różnicę. Oczywiście mówię tu o tabelach z wieloma milionami rekordów, a nie takimi co zawierają kilka tysięcy rekordów..
moja niechęć do logiki w kodzie wynika z tego że juniorzy nie widzą różnicy między logiką w kodzie na serwerze a przerzuceniem wszystkich danych do frontu żeby sumę policzyć
- Rejestracja:ponad 8 lat
- Ostatnio:ponad 2 lata
- Postów:116
0
Lepsze stabilne legacy, niż greenfield w pośpiechu i nerwach.
gorzej jak masz do legacy featury dolepić w pośpiechu i nerwach :D
- Rejestracja:około 17 lat
- Ostatnio:2 dni
- Lokalizacja:Wrocław
1
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ć?
Zobacz pozostałe 3 komentarze
Wiec zalezy kto co ma na mysli po prostu
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.
@somekind: na poziomie kodowania, czy wyznaczenia dobrej, stabilnej architektury ? tak / nie (nie ma wyboru)
@ZrobieDobrze: ale czego dotyczy Twoje pytanie o poziom?
@somekind: Koment "na greenfieldzie jest lepiej"
- Rejestracja:około 11 lat
- Ostatnio:13 minut
- Postów:8397
4
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.
edytowany 2x, ostatnio: LukeJL
Dodam tylko jeszcze od siebie, że jak w nowym projekcie na etapie dev coś się sypnie to po prostu można wyzerować dane i próbować dalej, natomiast w utrzymaniu jak się pomylisz i funkcja nie zadziała prawidłowo np. źle przeliczając jakieś dane to dopiera zaczyna się karuzela. W utrzymaniu każdy ruch, każda nowa funkcja muszą być bardzo przemyślane i przetestowane bo tu nie ma miejsca na pomyłki, a poziom stresu to jest x100 razy tego co na czystym dev gdzie chyba tylko nierealne terminy mogą podnieść ciśnienie.
dokładnie, jak są prawdziwi użytkownicy (tudzież klienci, którzy oczekują zmian na już), to trochę inaczej niż jak jest sobie greenfield, po którym nikt nie będzie oczekiwał, że będzie nawet się uruchamiał i działał prawidłowo.
- Rejestracja:ponad 8 lat
- Ostatnio:ponad 2 lata
- Postów:116
0
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ł.
edytowany 2x, ostatnio: crx
- Rejestracja:ponad 4 lata
- Ostatnio:4 miesiące
- Postów:15
5
@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.
edytowany 7x, ostatnio: Bronzebeard
- Rejestracja:prawie 7 lat
- Ostatnio:ponad 2 lata
- Lokalizacja:Gdańsk
- Postów:647
1
@MichuLFC: jakie konkretnie technologie masz w projekcie? Wspomnienie o Azure i ci / cd spowodowało zamieszanie.