Projekt utrzymaniowy a nauka

Cześć,

Do tej pory robiłem w czasie studiów małe aplikacje w celu nauki. Wykorzystywałem w projektach Spring, Hibernate oraz Angulara.
Celowałem w pracę jako fullstack.
Dostałem prace jako junior w jednej z dużych korpo w Krakowie. Przydzielili mnie do projektu, który był rozwijany od 3/4 lat i jest ukończony w 90%, potem ma być tylko utrzymywany.
Technologie to głównie Java EE oraz dużo Dockera, Kubernetes, itd.

Zastanawiam się, czy taki projekt pozwoli mi rozwinąć się równie mocno, co jakiś nowy pisany od zera.
Do tej pory wszystko, co robiłem to były projekty typowo rozwojowe, pisałem coś całkowicie sam.
Teraz w wakacje jak miałem sporo czasu na naukę, to jak pisałem jakieś małe aplikacje od zera i konsultowałem je ze starszymi kolegami, to czułem że mój przyrost wiedzy był ogromny.

Jakoś projekt utrzymaniowy kojarzy mi się z naprawianiem błędów, a nie pisaniem nowego kodu. Ale nie mam doświadczenia, trudno mi ocenić, może się mylę. Co wy sądzicie?

Praca utrzymaniowa konieczne doświadczenie, żeby zaznać czym się kończy pisanie kodu na pałę. xD No chyba, że to dobry kod, wtedy będzie nauka przez przykład pozytywny.

Mówisz że 90%, to dalej zostaje ci 10% w których możesz uczestniczyć. ;)

gaily napisał(a):

Mówisz że 90%, to dalej zostaje ci 10% w których możesz uczestniczyć. ;)

Tak. To jest OK. Tylko boję się, co potem będzie.
Jakie jest wasze doświadczenie? Jest ktoś w projekcie typowo utrzymaniowym?

Z technicznego punktu widzenia utrzymywanie jest dobrą lekcją dla świeżaków, ponieważ masz na tacy podaną wieloletnią pracę zrealizowaną w oparcu o różne technologie, techniki, i przez różnych programistów. To kopalnia wiedzy, ale i też zbiór wskazówek, opowieści o tym jak NIE pisać oprogramowania. Po prostu naucz się gita i obserwuj zmiany jakie w czasie były wprowadzane w plikach, śledź zmiany różnych programistów (nawet tych, których już nie ma w zespole Ci często są lepsi niż kadra jaką spotkasz) i przede wszystkim poznaj potwora nad którym pracujesz :)

Poza tym warto w porę się obudzić. Domyślam się, że Twoje prywatne projekty, chociaż były fajne to poza Tobą nikogo niestety nie uszczęśliwiały. Teraz masz projekt firmowy, być może to jest dla Ciebie szok jakościowy, być może jest nudny, ale ale jakby nie patrzeć ten projekt powinien być dla Ciebie przykładem jak robić kasę. Jeśli chcesz zarabiać jak dev 15k lub więcej to musisz wiedzieć skąd bierze się kasa. Warto poznać firmę, jej procesy i branżę w jakiej się ona obraca. Warto zrozumieć jej specyfikę, jej problemy ponieważ taka wiedza w połączeniu z technicznym skillem to furtka do: wprowadzania najpoważniejszych zmian w projekcie, pracy w lepszych firmach, podstawa do tworzenia opłacalnych projektów.

Jest taka książka jak "My Job Went to India 52 Ways to Save Your Job" i ona przedstawia, że bycie klepaczem to ta zła opcja.

PS, Ja nie lubię projektów z utrzymywaniem, bo wtedy wieje nudą. Na pokładzie wtedy pozostają słabi programiści, którzy nie mogą pozwolić sobie na zmiany albo tacy co dopiero zaczynają swoją przygodę. W dłuższej perspektywie IMO szkoda życia.

LeJava napisał(a):

Tak. To jest OK. Tylko boję się, co potem będzie.
Jakie jest wasze doświadczenie? Jest ktoś w projekcie typowo utrzymaniowym?

Ja na początku kariery trafiłem do legacy produktu i bardzo dużo zależy od samego produktu. W moim przypadku takiego bardzo legacy z 20 letnimi zaniedbaniami. Powiem, że nauczyłem się przy tym bardzo dużo. Czułem się trochę jak taki saper po środku zaminowanego pola. W życiu bym nie pomyślał, że ktoś mógłby wpaść na pomysł, żeby pod nazwą "setDisabled" ukryć wywołania kilkunastu innych metod (a do tego mieszały jeszcze refleksje zmieniające "coś" w silniku aplikacji), w tym jakieś customowe synchronizowanie wątków, które potrafiły stworzyć pięknego deadlocka i nagle przestawało działać 70% kontrolek w produkcie :D. Nie mówiąc już, że refaktor klasy mającej 6000 linijek też jest dosyć ciekawym zajęciem. W sumie to był chyba czas, w którym napisałem najwięcej kodu w mojej karierze, najwięcej przeklinałem i najwięcej siedziałem w debugerze. W moim przypadku też było dosyć prosto wejść w taki projekt (pomijając wiedzę domenową), bo frameworków było tam niewiele, abstrakcja praktycznie nie istniała, więc przydawała się znajomość czystej Javy.

Ale istnieją też stare utrzymaniowe produkty, w których nie ma zbyt wiele do roboty, bo były porządnie napisane. Wtedy może się okazać, że rozwój będzie stał (chociaż na samym początku nawet taki projekt może sporo dać zanim rozwój się zatrzyma).

Praca przy utrzymaniówce prędzej czy później się pojawia. Chyba, że jesteś jednym z wielu niebieskich ptaków polskiego IT, które zmieniają pracę od razu jak pojawia się etap utrzymania kodu który pisali - bo przeraża ich wizja pracy z własnym potworkiem, którego stworzyli. Czyli są świadomi jaki szajs wyprodukowali.

IMHO wielce wskazane jest by pojawiła się dość wcześnie - jeśli masz za sobą już doświadczenie w klepaniu własnych aplikacji - nawet jeśli nie były zabójczo wielkie.

• Uczy nawigacji w kodzie - taka gimnastyka mózgownicy - tworzy nowe połączenia między neuronami i nie daje się im nudzić. Zwłaszcza ze co projekt to inne rozwiązania projektowe i budowa samej struktury.
• Uczy lokalizowania błędów - bywa że przy pomocy skakania po rewizjach na gicie. Git bisect FTW.
• Uczy niuansów danego języka w praktyce - niuansów którym normalnie nie poświęca się zbyt dużo czasu do momentu aż zaczną powodować problemy. Zwykle poznajesz ich wiele w jednym projekcie dzięki temu.
• Może podwyższać samoocenę jeśli pracujesz z naprawdę kiepskim kodem, który jest wdrożony komercyjnie od lat - a ty byś nawet po pijaku nie pisał w ten sposób.
• Nie musisz się zbyt często wysilać twórczo i wiele błędów wykrywasz "na automacie" - w danych technologiach i językach zbiór problemów zwykle jest ograniczony i dość typowy w obrębie jednego projektu - nawet jeśli idzie w miliony linii kodu (piszę z doświadczenia).

Utrzymaniówka w doświadczeniu to też dobry argument przy ewentualnej zmianie ścieżki z programisty na zadania około administratorskie, czy czysto projektowania oprogramowania. Jakbym nie spojrzał to widzę całą masę zalet przynajmniej liźnięcia tematu.

Dlatego też te słynne kontrybucje na githubie są tak cenione. Bo pokazują, że jesteś w stanie pracować z cudzym kodem. Bo wiele poważniejszych projektów powstaje grupowo jakby nie patrzeć. Do wielu też dołącza się w trakcie ich powstawania daleko po starcie i trzeba pracować z tym co już jest i rozwijać to co już jest.

Spędziłem 6 lat w trzech różnych firmach przy projektach utrzymaniowych i raczej nie polecam takiej ścieżki kariery. Dużo na pewno zależy od projektu, natomiast ja bardzo żałuje, że nie spędziłem pierwszych lat w typowym developmencie nowego produktu. Czuję teraz dość spore braki i aplikując na stanowiska seniorskie idę z przekonaniem, że tak na prawdę nie umiem programować. Wiem jak dokleić funkcjonalność, aby nie popsuć systemu, na co zwrócić uwagę poprawiając błędy, gdzie ich szukać. Umiem ocenić konsekwencję rozwiązania i wskazać gdzie za kilka miesięcy lub lat pojawią się problemy z architekturą, natomiast umiejętności programowania i prowadzenia projektu 'od początku do końca' są u mnie bardziej na poziomie juniora niż seniora. Warto uważać, aby nie zostać juniorem z wieloletnim doświadczeniem, bo praca w utrzymaniu nie sprzyja rozwojowi, a na pewnym etapie życia często coraz mniej czasu można poświęcić na rozwój po pracy :P

No to podaj mi przykłady wielkich projektów, które byś budował jako junior sam albo w niewielkich zespołach w jakiejkolwiek firmie od początku do końca. Chyba, że masz na myśli firmy gdzie junior robi też za kilka osób z działki inżynierów oprogramowania. Takie coś to w januszsoftach. W normalnych firmach juniora dopuszczają najwyżej do klepania fragmentów wedle specyfikacji. Jak trzeba coś więcej to dostaje "nadzorcę". Już nie wspominając o totalnym często braku rozumienia konsekwencji długoterminowych tego co klepią. Serio myślisz, że nie podołałbyś klepaniu CRUDów czy implementacji czegoś ze specyfikacji?

Marne szanse abyś na projektach utrzymaniowych podciągnął skilla. Kod powstał pół dekady, dekadę czy nawet dwie dekady temu i tworzono go na miarę tamtych realiów. Utrzymanie na ogół powierza się kontraktorniom, a priorytetem jest, że ma działać.

Nawet jak biznes chce wycofać starą aplikację oraz zastąpić ją nową to w projekcie jest armagedon i branie udział w takim przedsięwzięciu jest ryzykowne w każdym obszarze.

Według mnie jeżeli jest to pierwsza praca to nie ma większego znaczenia. Z mojego otoczenia chyba wszyscy w przeciągu roku zmienili pracę lub projekt + sporo wyższa pensja :).
Jak nie pracowałeś nigdy w zespole to nieważne czy będziesz wykonywał nowatorskie pomysły, utrzymywał 10 letnie chimery czy klepał te legendarne crudy. Wszędzie jest kupa nauki, grunt to odejść w odpowiednim momencie żeby dalej się rozwijać.

@LeJava: op może wrzuci update czy się czegoś nauczył? To już dwa lata minęły ;)