Czołem!
Jakiś czas temu trafiłem na ofertę pracy z czymś dosyć starym - rozwijanie i utrzymanie. Jako iż jest 2017 rok i aktualnie mamy Javę, C#, Python, PHP (sic!), JS, Ruby itd. zacząłem się zastanawiać wieczorową porą czy byłby sens wejść w taki projekt? Przypuśćmy, że robię w takim projekt 'in', a po powiedzmy 2 latach 'out' - przy założeniu, że po godzinach klepię sobie rzeczy w nowożytnych technologiach aby nie wypaść z obiegu - jak duży byłby koszt (osobisty) wyjścia z takiej jaskini? Późniejsze przejście z utrzymaniówki i rozwoju jakiegoś bardzo starego systemu odbiłoby się na rekrutacji przy czytaniu cv?
Osobiście dobrnąłem do wniosków iż po takim czasie w specyficznym projekcie mógłbym zyskać na pewno sporą wiedzę, którą w jakiś sposób można przecież przelać na nowe projekty. Może też zyskałby człowiek zaciekawienie (albo wyśmianie) rekruterów jak rekruterów ale ludzi technicznych? Bo przecież zawsze to jakiś zupełnie inny punkt widzenia.
Ktoś skłonny do swoich argumentów za/przeciw?
Moim zdaniem umiejętność odnajdowania się w niesprzyjających okolicznościach, analizowania i poprawiania antycznego kodu, to jest coś, co odróżnia profesjonalistę od juniora, który wiecznie chce pracować w najnowszych technologiach.
Nie wchodź w to. W starym projekcie nie nauczysz się dobrych praktyk, bo zwykle o nich już dawno zapomniano a ludzie tak rotują że nie mają na to czasu bo nim zdążą się zapoznać z projektem już odchodzą.
Korzystanie ze starych technologii ma jeden plus - możesz spowodować uśmiech na twarzy kolegów gdy im powiesz w czy pracowałeś (ew. zakłopotanie).
Na CV to nie ma bezpośredniego wpływu, o ile masz coś jeszcze w tym CV. Wpis typu "COBOL" w CV nie jest natychmiastowym sygnałem do odrzutu o ile robiłeś coś z innymi technologiami (i możesz się tym pochwalić - np. strona www, GitHub, certyfikat).
Maintenance ma jeden plus - jest to robota którą ktoś musi wykonywać. Czyli dużo łatwiej się dostać na takie stanowisko niż do green field. Jeśli trafiasz w technologię docelową, ale w działce maintenance to może się to dla Ciebie okazać nawet pozytywne - łatwiej jest coś poprawić co kiedyś działało niż pisać od nowa w technologii o której się głównie czytało.
To straszne, ale już od dawna (2002 - dostałem na twarz kobyłe z lat 90-tych) lubię stare systemy:
- Greenfielda każdy głupi umi zrobić
- Dużo można się nauczyć z pomysłów innych - czasem bywały to głupie pomysły, ale zwykle ciekawe
- Kasa - i to nie tylko chodzi o zarobki, te stare systemy są często podstawą działania jakiejś firmy - więc nikt nie skąpi budżetu na testy czy poprawę jakości oraz toole (!!!)
- Jak chce się coś zmienić /dodać/ poprawić to jest naprawdę ciekawie i wymaga dużego możdżenia - zwłaszcza, że zwykle nie można ryzykować ubiciem produkcji nawet na kilka godzin
- Zwykle te systemy ledwo dysza - więc dużo się można dowiedzieć i poćwiczyć w tematach związanych z wydajnością
minus
-1 . Nie warto zostać z tylu -więc albo poświęcasz pewną część pracy na ćwiczenie nowych technologii... albo zmieniasz taki projekt na inną staroć po 2-3 latach :-)
Ci z was, którzy ukończyli przynajmniej studia poziomu inż. z informatyki poznali Wujka Boba. Pokazywał na swoich błędach jak prosto zrobić nowy system od zera i jak trudno go później rozwijać i utrzymywać.
Stary Wujek Martin kipeski być, nie dorastać do piętaszki dobra wymiatacz najnowsza frameworki.
Praca ze starym, zasyfiałym i totalnie nieprzemyślanym systemem, to po prostu praca w trudnych warunkach. Jak chcesz więcej, to proponuję obciąć ram w kompie do 4 GB dla większej frajdy. Na pewno jest to przydatna umiejętność, ale mamy tak szeroki wybór że lepiej skupić się na czymś innym. To co jest istotne, to praca z systemem na produkcji, który już swoje przeszedł, ale nadal jest w sensownej kondycji.
I na pewno nie zgodzę się że zrobić system od nowa to pryszcz, a utrzymać to ciężko. No chyba że nie zależy nam na jakości. Widziałem już systemy nówki sztuki, jeszcze nie wdrożone na produkcję, a już było widać że utrzymywać to to będzie problem, a widziałem też kilkuletnie które były naprawdę w świetnym stanie. Więc zrobić coś na chwilę od nowa jest łatwo, ale jeżeli ma być utrzymywane długo, to początek jest równie ważny co rozwój.
Moim zdaniem nie warto iść w stare systemy. Nie wyniesiesz z tego za dużo, a nabawisz się siwych włosów. Jeżeli faktycznie chcesz nabyć doświadczenia w utrzymaniu, to idź do supportu dla jakiegoś systemu który działa już kilka lat, ale nie umiera. Takiego którego jedyną sensowną naprawą nie jest zastąpienie, a który może żyć jeszcze wiele lat i dalej się rozwijać. Takie doświadczenie jest przydatne i warte uwagi.
A ironia o super nowych technologiach w odpowiedziach jest zbyteczna. Co innego ogarniać jak zmienia się świat i wiedzieć czego używa się dzisiaj, a co innego jarać się technologią która wyjdzie jutro a umrze za miesiąc. W tym pierwszym nie ma nic złego, a nawet jest zdrowe.
vpiotr napisał(a):
Nie wchodź w to. W starym projekcie nie nauczysz się dobrych praktyk
No, bo nowe projekty są pełne dobrych praktyk, takich jak np. encja na twarz i pchasz, kontrolery z logiką biznesową operujące bezpośrednio na repozytoriach zawierających drugą połowę logiki biznesowej, interfejsy do wszystkiego i testowanie mocków.
Tyyyyyle można się nauczyć! A potem pisać legacy code od pierwszego dnia.
Ja t tu tylko zostawię jako ciekawostkę historyczną :)
https://www.technologyreview.com/s/538966/what-is-the-oldest-computer-program-still-in-use/
Ogólnie praca ze starym kodem to normalna robota. Często rozwój + utrzymanie wymusza dużo kompromisów, ale często można się sporo nauczyć.
Na pewno nie warto brać się za utrzymanie, jeśli projekt co roku utrzymuje inna firma. To znaczy, że prawdopodobnie stan techniczny to dno. Poza tym nie będzie się od kogo uczyć (przechodziłem przez taki case, krytyczny system dla jednej z ważniejszych spółek skarbu państwa, prawdziwy mordor).
Wydaje mi się, że też rotacja kadrowa i zmiana ludzi, którzy utrzymują (ucieczka do innych firm, nie działów) i utrata wiedzy jest przyczyną degradacji systemów.
Legacy code - spoko, pod warunkiem, że można go usprawniać a nie tylko support.
margor90 napisał(a):
Wydaje mi się, że też rotacja kadrowa i zmiana ludzi, którzy utrzymują (ucieczka do innych firm, nie działów)
A czemu ludzie uciekają? Bo projekt to jakieś koszmarne spaghetti big ball of mud.
A czemu tak jest? Bo sami go tak napisali.
W efekcie ludzie wiecznie uciekają przed swoimi dziełami.
i utrata wiedzy jest przyczyną degradacji systemów.
Żeby coś stracić trzeba to najpierw mieć.
U mnie to się przedstawiało mniej więcej tak:
| Od zera | Utrzymanie |
|---|---|
| Nowe technologie | Dużo różnych technologii |
| Setki linni kodu dziennie | Czasem jednka linijka na 2 tygodnie |
| Bezpiecznie | Dużo łatwiej zepsuć produkcję |
| Zastanawianie się jak coś napisać | Szukanie błędu |
| ------- | Analiza wydajności i optymalizacja |
| Lekki refucktoring | Czasem bardzo poważny refucktoring |
| Znajomość frameworków | Znajomość przypadków brzegowych |
| Co mam zaimplementować? | Co to w ogóle robi? |
| Głównie DEV | Głównie Logi, Baza i OPS |
| Bardzo dobra znajomość logiki | Czasem traktowanie systemu jak blackbox |
| Czasem radosna twórczość | Użeranie się ze skutkami radosnej twórczości |
| Nauka jak roić | Nauka jak nie robić |
Na rozmowach kwalifikacyjnych to faktycznie wypada się słabiej po dłuższej pracy na wsparciu, bo rekruterzy są przeważnie osobami które tego wsparcia nie robią, więc naturalnie będą pytać o coś co jest ważne w ich pracy, a czego zupełnie się nie używa/nie robi na wsparciu.
Jak się dostanie zadanie do napisania to też wypada się słabiej, bo zwyczajnie nie ma się w tym praktyki, bo przeważnie operacje są chirurgiczne i najtrudniejszą rzeczą nie jest napisanie kodu, a znalezienie dla niego odpowiedniego miejsca.
@Skromny Szewc, refucktoring to hardkorowa wersja refuctoringu? :)
@testowy_user:
Celowo tak to napisałem, bo "klątw" jest czasem dużo.
Jeżeli np trafiam na taki kod, bez testów oczywiście, i na każdym poziomie wykonywana jest jakaś logika w statycznej funkcji która wykonuje dużo efektów ubocznych to niestety miłe słowa na usta się nie cisnął.
Nie mogę od tak wyekstrachować najardziej zagłębionych, bo wszystko jest ze wszystkim statycznie powiązane i nawet jak IDEA nie podkreśli to wcale nie ma pewności, że to dalej dobrze działa.
@Hispano-Suiza:
To będziesz musiał samemu ćwiczyć normalne programowanie lub liczyć się z tym, że część rekruterów pracę na supporcie uważa za coś gorszego i mniej ważnego niż twprzenie kodu od 0.
Troche loteria, bo jak trafisz na rekrutera który nigdy na supporcie nie był, to on oczywiście będzie pytał od strony którą zna więc będzie Ci trudniej.
Czasem jednak trafiają się rekruterzy którzy wiedzą, że projekt nie kończy się na wdrożeniu i potraktują taką wiedzę jako zaletę.
IMO prawie na pewno po 2 latach supportu potrzeba będzie ze 2 miesięcy na ponowne przyzwyczajenie się do klepania dużej ilości kodu.
Jeżeli by tego supportu miało być do pół roku, to imo takie coś każdy przejść powinien, bo to bardzo otwiera oczy na konsekwencje drobnych zaniechań podczas pisania systemu.
Po czymś takim gwarantuję, że zawsze będziesz już robił acces logi, albo ustawisz dużo constraintów na bazie.
@Hispano-Suiza:
IMO nawet jeżeli to by miało być samo wsparcie, to nic nie szkodzi żeby sprawdzić czy Ci się spodoba taka rola.
W najgorszym razie można po pół roku lub nawet wcześniej zagrozić odejściem, lub zwyczajnie pracę zmienić.
Ja tak pracuję juz kilka lat i ma to swoje plusy, jeżeli oczywiście SLA jest podpisane sensownie.
Co Ci mogę poradzić, to zapytać o to czy to jest support w godzinach pracy, czy 24/7 z dyżurami telefonicznymi, oraz właśnie o czasy SLA.
Dobrze też podpytać kogoś w tym projekcie jak to wygląda i jak często są zgłoszenia.
Jeżeli SLA na krytyka to 6h, a system jest na tyle niestabilny, że wyeliminowanie krytyka to coś więcej niż restart jakiejś usługi, to ja bym od tego uciekał.
@Hispano-Suiza:
Jeżeli masz podane rozwój i utrzymanie, to tak na prawdę, może to być tylko pisanie jakiejś części od 0 i używanie API wystawionego przez inne systemy.
W tym przypadku to to jest standardowe pisanie kodu.
To zależy.
Ale z jakim kodem dokładnie? Jaki zakres obowiązków?
Wg pewnych definicji, Legacy code to kod nie pokryty testami. Wg innych wszystko co napisaliśmy przed tygodniem... ;-)
Kod może mieć 5 lat, być otestowany i nawet średnio-dobrej jakości, przy którym przyjemnie się go pracuje i ciągle rozwija.
A może mieć 2 lata, być totalnym spagetti, bez testów i polegać tylko na utrzymaniu.
Może mieć 15 lat i być spagetti.
Może mieć 10 lat i mieć testy, być w starych i nieciekawych technologiach i być zdecydowanie poniżej średniej. Do tego może być mieszanką utrzymania i rozwoju.
Może mieć rok, być ładnie napisany, ale przyszły takie deadliny że teraz się pisze bez testów bo inaczej klient upadnie i nie będzie w ogóle biznesu. Do tego połowa ludzi z wiedzą odeszła z zespołu do innego projektu. To legacy jak ma rok, czy jeszcze nie?
To tylko przykłady, każdy wymyślony na poczekaniu, każdy inny. Można sobie wyobrazić ich znacznie więcej. Jak czytam Legacy code, dobry kod, zły kod... chciałbym wiedzieć co autor ma na myśli. Bo moje wyobrażenie o tych rzeczach może być zupełnie inne niż drugiej osoby. Zależy przy jakich projektach pracowaliśmy jakie mamy doświadczenia. W tym wątku tak samo, odpowiedź brzmi:
To zależy. Jaki dokładnie kod, jaki zakres obowiązków (realnie, nie na papierze), z kim współpraca, jakie terminy, jak wygląda cały proces (code review, integracja, wdrożenia...).
Zastał kod i praca przy nim jak każda, ma plusy i minusy. Wiele zależy od szczegółów.
Dzięki wszystkim za opinie do tej pory :)
Na tym etapie 'niezdecydowania' wiem tylko tyle, że - Cobol, głęboki 'system bankowy' odpowiadający za różne operacje finansowe (idę po popcorn :D ) rozwijany na bieżąco i system istniejący już od xx lat. Resztę dowiem się zapewne jeśli wybiorę się na ewentualną rozmowę ;)
Cenne wasze opinie i biorę je pod uwagę. Idea brzmi fajnie - kręci mnie robienie czegoś niszowego, a samo spróbowanie czegoś zupełnie innego również.
Żeby ostudzić trochę Twój zapał to muszę wspomnieć, że Cobol to raczej mało przyjazny język i ludzie na początku bardzo szybko uciekają od niego(pomimo wizji dobrej kasy w przyszłości).
na pewno nie zgodzę się że zrobić system od nowa to pryszcz, a utrzymać to ciężko. No chyba że nie zależy nam na jakości. Widziałem już systemy nówki sztuki,
jeszcze nie wdrożone na produkcję, a już było widać że utrzymywać to to będzie problem, a widziałem też kilkuletnie które były naprawdę w świetnym stanie.
To zależy to od ogarnięcia/doświadczenia/kumatości programistów (oraz rzeczy pobocznych typu zarządzanie projektem). Źli programiści i kiepsko zarządzany projekt i nówka sztuka w jakimś cool frameworku będzie nie do użycia. A potem będzie się to kiepsko utrzymywać.
Jednak myślę, że doświadczenie danego programisty może wzrosnąć w trakcie utrzymywania aplikacji. Na początku jeśli ktoś podchodzi do nieznanego wcześniej problemu to często napisze coś słabego, bo nie będzie znał ani specyfiki problemu, ani technologii, nie będzie znał przypadków krańcowych, jakie mogą wystąpić, nie będzie umiał przewidzieć wymagań biznesowych jakie się pojawią itp.
Z drugiej strony wraz z obcowaniem z pewną dziedziną problemów, taki człowiek staje się bardziej kumaty, bo wie, co źle zrobił, wie jak coś zrobić dobrze.
Tylko, że często nie dochodzi do tego nawet, bo może być tak, że osoby mało doświadczone zaczynają pisać, a potem odchodzą z projektu, nie czyszcząc swoich brudów. I potem przychodzą nowe osoby, również mało doświadczone i muszą się zmagać nie dość, że z własnym brakiem doświadczenia, to i z kodem zastanym (który może być jakimś spaghetti). Potem te osoby znowu po jakimś czasie odchodzą i wchodzą kolejne osoby i tak dalej. Projekt jest cały czas rozwijany przez kolejnych noobów.
Ale to tylko jeden ze scenariuszy. Może się tak zdarzyć że osoby które rozwijały projekt na początku zostaną w projekcie. To jest lepsze, bo takie osoby mogą potem przynajmniej posprzątać swój burdel w kodzie, i jakoś doprowadzić projekt do poziomu utrzymywalności... (gorzej jak nowa osoba wchodzi do projektu, bo jeśli wchodzi ktoś nowy, to startuje z poziomu wiedzy zero).
somekind napisał(a):
margor90 napisał(a):
Wydaje mi się, że też rotacja kadrowa i zmiana ludzi, którzy utrzymują (ucieczka do innych firm, nie działów)
A czemu ludzie uciekają? Bo projekt to jakieś koszmarne spaghetti big ball of mud.
A czemu tak jest? Bo sami go tak napisali.
W efekcie ludzie wiecznie uciekają przed swoimi dziełami.i utrata wiedzy jest przyczyną degradacji systemów.
Żeby coś stracić trzeba to najpierw mieć.
Często ludzie zrzucają winę na... biznes, ale myślę, że rzadko jest w tym prawda. To my jesteśmy odpowiedzialni za projekt pod względem technicznym itp.
A biznes do wielu rzeczy można przekonać podając argumenty oraz plan, który da się wykonać w skończonym czasie.