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.