Wpis z mikrobloga

W dużym korpo trafiłem do zespołu, gdzie jest tyle manualnej roboty, że ja pier****. A pisana aplikacja webowa nawet nie stała obok standardów REST API. (POSTy są GETami etc.)
Jestem programistą i jestem jednocześnie fanem automatyzacji, skryptowania i pisania automatów do rzeczy, które są powtarzalne i zajmują dużo czasu, jak również lubię jak kod jest czysty, czytelny i zgodny ze standardami.
Raz na 2 tygodnie robię manualnie release na wszystkie środowiska, co zajmuje mi cały dzień i gdzie ręcznie muszę wszystko przeklikiwać. Dlaczego manualnie? Bo "nie ma wartości biznesowej, nie ma czasu na poświęcenie czasu na zautomatyzowanie tego przez pipeline'y, trzeba dostarczać nowe funkcjonalności". Zespół ma nastawienie "wezmę taska, będę go robił cały dzień" - chociaż można go opitolić w 20 min. Zespół również niechętny do wprowadzenia tych zmian, bo już się przyzwyczaili do "strefy komfortu". Nie można refactorować endpointów do standardów REST API, bo "nie ma czasu". Migracje baz danych robione są ręcznie na bazie, odpalane manualnie skryptem SQLowym, nie z poziomu kodu, bo "nie da się inaczej" - a jest to niezgodne z security. Mnóstwo zdublowanego kodu, trudnego do utrzymania, brak kompatybilności wstecznej, wersjonowania API. Propozycje moich zmian zostały odebrane tak, jakbym chciał sabotować projekt xD
Jak myślicie, ewakuować się czy jeszcze zmienią zdanie? :D

#it #praca #pracait #programista15k #programista #programowanie
  • 18
  • Odpowiedz
  • Otrzymuj powiadomienia
    o nowych komentarzach

Zespół ma nastawienie "wezmę taska, będę go robił cały dzień" - chociaż można go opitolić w 20 min.


@darkmen2905: I bardzo dobrze. Nie robią tego dla siebie. Mają komfort psychiczny, czas na pierdoły i rzeczy gówno managementowe. Jak coś nie wyjdzie albo się skomplikuje to czas dodatkowo w to wliczony, a taski idą tylko nie tak szybko jak by mogły. Ty patrz lepiej na siebie zamiast psioczyć na innych. Dla
  • Odpowiedz
@darkmen2905: A ktoś ci zabrania wprowadzania zmian w kodzie? Czy przypadkiem nie płacą ci byś te zmiany robił? Mam wrażenie, że wyszedłeś do ludzi, powiedziałeś co trzeba zrobić, pokiwaliście mądrze głowami i każdy wrócił do cs-a xD Bo co innego robi się tam przez resztę dnia po zrobieniu taska na 20 min
  • Odpowiedz
  • 0
@AnonimoweLwiatko: W sumie mam wrażenie, że przez to nastawienie nie rozwinę skrzydeł. Plus ogarniając sobie usprawnienia i automaty oraz standaryzację nowe feature'y mogą być implementowane szybciej a potem i jest możliwość brania kolejnych projektów. No i są potem podstawy do podwyżek. Poza tym my tą apkę też będziemy utrzymywać - jak coś się wysra to nikt nie będzie wiedział jak to ogarnąć, bo każdy też będzie się bał coś zmienić
  • Odpowiedz
  • 0
@TwojHimars: Cóż...PRki sprawdza przynajmniej dwóch członków mojego zespołu. Kiedy wyszedłem z inicjatywą zmian w PRce (usunięcia zdublowanego kodu etc.) to dostałem Rejecty, bo ma być tak jak było. Raczej to było tak, że wyszedłem do Nich, powiedziałem co można zrobić, oni pokręcili głową, że "Nie, to się nie sprawdzi, nie ma czasu, nie ma sensu" i ucinają te pomysły, bo "nie ma czasu, liczą się feature'y".
  • Odpowiedz
@darkmen2905: Im więcej automatyzacji tym mniej pracy dla Ciebie. Z punktu widzenia inżyniera/programisty, rozumiem. Rozumiem też z punktu widzenia gościa, który jest zatrudniony i widzi jak wygląda teraz rynek oraz wie, że w przypadku gdy jest mniej roboty niż zatrudnionych ludzi to lecą głowy. Mega oporne taski możesz sobie na boku sam automatyzować, mieć skrypty od tego ale nie poprawiaj procesu jeśli to zredukuje znacznie pracę i możesz na tym
  • Odpowiedz
@darkmen2905: trochę rak xD Akurat robienie taska cały dzień to rozumiem, bo jak im tak dobrze to po co na siłę chcesz im narzucać, ale jak tobie jest z tym źle i masz ochotę sobie #!$%@?ć refactor to #!$%@? im do tego...

...ale z drugiej strony weź tak powiedz może ile ty masz doświadczenia? Bo takich juniorów co dołączyli i chcą zrobić wszystko lepiej, bo oni przecież wiedzą jak powinno
  • Odpowiedz
Plus ogarniając sobie usprawnienia i automaty oraz standaryzację nowe feature'y mogą być implementowane szybciej a potem i jest możliwość brania kolejnych projektów


@darkmen2905: Tak, ale z biznesowego punktu widzenia mozesz nie miec racji.

Dajmy na to ze dadza Ci wolna renke w wprowadzeniu automatyzacji i jakiej marzysz. Na ile to wyceniasz?
Czy dla zaoszczedzenie 2 dni w miesiacu, czyli 24 w roku warto isc w jakis system ktorego implementacja i utrzymanie, a takze szkolenia zajma wiecej niz 24 dni w roku? Gdzie nie wiadomo czy ta inwestycja sie wogole zwroci w skali projektow jaki
  • Odpowiedz
@darkmen2905: Z tego co wymieniłeś to IMO 2 rzeczy są sensowne do zwrócenia uwagi:

* obecnie ręczny deploy na wszystkie środowiska zamiast automatycznego - tutaj nie ma wątpliwości, że zautomatyzowanie i gotowe pipeliny dostarczyłyby szybsze i powtarzalne deploymenty. Inna rzecz to sprawdzenie, czy deploy się udał - sam healthcheck może nie starczyć, może faktycznie warto przeklikać UI pod kątem smoke testów

* migracje na bazie - nie macie żadnego Flyway
  • Odpowiedz
Co jest złego w manualnym releasie na proda jeśli wszystko jest udokumentowane? Manualne rozumiem przez kliknięcie "approve" i utworzenie tagu/release brancha xd
  • Odpowiedz
Jak myślicie, ewakuować się czy jeszcze zmienią zdanie? :D


@darkmen2905: zrób jak chcesz. Z tego typu postów nigdy nie da się wywróżyć, czy problem jest z tobą czy zespołem
  • Odpowiedz
  • 0
@WyjmijKija: Brałem udział w 5 dużych projektach. Mam 5 lat doświadczenia. Chcę po prostu wdrażać to, co bardzo dobrze się sprawdzało w poprzednich projektach. Rozwinięte to było do tego stopnia, że mikroserwis, z którego korzysta 500 osób został zaimplementowany w mniej niż 3 tygodnie, bo stworzyliśmy własny silnik z tymi standardami i automatami o których wspomniałem.
  • Odpowiedz
  • 1
@AnonimoweLwiatko: Zgadza się, mniej pracy dla mnie, ale więcej czasu na skupienie się na innych rzeczach, innych projektach. Automatyzacja też ma na celu zredukowanie błędu ludzkiego, który bardzo łatwo popełnić. Ale rozumiem Twój punkt widzenia.
  • Odpowiedz
  • 0
@JayCube: Biorąc pod uwagę kwestię deadline'ów i fakt jednorazowej akcji myślę, że oszczędność czasu jest tutaj na plus. W teorii firma płaci inżynierowi za 4 godziny przeprowadzenia release'u (bez automatu) zamiast 30 min na release i 3,5 godziny na implementację kolejnej funkcjonalności biznesowej. Myślę, że w aspekcie długofalowym to się zwraca.
  • Odpowiedz
@darkmen2905: przekonaj ich, że chcesz to robić na boku, na spokojnie. Ja bym był otwarty z tym co widzę i chcę robić na jakimś spotkaniu 1on1 z leadem. Powiedziałbym, że bądźmy szczerzy, ale większość tych zadań jest do zrobienia mega szybko i rozumiesz, że taki mają tryb pracy i nie chcesz zmieniać przyzwyczajeń, ale bardzo chętnie zrobisz coś na boku. Jak nie chcą się dać przekonać to zaproponuj, że zrobisz
  • Odpowiedz