Moje wątpliwości po kilku miesiącach pracy

0

Cześć. Od kilku msc. pracuje w mojej pierwszej "normalnej" pracy jako programista, wcześniej tylko korki, projekty na zaliczenie, dłubanie samemu hobbystycznie, teraz praca "w zespole" na etacie, środowisko produkcyjne. Poznań, nie jest to polskie top3, ale też nie informatyczna pustynia. Webówka, frontend, kasa na start akurat mieści się w moich oczekiwaniach. Firma mała, 9 programistów na dwa projekty, podział mniej więcej po równo na projekt i połowa front połowa back, w przypadkach jakiś poważniejszych problemów wspólna burza mózgów. Nie nazwałbym Januszsoftem, atmosfera dość dobra bez patologii organizacyjnych, ale w sumie nie mam porównania do innych firm. Pierwsze tygodnie ok, ale to normalne że odczuwałem pewnego rodzaju ekscytacje, teraz zderzenie z rzeczywistością. Projekt 5 letni, wcześniej utrzymywany przez inną (inne?) firmy, od 3 lat przez moją aktualną, były pracownik który mocno zajmował się tym projektem zmienił trochę podział na foldery po swojemu, odbiega to znacznie od dokumentacji dostarczanej od producenta, własnej dokumentacji nie mamy. Nie ma przyjętych konwencji, część osób z powodzeniem stosuje dobre techniki pisania kodu, czytelne długie nazwy obiektów ułatwiające ich zrozumienie, ale też często napotykam na stare nic nie mówiące zbitki znaków w kilkatysięcy linijkowym pliku, a muszę w tym grzebać. Chcę coś zmienić, a nazwy poprzesłaniane, gęsto ponadpisywane importanty w cssach. Po stronie backendu chyba w miarę porządek, php + redis + mysql. Na froncie biegunka technologii, wersja javascript gdzieś tak z 2009, dużo nieużywanych już bibliotek, nie chodzi o "fajne" rzeczy jak react, angular, ember. Większość czysty js bardzo ewentualnie jquery. Z wieloma rzeczami szybko mogą poradzić sobie tylko osoby, który dawno dawno jakieś funkcjonalności pisały, a inne osoby choćby i z 3 letnim doświadczeniem w tym projekcie szukają tak jak taki świerzak jak ja na "chybił trafił" i długo nie znajdują rozwiązania, a że niektórych już nie ma to liczba wtf-aków niebezpiecznie wzrasta. Czasami po godzinie myślenia znajduję, że rok temu ktoś w jakiejś głębokiej templatce zamiast w php $this->(...) wpisał coś z bomby. Normalka, błędy się zdarzają, ale ich natężenie naprawdę mnie zaczyna przygniatać, chociaż z zadaniami się myślę wyrabiam ok. Wiem, że frontend to mnogość technologii, praca programisty polega na rozwiązywaniu problemów, błędy są nieuniknione... ale jednak mam coraz większe wątpliwości. Jasne, że to ja podejmę decyzję o dalszej karierze, niedługo porozmawiam z ludźmi z firmy, ale jednocześnie korzystając z forum zapytam czy to mogą być poważne objawy świadczące o tym, że taka praca w dłuższej perspektywie nie będzie dla mnie rozwijająca?

2

Ja na Twoim miejscu zacząłbym się już rozglądać za inną pracą - po kilku miesiącach powinieneś znaleźć coś lepszego - szukaj nowych projektów i wybadaj czy stosują:

  • ES6!,
  • HTML5, CSS3 (także animacje CSS),
  • Babel / Webpack / Browserify / Gulp,
  • testy automatyczne (jednostkowe, integracyjne, e2e),
  • BEM lub coś podobnego,
  • Sass (ewentualnie Less),
  • npm (ostatecznie Bower),
  • jakiś nowoczesny framework: React / Angular2 / Vue (cokolwiek poza jQuery),
  • biblioteki typu Lodash / Ramda / ImmutableJS,
  • ESLint / JSHint / JSLint i ścisłe konwencje (np. https://github.com/airbnb/javascript ),
  • JSDoc,
  • robią zawsze code review,
  • jak mi się coś przypomni to dopiszę ;)

Ogólnie to taka "szkoła" nie pójdzie na marne - znasz już wartość dobrego kodu i pewnie nauczyłeś się debugować i korzystać z DevTools, ale nie ma co tego dalej ciągnąć - roboty na froncie mnóstwo, można przebierać.

3
Mały Lew napisał(a):

Nie nazwałbym Januszsoftem

zwykle to właśnie januszsofty biorą takie zlecenia miny z babraniem w goownokodzie których nikt inny nie chce

widzę to codziennie w skali mikro typu "zrób z wordpressa drugą interię za niedrogo-pilne"

1

Możesz spróbować jakoś dogadać się z szefostwem, aby takie projekty przepisywać od nowa.
Nie jest to żart, na takim działaniu traci się znacznie mniej czasu. U mnie w firmie jak przejmujemy projekt z zewnątrz, po krótkim zebraniu i sprawdzeniu dokładnie kodu decydujemy czy przepisujemy czy się męczymy. Na oko w 90% przypadków, przepisujemy projekt od nowa.
Nie wiem skąd bierze się tak niskiej jakości kod na rynku, ale tak od ~2 lat pracy sytuacja się nie poprawia. Wręcz przeciwnie.

0

Dzięki, więcej jutro napiszę. Domena jest prestiżowa, klient zagraniczny, a my jesteśmy ostatnim podwykonawcą. Nie jest tak, że to aż takie zupełne starocie, jest SASS/CSS3, Gulp (przy aktualnych zadaniach ten akurat dla mnie bez różnicy), pamiętam lodash, ale uciekł mi z pamięci gdzieś w codziennym gąszczu innych. Patrząc z jakiejś tam perspektywy teraz myślę tak: są oczywiście plusy, ale jednak minusy przeważają. O przepisaniu od nowa na razie nie ma mowy, planowane jest za pół roku, ale dużo zależy od strony biznesowej jak będzie układała się dalsza współpraca z głównym klientem no i za pół roku mogę być zupełnie gdzie indziej. Na razie mamy testy "bardzo manualne", automatyzacja też ma być za pół roku wraz z innymi rzeczami, ale może to tylko takie gadanie by zatrzymać mających wątpliwości. Dzięki za odpowiedzi. Bezpiecznie teraz szukam pracy w technologiach co mnie interesują (Python, więcej dobrego JS, ew coś innego).

1

To jest poniekąd problem studenta. Student uczy się nowych rzeczy, poznaje etc. W pracy oczekuje tego samego, a tutaj zonk. Utrzymanie projektu, jego serwis lub rozwój pod dyktando klienta. W końcu jak napisane zostało coś te 5 lat temu to ktoś musi to utrzymywać. Ciesz się, że nie trafiłeś na kod który nie jest starszy od Ciebie ;) Nie mówię, że to złe u Ciebie. Sam też mam takie podejście, ale właśnie dlatego pracuję od początku przy rozwoju i to technologii, a nie aplikacji (rozwijanie końcowych produktów tez mnie nudzi). Może zamiast w utrzymaniu poszukaj jakiejś firmy z działem RnD.

0

były pracownik który mocno zajmował się tym projektem zmienił trochę podział na foldery po swojemu, odbiega to znacznie od dokumentacji dostarczanej od producenta, własnej dokumentacji nie mamy. Nie ma przyjętych konwencji, (...) często napotykam na stare nic nie mówiące zbitki znaków w kilkatysięcy linijkowym pliku, a muszę w tym grzebać. Chcę coś zmienić, a nazwy poprzesłaniane, gęsto ponadpisywane importanty w cssach. (...) Na froncie biegunka technologii, wersja javascript gdzieś tak z 2009, dużo nieużywanych już bibliotek, nie chodzi o "fajne" rzeczy jak react, angular, ember. Większość czysty js bardzo ewentualnie jquery. Z wieloma rzeczami szybko mogą poradzić sobie tylko osoby, który dawno dawno jakieś funkcjonalności pisały, a inne osoby choćby i z 3 letnim doświadczeniem w tym projekcie szukają tak jak taki świerzak jak ja na "chybił trafił" i długo nie znajdują rozwiązania, a że niektórych już nie ma to liczba wtf-aków niebezpiecznie wzrasta.

Jeśli macie budżet czasowy to lepiej to przepisać, a starą aplikację traktować jako nędznej jakości prototyp, który jednak pozwala na zobaczenie tego, jak aplikacja powinna wyglądać i jak się zachowywać. A sam kod może być wskazówką na to, w jaki sposób można rozwiązać pewne problemy techniczne (albo też: w jaki
sposób ich nie rozwiązywać, bo to też ważne).

Z drugiej strony przepisywanie to jest duży kawałek chleba, który może zająć dużo czasu (tylko wszystko zależy ile macie się z tym męczyć - kurczę, jak macie zrobić w dwa tygodnie jakieś poprawki na szybko, to nie brałbym się za przepisywanie, bo nie warto, ale jak macie pół roku czy rok, to jak najbardziej można a nawet trzeba przepisać, bo przepisanie się lepiej opłaci biznesowo niż utrzymanie takiej kobyły, gdzie inne osoby choćby i z 3 letnim doświadczeniem w tym projekcie szukają tak jak taki świerzak jak ja na "chybił trafił" i długo nie znajdują rozwiązania).

Po stronie backendu chyba w miarę porządek,

to dobrze, bo to znaczy, że przy przepisywaniu backend mógłby zostać.

Nie wiem skąd bierze się tak niskiej jakości kod na rynku,

Coraz większy popyt na programistów ---> Programistą zostaje dzisiaj każdy --> i mamy brzydki kod :)

Chociaż nie wszystko jest takie proste i nie całą winę można zwalać na programistów. Czasem brzydki kod bierze się ze złożoności projektu, za którą nie podąża dobre zarządzanie projektem (a złe zarządzanie to np. presja czasowa na robienie ficzerów "na wczoraj" i brak wyznaczenia czasu na projektowanie architektury, na refaktoring, na ulepszenia, na testy, na kod eksploracyjny itp. złe zarządzanie potrafi zabić każdy projekt i zrobić z niego ledwie dychające zombie)

O przepisaniu od nowa na razie nie ma mowy, planowane jest za pół roku,

I tu właśnie mamy jak na dłoni przykład złego zarządzania projektem. Jeśli płacą co najmniej 10 tysięcy to może bym się zastanowił i bym może popracował w takiej firmie przez parę miesięcy, ale za mniej szkoda czasu.

0

Nie martw sie - w nastepnej pracy nie bedziesz mial lepiej :) (btw wiesz ze masz zajebiscie?). Po mimo tych ochow i achow nad jakoscia kodu wiekszosc osob pisze brzydki kod bo... i tu sobie mozesz wpisac tysiac powodow. Zreszta jak ogladniesz swoj ladny kod napisany jakies 6 miesiecy temu to stwierdzisz ze jest brzydki. Z takim rzeczami musisz nauczyc sie pracowac i tyle. Co do tego ze nie ma modnych frameworkow js - znajomosc vanilla js jest znacznie wazniejsza niz znajomosc angurlara, aureli i innych frameworkow.

1 użytkowników online, w tym zalogowanych: 0, gości: 1