Po jakim czasie przestaliście się przejmować tym, jak bardzo chujowy kod jest na produkcji?
Pracuje dopiero pierwszy miesiąc, i za takie gówno które odsyłam mam ochotę samego siebie ukrzyżować
@redve Po czasie jak zmieniłem robotę. Rzeźbienie w gównie na dłuższą metę jest męczące i nie rozwija. Uciekaj jak najszybciej.
@redve po kilku latach staram się raczej naprawiać i nie dokładać się samemu do tego.
Ale to na ile możesz sobie pozwolić albo nawet ile musisz odjebać to kwestia zależna od projektu. Jak pracujesz miesiąc, to wszystko co przepuszcza Twój mentor (? team lead ?) jest dostatecznie dobre. I będzie przez pierwszy ~rok/dwa pracy, bo moim zdaniem nie masz dostatecznego doświadczenia z projektami programistycznymi żeby stwierdzić która "chujowość" będzie dla Was problemem w przyszłości.
@redve działa, to nie ruszaj. A jak nie działa, cóż...
@redve lepiej zmienić robotę/zespół niż się z tym pogodzić. Z doświadczenia w rekrutowaniu wiem, że potem ciężko wbić z powrotem na dobre tory jak już się przyzwyczaisz do pisania i akceptowania gówna na prodzie.
@redve po prostu nie akceptuj i nie pisz gówno kodu na odpierdol, co się daje to rewaloryzując nie zapominając o testach. Gorzej jeśli jakiś baran pisze pliki po 1k linijek kodu, w zależności od języka warto też doda lintery które będą pilnować podstawowych przyjętych zasad.
@redve to zalezy jak szybko chcesz zmienic prace. Ja nie lubie skakac co roku - i tak w moim wieku juz coraz ciezej nauczyc sie nowych rzeczy na perfa, tak wiec przejmuje sie kodem. Inna sprawa tez zawuwazylem, ze kod mniej chujowy wychodzi jak znasz szerszy obraz projektu. Wiesz - jakas funkcje dopisac czy cos tam zalatac to spoko, ale jak wiesz, ze pozniej bedzie trzeba jeszcze wiecej rzeczy dorobic - to raczej staralbym sie nie pchac do repo / na produkcje balaganu
@redve a wiesz dlaczego tak jest? Bo można…. Użytkownik jest się w stanie do wszystkiego przyzwyczaić. Program przestał działać? Zrestartuj…
Błąd na stronie? Odśwież…
Działa wolno? Zmień telefon/laptopa…
No one cares…
Technika poszła do przodu, pamięć jest relatywnie tania. Kod może dużo ważyć i być pisany w językach, które same z siebie są dosyć ciężkie. Ograniczenia sprzętowe nie są już dużym problemem. Brakuje zasobów? Można postawić kolejną instancje EC2…
W większości przypadków nie ma już potrzeby oszczędzania zasobów czy pisania wydajnego kodu.
Z jednej strony znak czasów i dużego poziomu informatyzacji (więc deweloperów ma być dużo, więc i średnia jakość kodu spada). Z drugiej strony jest to przerażajace z perspektywy użytkownika - oprogramowanie samolotów (niedawna afera z Boeingiem 737 MAX), autonomicznych aut….
Bardzo w tej kwestii podoba mi się poniższy artykuł. Daje do myślenia:
@tegie bo:
-
usługi programistów są drogie
-
klientów nie stać na płacenie tyle, ile by powinna kosztowac aplikacja, której by chcieli, więc idą software housu, który zrobi im to taniej (i gorzej)
-
na rynku brakuje midów/seniorów, w związku z czym obecni midzi/seniorzy są zawaleni robotą i często podejmują decyzję o redukcji ilości testów
-
plus często za aplikacje biorą się juniorzy, którzy nie mają odpowiedniego mentoringu, więc ilość bugów się mnoży
-
plus jeszcze to, ze ze wzgledu na łatwość podmiany plików, istnieje pewna tolerancja na chujozę w kodzie. Kiedys jak cos wypusciles, to jak nie dzialalo dobrze, to dupa - juz sprzedałes 1202412 płyt z oprogramowaniem i zepsules sobie reputację. Dzisiaj w kazdej chwili mozesz podmienic pliki i albo pobiora sie automatycznie bez wiedzy usera (web), albo mozna wymusic pobranie łatki i ją zainstalować w kilka sekund
@Flaaj owszem, nie twierdze że powody wynikają tylko z niedbałości i nieudolności.
Poniekąd o braku seniorów wspomniałem (duże zapotrzebowanie na software sprawia, że jakość usług średnio maleje - miałem na myśli właśnie niewystarczającą liczbę seniorów i pisanie kodu przez mniej doświadczonych devów).
Co nie zmienia faktu, że duża cześć sortu jest pisana niedbale. Bo czas programisty jest więcej warty, niż jakość. Bo w świecie clouda mamy teoretycznie nieograniczone skalowanie, a zasoby są relatywnie tanie.
Bo stosowane są języki i frameworki obarczone sporym narzutem i przez to mniej efektywne.
W końcu też dlatego, że duża cześć seniorów robi po godzinach własne fuchy. Żeby nie było, nie mam nic przeciwko. Ale takie zlecenia robi się szybko, często powielając te istniejące „niewydajne” schematy, bez zmóżdżania się nad wydajnością.
Ostatecznie cierpi użytkownik końcowy, który de facto i tak nie ma wyjścia, bo podobny trend jest niestety powszechny.
Jeszcze inny powód - brak znajomosci backendu. Miałem w pracy taki przypadek wiele lat temu. Zewnętrzna firma pisała oprogramowanie, które miało wykonywać specyficzne zadania na backendzie (harware, db, różne OSy, wirtualizacja itd.). Wizualnie było ładnie i działało szybko przy małej skali. Gdy skala wzrosła, program zaczynał dostawać czkawki. Czkawki wystarczającej by produkt nie był użyteczny do celów komercyjnych (rozwiązanie wymagające bardzo małych opóźnień). Wszystko wynikało właśnie z niewystarczającej znajomosci wszystkiego co pod spodem (we współpracy z tą zewnętrzną firmą analizowałem ich kod i algorytmy, było tam bardzo dużo… „oryginalnych”…. rozwiązań
Zaloguj się aby komentować