Jakość czy jakoś a przyszłość w firmie

Jakiś czas temu zacząłem kontrakt w firmie która rozwija swój produkt z branży hotelarskiej. To jaka to branża to może mniej istotne.
Ale czy spotkaliście się z sektą Agile?

Ogólnie rzecz biorąc nigdy nie miałem problemu z Agilem, Scrumem i tymi bzdetami, ale tutaj podniesiono poprzeczkę do ekstremum.
Product Ownerzy w zasadzie nie do końca rozumiem po co są, gadają z klientami i przekazują feedback - za produkt odpowiadają developerzy!
Mają nawet każdy piątek aby generować pomysły zbawienia naszego systemu, znalezienia brakującego ogniwa czy wynalezienia kamienia filozoficznego. Efekt nie trudno przewidzieć, tracą czas na implementację rzeczy po prostu z d**y(w 90% przypadków), ludzie którzy (jak ja) dopiero dołączyli i nie kumają domeny też mają generować pomysły które są jeszcze bardziej pokraczne. Szukaj business value, aport! No już! C'mon! Bądź data-driven i generuj fajne raporty. Grunt żeby były kolorowe, to że mało prawdziwe to nie ważne.

Dodatkowo pod wpływem charyzmatycznego "architekta" logika znajduje się nie gdzie indziej jak w kontrolerach, a w sumie najlepiej w kontrolerze, dzięki czemu strzelanie do bazy i mieszanie zwrotki z JSONem nigdy nie było tak proste. Bo mikroserwis trzeba mieć możliwość przepisać w tydzień, z czego większość ma po 5 lat, woła o pomstę i nigdy rewrita nie zobaczy bo jest tak napisana że już nikt nie wie za co właściwie odpowiada. Chyba nie trzeba mówić że model praktycznie nie istnieje, encje bazodanowe są anemiczne. W każdym razie ważne że na koniec jest OK 200. Chyba jedyny pozytyw jaki mogę wymienić to to że pokrycie testami jest niezłe.

Zacząłem się zastanawiać czy to ja tracę kontakt z rzeczywistością czy tak wygląda wymarzone miejsce do pracy, bo rozmawiając z ludźmi którzy tam pracują nie słyszę żadnego kompletnie narzekania. Everything is excellent and brilliant, and I can't wait to figure out new features! Mają taki charakterystyczny dla narkomanów i sekciarzy wyraz twarzy z którego nie znika grymas uśmiechu i chęć sprostania kolejnym przeciwnościom losu. I na prawdę nie przesadzam mówiąc że nie są w stanie wykrzesać odrobiny cynizmu wobec swojego dzieła i podejścia do sprawy.

Spróbowałem pewnego razu dodać warstwę, serwis który coś tam przemieli, przekieruje i zwróci - normalka. No jednak nie było to spójne z resztą kodu i przekleiłem tę logikę z powrotem w kontroler. Ogólnie dużo by mówić z jakim trudem wciskam gdzieś strategie żeby kod nie wyglądał jak drzewko bożonarodzeniowe.

Czy tak wygląda pragmatyzm? Czy pragmatyzm boi się rozdzielania odczytów od zapisów? Czy może ja jestem obmierzłym teoretykiem który by wciskał wzorce projektowe i bezsensownie budował abstrakcje. Bo abstrakcje są bez sensu, tak jak podział projektu na moduły.

Powiedzcie proszę że źle trafiłem i wystarczy poszukać nowej firmy, pragnę akceptacji.

Pozdrawiam z kąta pokoju patrząc na półkę z książkami które przeczytałem zastanawiając się czy zapomnieć wszystko czego się nauczyłem przez ostatnie 7 lat i zastanawiając się nad założeniem hodowli rybek.

Jedno pytanie, ile ci płacą? Czy wystarczy aby otrzeć łzy, a wszędzie indziej płacą mniej?

Jeśli odpowiedź to "nie" to:

Uciekaj stamtąd XD

orchowskia napisał(a):

Ogólnie rzecz biorąc nigdy nie miałem problemu z Agilem, Scrumem i tymi bzdetami, ale tutaj podniesiono poprzeczkę do ekstremum.
Mają nawet każdy piątek aby generować pomysły zbawienia naszego systemu,

Jak w piątek to pewnie przy piwku? A potem wygląda to, jak wygląda.

Dodatkowo pod wpływem charyzmatycznego "architekta" logika znajduje się nie gdzie indziej jak w kontrolerach, a w sumie najlepiej w kontrolerze,

obstawiam, że jakaś Java?

Zacząłem się zastanawiać czy to ja tracę kontakt z rzeczywistością czy tak wygląda wymarzone miejsce do pracy, bo rozmawiając z ludźmi którzy tam pracują nie słyszę żadnego kompletnie narzekania. Everything is excellent and brilliant, and I can't wait to figure out new features!

Mają taki charakterystyczny dla narkomanów i sekciarzy wyraz twarzy z którego nie znika grymas uśmiechu i chęć sprostania kolejnym przeciwnościom losu. I na prawdę nie przesadzam mówiąc że nie są w stanie wykrzesać odrobiny cynizmu wobec swojego dzieła i podejścia do sprawy.

Ludzie, którzy są w bagnie przez dłuższy czas już potem nie ogarniają, że są w bagnie. Przyzwyczaili się "bo tak się zawsze robiło" albo "komu to przeszkadza" czy "przez x lat pracuję w tym i nigdy nie miałem z tym problemów".

O ile są to ludzie doświadczeni. Bo niedoświadczeni też się jarają ze wszystkiego, ale są jeszcze naiwni, nieobeznani, nastawieni na naukę, a nie krytykę, więc się jarają, że będą robić nowe ficzery, bo to dla nich jakiś rozwój.

Powiedzcie proszę że źle trafiłem

Źle trafiłeś, ale to jest loteria. W kolejnej firmie możesz trafić lepiej, a możesz jeszcze gorzej (tutaj przynajmniej pokrycie testami było niezłe, z tego co piszesz). Można co najwyżej uważnie się przysłuchiwać tego, co mówią na rozmowach i zadawać im pytania zanim się zatrudnisz, żeby wysondować mocniej temat.

wystarczy poszukać nowej firmy, pragnę akceptacji.

No jeśli masz już jakieś doświadczenie, to ja bym się zwijał stamtąd.

Chodzi mi o to że zdaje się jakbym tylko ja widział problem. Nie wiem czy to jakaś chora ambicja, czy inne zapłodnienie intelektualne. Podnoszenie sprawy na retro nic nie dało, po prostu nie rozumiem tych ludzi. Zarówno Polacy jak i inne narodowości. Firma UK.

Może nie jestem w stanie się przebić przez tę barierę mentalną zachodu, bo w sumie pierwszy raz w takiej mocno tamtejszej firmie kulturowo

orchowskia napisał(a):

Chodzi mi o to że zdaje się jakbym tylko ja widział problem. Nie wiem czy to jakaś chora ambicja, czy inne zapłodnienie intelektualne. Podnoszenie sprawy na retro nic nie dało, po prostu nie rozumiem tych ludzi. Zarówno Polacy jak i inne narodowości.

Większość programistów nie ma albo odpowiedniej wiedzy/doświadczenia, albo odpowiedniej inteligencji czy postawy.

Jak ktoś nie ma wiedzy/doświadczenia, to jest juniorem i może jeszcze coś z niego będzie.

Jak ktoś ma mnóstwo doświadczenia, a dalej brak mu wiedzy i rozsądku, to znaczy, że się nie nadaje na programistę, jednak oszukał system i udaje wielkiego programistę, a g**no umie w rzeczywistości. I takie osoby się wożą i są często doceniani przez pracodawców bo znają projekt, mimo że z umiejętnościami u nich słabiutko.

Problem w tym, że taka postawa "g**no umiem, g**no mnie to obchodzi, ale udaję dobrego" jest zaraźliwa i potem ludzie wchodzą i się demoralizują i też zaczynają mieć na wszystko wywalone czy powielać już istniejące chu*owe praktyki. Trochę jakbyś wpuścił jednego zombiaka do projektu, to po chwili by gryzł wszystkich i każdy byłby zombiakiem. Oni już nawet nie wiedzą, że robią źle.

Więc jeśli chcesz mieć normalność, to ja już bym zaczął rozsyłać CV i rozglądał się za nową pracą. Bo w tej firmie już jest jak jest.

@orchowskia:

Może nie jestem w stanie się przebić przez tę barierę mentalną zachodu, bo w sumie pierwszy raz w takiej mocno tamtejszej firmie kulturowo

Znam te klimaty. To jest normalne w UK. Wszystko jest „brilliant” i niczego się nie krytykuje. Po wielu latach rotacji miernych programistów zostaje kupa w kodzie.

Poza tym, znaj swoje miejsce. Jeśli jakiś external employee z Europy wschodniej chce wprowadzać swoje standardy, to sorry, ale ma tak samo ciężko jak Hindus z Indii w analogicznej sytuacji w Polsce.

orchowskia napisał(a):

Powiedzcie proszę że źle trafiłem i wystarczy poszukać nowej firmy, pragnę akceptacji.

Źle trafiłeś, poszukaj innej firmy.

Kiedyś pracowałem przez kilka lat dla klienta z UK (firma produktowa), takie coś by tam nie przeszło.
Jeszcze wcześniej, w innej firmie, dostaliśmy kod wyprodukowany w UK - nie było kontrolerów, do bazy się strzelało prostu z frontendu.
Tak więc możesz trafić lepiej albo gorzej, kraj pochodzenia firmy nie ma znaczenia.

@somekind: Ale jaki masz problem ze strzelaniem do bazy prosto z frontendu :) ?
Taki np supabase(oparte o postgresie) ojebie ci logowanie, ojebie ci RLS + masz dostęp do profilu użytkownika na tym poziomie, a do tego wystawi ci api graphql'owe czy nawet rest a z tyłu funkcje bazodanowe :). Więc nawet takie rzeczy jak wyciagani raportów z wielomilionowych tabel ciężko zjebać.
Większość crudów dałoby sie ojebać tego typu rozwiazaniami i byłoby w c**** stabilniejsze a na pewno tańsze.

Z całego posta zrozumiałem, że tak konkretnie problem jest z umieszczeniem logiki w kontrolerach i mieszanie bazy danych z jsonami do zwrotki http. Fakt, jest to problem - a próbowałeś opisać problem i powiedzieć co da rozbicie na warstwy?

Oprócz wyżej wymienionego, nie widzę konkretnie nic innego.

orchowskia napisał(a):

encje bazodanowe są anemiczne.

No i co z tego ?

1. Rób swoje.
2. Szukaj nowej pracy - omijaj szerokim łukiem miejsca gdzie jest excellent, mają super działający scrum, czysty kod, idealną architekturę, dobre testy itp.

Każdy zespół projektowy ma w swoim składzie odpowiednią ilość idiotów, a ci generują określoną masę głupoty. Jak masa krytyczna zostanie przekroczona to dochodzi do reakcji łańcuchowej. Jedną z cenniejszych umiejętności w karierze programisty jest przewidzenie kiedy dojdzie do reakcji łańcuchowej i wycofanie się zanim to nastąpi.

Konia z rzedem temu, kto znajdzie sensownego producto ownera. Po części przyzwyczaiłem się do ich niedoskonałości. Natomiast mnie bardziej boli praca z developerami którzy udają pożytecznych idiotów, a właściwie nic nie robią oraz developerów przekonanych o własnej zajebistości choć są mniej niż zerem i nie mają ochoty tego zmieniać.

Przydałby Ci się taki scrum master jak u mnie, czyli jego brak bo go wy****li za to, że się opierda**ł :P
Lepsze to niż "wyczarowywanie" zbawiennych rozwiązań i wnerwianie dev-ów swoimi pomysłami ;)

aolo23 napisał(a):

Przydałby Ci się taki scrum master jak u mnie

Co do scruma:

Dla mnie scrum to jest proces, a nie stanowisko.

Co do scum masterów:

W swojej karierze przerobiłem sporą ilość scrum masterów. Mam wybitnie kiepskie zdanie o osobach pracujących w tej roli.

W moim obecnym projekcie mamy ziomka który zrezygnował z bycia programistą i zajął się scurmem. Pracy ma niewiele, kasa podobna do programersów, udaje że wyznaje się na temacie lecz się nie wyznaje.

W poprzednim projekcie scrum master też był gościem który nie sprawdził się w roli programersa więc zaproponowano mu takie stanowisko. Po pierwszym callu wysyłał zaproszenia na wszelkich szocial mediach, wchodził w życie prywatne, zazdrościł wszystkiego.

Ogólnie to średnio wiadomo co taka postać scrum mastera ma robić. Na pewno jest to ciepła posadka jak w urzędzie.

Co do nadmiernej kreatywności:

Rozmawiałem kiedyś z psychologiem na ten temat i jegomość wspomniał, że to raczej normalne nie jest. Wspomniał coś o spektrum schizofrenii i konieczności leczenia gdy osoba nie zachowuje wyraźnego krytycyzmu w stosunku do swoich zachowań. Jak ktoś zatrudnia wariatów to jego problem. Ja wolę trzymać się od takich ludzi z daleka.

scrum jest inaczej sprzedawany biznesowi, a inaczej zasobom ludzkim, cały system opiera się na tym przecież żeby zasoby ludzkie miały nadzieje że będzie lepiej.
wiadomo są jacyś upupieni ludzie którzy nigdy w macdonalds/kfc nie byli, ale większość ludzi tam była,
i pierwszy raz się zdziwiła jak na billboardzie był inny burger niż dostali po zakupie, to im się lampka już zaświeciła.
nie bez powodu sprint się nazywa sprintem, a nie run (bieg), march (marsz), walk(chód). Spróbujcie raz po razie przebiec pare sprintów, a zrobić kilka marszów to zrozumiecie czego się oczekuje od zasobów ludzkich w scrumie :-). Jak mówią scrum masterzy, scrum isn't walk in the park. Jak ktoś by wam powiedział że poprzednie dwa tygodnie w pracy to był sprint, to każdy zrozumiał by że był ostry zapierdol. Jakby dodał, że raz za razem co dwa tygodnie macie sprint od miesięcy, to ktoś by uznał że w niezłym kołchozie pracujesz, ale jak się zapierdalaniu na plantacji oprogramowania da trendy nazwę, to robi się to zwinne
jak się sprzedaje biznesowi scrum:
daily meeting to takie spotkanie statusowe, tak jak w fabryce/magazynie, że przed zmianą mówi się jaki jest dzisiejszy target, co się będzie robiło, i czy wczoraj się udało dowieźć target, czy trzeba nadganiać. Oraz jakie były, mogą być problemy, że jakaś paczka np nie wyszła i zmiana dostaje opierdol. dodatkowo jest to taki mini dzienny deadline, że obiecujesz że do następnego daily coś zrobisz, taki mini crunch przed kolejnym daily żeby zasób ludzki nie musiał się spowiadać czemu nie dowiózł commitment z poprzedniego daily, plus pomaga by mieć lepsze traceability, measurement i accountability tego czy się dowiezie cel sprintu, tak żeby było accountability
w backlogu są tylko feature które mają wartość biznesową, by bugi itd trzeba było robić w nadgodzinach i nie uwzględnia się nieplanowanych rzeczy, spotkań, daily, refactoru, architektury, optymalizacji, ci/cd, urlopy, refactor, dokumentacja, optymalizacja procesów. Tłumaczy się to tym że to nie buduje wartości biznesowej dla klienta, bo poprawki błędów i spotkania nie przynoszą zysku same w sobie.
używa się punktów zamiast godzin, jeżeli chcesz mieć coś dobrze zaplanowane to umieszczasz to w kalendarzu i blokujesz dla danego zadania czas wtedy widzisz ile możesz zrobić w danym okresie czasu, ile idzie na spotkania itd, dzięki punktom i przy dobrym scrum masterze zasoby ludzkie biorą więcej tasków niż powinny, taka sama zasada jak używanie żetonów w kasynie, dodatkową kwestią że dzięki punktom liczonym jako trudność zadania możesz porównywać kpi zasobów ludzkich. Bo przy liczeniu godzin, nie możesz użyć tego do porównywania wydajności pomiędzy zasobami ludzkimi.
wycenia się user story by mieć optymistyczną estymacje, a jak ktoś powie że zrobi, to będzie pracował w darmowych nadgodzinach by dowieźć, są oczywiście tacy którzy tego nie robią ale od tego jest scrum master by pokazać drugą stronę drzwi
dodatkowo user story powinny być małe, by dało się weryfikować ich wykonanie pomiędzy daily, najlepiej 1-3 dni by był zawsze widoczny progres. Oraz żeby były ładne burndown charty, i visibility sprintowania
sprint, a dokładniej review przed klientem gdzie zespół się spowiada z tego co zrobił, pokazuje burndown charty, tabelka z członkami zespołu i zdobytymi przez nich punktami, jest po to by wymuszać częste deadliney, i kapitalizować na tym że ktoś się zobowiązuje do wykonania celów sprintu, po prostu jest to wymuszenie crunchu co 2 tygodnie, a nie tylko przed releasem. Czyli w scrumie masz dwa crunche, mały crunch przed kolejnym daily żeby nie świecić oczami przed scrum masterem, i duży crunch przed review żeby nie świecić oczami przed klientem. Plus wiadomo przygotowanie do review przed klientem nie ma wartości biznesowej jako funkcjonalność więc tego nie szacujemy (postawienia środowiska, próby przeklikania itd).
retrospekcje są po to, by zasoby ludzkie mogły się wygadać i wyrzucić z siebie problemy. Oraz podkablować na innych. Tak żeby zasoby ludzkie czuły się wysłuchane, ewentualnie od czasu do czasu, w nagrodę zrobić coś dla nich małego i taniego. Dodatkowo ma to ważny cel budowania nadziei że sytuacja się poprawki, tak jak w tym memie że lepiej będzie po szkole, po tym jak znajdziesz robotę, po tym jak znajdziesz dziewczynę, po tym jak się dorobisz, jak będziesz na emeryturze...
w scrumie jest takie coś że można ciągle zmieniać, mieszać i modyfikować, po to żeby nie trzeba było tracić czasu na dobre zdefiniowanie projektu/wireframe/mvp i przerzucić koszt tego na zespół scrumowy, który będzie zmieniał i poprawiał by dowieźć commitment sprintu mimo setbacków
sprint musi być zawsze dowieziony, nie można go nigdy anulować nawet gdy product owner nie odp na pytania zespołu lub wyszły jakieś niespodziewane rzeczy. Dokładnie tak jak komunistyczny plan 5 letni, który zawsze musi być dowieziony przez przodowników pracy, inaczej kogoś czeka egzekucja z pozycji człona partii lub zespołu
punktów używa się jako KPI/productivity metrics by mieć porządny traceability&measurement, robi się burndown chart, tabelkę z tym ile każdy członek zespołu zdobył punktów, itd by widzieć przodowników pracy i jak szybko zespół "buduje wartość"
bardzo ważne jest by praca była widoczna, i nie pozwalać na ukrywanie czegokolwiek, a wszystkie porażki w dowożeniu muszą być widoczne, od tego są karteczki, burndown, daily itd. tak żeby każdy wstydził się zawalić i ostro zapierdalał, żeby go plemię nie wyrzuciło (dawniej wyrzucenie z plemienia to była śmierć, więc ludzie mają to mocno w genach zapisane)
refinement jest po to by przypominać ile rzeczy jest do zrobienia i że trzeba zapierdalać, być może dorzucić też coś do pieca, tak by w każdym kolejnym sprincie robić coraz większe velocity punktów
planowanie polega na tym by wcisnąć jak najwięcej punktów do sprintu, i wrzucanie czy dacie rade zrobić to czy tamto bo punktów brakuje w sprincie, bo w poprzednim było x, albo to tylko punkt więcej, wiadomo ma być continous impovement / infinite growth, w każdym sprincie ma być wyższe velocity, bo się zespół się rozpędza, scrum master mówi że w poprzednim sprincie było x, więc teraz powinniśmy dać radę zrobić x*1,05 (+5% albo więcej), i zrobić jakąś animację zasobów, damy radę, jak nie wy to kto itd żeby zmotywować, pizza w nagrodę itp.
w pewnym momencie konwertuje się scrum na waterfall estymując cały backlog i dzieląc na sprinty, biorąc pod uwagę aktualne velocity i nie biorąc pod uwagę że będzie coraz więcej bugów oraz będą zmiany i modyfikacje, ale wyznaczając deadline całego projektu
częścią tej konwersji/migracji, jest by zasoby ludzkie zgodziły się na plan kilku sprintów do przodu, tzw roadmapa
gamifikacja, czyli tablica scrumowa, nikt nie chce się zhańbić i przenieść najmniejszej liczby kartek oraz "zdobyć" najmniej punktów w sprincie:
różne rytuały, ceremoniały, mitologia, korporacyjna indoktrynacja i nowomowa jest po to by zasoby ludzkie nie zorientowały się że robią na plantacji oprogramowania, taka gamifikacja wyścigu szczurów, do tego właśnie jest scrum master:
wspomniane wcześniej rzeczy mają na celu uzależnienie zasobów ludzkich od pracy poprzez wywołanie pracoholizmu, tak jak napoje dodają dużo cukru by uzależnić od swoich produktów, firmy tytoniowe robią fajki z większą ilością nikotyny, a w białym proszku jest fentanyl. Tak firmy chcą wywołać uzależnienie od pracy dla nich. Tj żeby pracownicy mieli trudność w zrelaksowaniu się i ciągle myśleli o pracy. By pracowali kompulsywnie jak palacz sięgający po papierosa co chwile, czuje się niekomfortowo gdy nie pracuje, wkłada więcej energii w firmę którą pracuje niż w swoje prywatne życie. Tak by ich całe życie to była jedynie praca. Ważne jest też wywołanie uczucia że nie mogą odejść, bo firma bez nich padnie i sobie nie poradzi. Żeby pracowali nie dla pieniędzy, tylko respektu, poczucia bycia lepszym w pracy od innych, wygenerowania dużego surplusu punktów w ciągu dnia, by mieć dobre velocity w sprincie i zrealizować sprintowy plan dwótygodniowy tak by mieć dobre walidację w postaci performance review i oceny zespólu. Kariera to ich życie, ich przyjaciele to współpracownicy, jedyne miejsce gdzie ich życie jest ogarnięte to ich kariera, ich praca to jedyne miejsce gdzie są akceptowani i jest to jedyne miejsce dostają pozytywne bodźce i akceptację drugiego człowieka jest praca, praca to ich tożsamość i najbardziej interesująca w nich rzecz, bo poza pracą są nudziarzami, są uzależnieni od "respektu" i "prestiżu" ich pracy, firma to ich rodzina/plemię/sekta/kult, jak mogą wyprzeć się/zdradzić swoją rodzinę. Dodaj do tego bonusy które dostaniesz po 2 latach, zorganizowane w taki sposób byś zawsze tracił jakiś bonus jeżeli odejdziesz lub Cię zwolnią, i masz perfekcyjną receptę na pracoholizm (wykorzystuje to ludzką podatność że bardziej się boją stracić niż zyskać). Scrum to dobry framework do złapania zasobów ludzkich w pułapkę pracoholizmu.
wiadomo są zasoby ludzkie które fetyszują scruma, po prostu jest więcej ludzi którzy lubią soft-BSDM niż się wydaje, tak przy okazji BSDM biczuje nowe światło na role scum MASTER'a, i kto tu jest slave'em :-) taki paradoks że teraz brancha nie można mieć już w repo mastera, nie można mieć white/black list, ale scrum może być masterem, widać jakie są priorytety ;-)
W scrumie slave ma być pracoholicznym NPC, atomomotonem, bez swoich emocji, łatwo wymienialnym trybikiem maszyny, gdzie jest mocno kontrolowany, podporządkowany kultowi scrum'a, zatopionym w jego fetysze, ceremoniały i inne kultowe mistycyzmy.

Jaslanin napisał(a):

scrum jest inaczej sprzedawany biznesowi, a inaczej zasobom ludzkim, cały system opiera się na tym przecież żeby zasoby ludzkie miały nadzieje że będzie lepiej.

Dziękujemy za wypociny niemniej z tego co obserwuję to każda firma ma swoją definicję scruma i może na tym skończmy bo za bardzo schodzimy w ideologię.

Dodatkowo pod wpływem charyzmatycznego "architekta" logika znajduje się nie gdzie indziej jak w kontrolerach, a w sumie najlepiej w kontrolerze, dzięki czemu strzelanie do bazy i mieszanie zwrotki z JSONem nigdy nie było tak proste.

Czyli dominuje transaction script, co warto zaznaczyć transaction script to nie jest anti-pattern. Po prostu bardziej proceduralne podejście. Nie zrozum mnie źle, nie chcę pisać, że to złe czy dobre - bo w swej istocie to jak to z każdym narzędziem / podejściem bywa - zależy od przykładu, konkretnego użycia i potrzeb.

W każdym razie narzekanie na coś bez konkretnego uzasadnienia jest tylko bezproduktywnym narzekaniem i to mnie w Twojej wypowiedzi trochę boli, a tak to z resztą jest luz.

Czy tak wygląda pragmatyzm? Czy pragmatyzm boi się rozdzielania odczytów od zapisów? Czy może ja jestem obmierzłym teoretykiem który by wciskał wzorce projektowe i bezsensownie budował abstrakcje. Bo abstrakcje są bez sensu, tak jak podział projektu na moduły.

Oddzielanie odczytów od zapisów to większa złożoność, więcej pośrednich typów i abstrakcji, które z czasem mogą Ci się rozjechać. Samo oddzielanie odczytów i zapisów nie jest pozbawione kosztów, a jednym z nich jest utrudnione czytanie kodu, utrzymanie synchronizacji i spójności w obrębie biznesowych procedur.

Może się męczysz z tą pracą, bo oni chcą problem ogarnąć prostszymi, mniej zaawansowanymi środkami? Wg mnie nie jest to złe, ale też nie jest zbyt porywające.

znowutosamo napisał(a):

Czyli dominuje transaction script, co warto zaznaczyć transaction script to nie jest anti-pattern. Po prostu bardziej proceduralne podejście. Nie zrozum mnie źle, nie chcę pisać, że to złe czy dobre - bo w swej istocie to jak to z każdym narzędziem / podejściem bywa - zależy od przykładu, konkretnego użycia i potrzeb.

Wpychanie logiki biznesowej do infrastrukturalnej (kontrolerów) to jest jak najbardziej antywzorzec, i nie ma związku z transaction scriptem, który to organizuje logikę biznesową w procedury obejmujące pojedyncze transakcje.

Oddzielanie odczytów od zapisów to większa złożoność, więcej pośrednich typów i abstrakcji, które z czasem mogą Ci się rozjechać. Samo oddzielanie odczytów i zapisów nie jest pozbawione kosztów, a jednym z nich jest utrudnione czytanie kodu, utrzymanie synchronizacji i spójności w obrębie biznesowych procedur.

Owszem, jest więcej typów - i dzięki temu zarówno czytanie jak i utrzymanie kodu jest ułatwione, bo trudniej zepsuć zapis przy okazji wprowadzania zmian w odczycie, i vice versa.

Dzięki @somekind za odpowiedź.

Masz rację, pisząc Transaction Script jednak pomyliłem procedurę jaką wytacza kontroler z serwisem (warstwa logiki).

Zakładam, że zaszywanie logiki w kontrolerze dla Ciebie oznacza antywzorzec, ponieważ nie ma wtedy odgórnego limitu na to co może bezpośrednio znaleźć się w kontrolerze. Potencjalnie mogłoby tam przecież wskoczyć wszystko, efekt z wymieszaniem szczegółów pochodzących z różnych warstw nie jest szczególnie ciekawym widokiem. To utrudnia wydzielania zarówno z myślą o ponownym użyciu jak i rozłożeniu kodu tak, aby dało się go czytać mniejszymi porcjami. Taki kod kod kontrolerów z pewnością nie raz może być zbyt obszerny i zbyt konkretny, w rezultacie trudny do pojęcia.

Jeśli się mylę to daj znać co miałeś na myśli. Ja tego podejścia nie neguje, ponieważ zakładam, że to zależy od przypadku.

Przykładowo przy złożonej logice warto się zatrzymać, warto napisać kod, który nie tylko będzie niezależny od platformy, ale taki który również przygotuje odpowiednie podwaliny, rozpatrzy problem dziedziny szerzej, aby na tej podstawie dało się wyprowadzić pewniejsze rozwiązania.

Nie mniej większość rzeczy nie jest zbyt trudna w pojęciu, przeważnie sprowadza to się do wyliczenia przypadków w ramach których dochodzi do przeniesienia danych z punktu A do punktu B.

Gdybym każdą taką drobną zmianę probówał opakować w coś niezależnego to każda rzecz jaka dosłownie chciałbym wyrazić w kodzie oznaczałaby nową definicję funkcji/metody/klasy, w kodzie miałbym multum kruchych komponentów (bo ich api przeciekałoby przy zmianie wymagań). Czy to byłoby zrozumiałe? Wrażenia pracy z takim kodem byłyby jak podczas czytania umowy gdzie każde słowo jest specyficzne i charakterystyczne tylko i wyłącznie dla tej jednej umowy, a powtórzenie niedopuszczalne. Piszący umowę mógłby argumentować, że chodzi o jednoznaczność, aby zniwelować nieporozumienia, ale z drugiej strony kto normalny taka rzecz przeczyta ze zrozumieniem?

W tym wydaniu nadmierna specyficzność powoduje efekt odwrotny od zamierzanego. Nie raz, gdy próbuje coś przeczytać to co z tego, że metoda ma nazwę, co z tego, że problem jest podzielony na warstwy skoro i tak muszę zajrzeć co kryje się pod każdą nazwą, by zrozumieć sens głównej procedury i to czy jej zachowanie jest nadal zgodne z wymaganiami.

Odnośnie oddzielenia odczytów od zapisów mam zbliżone zdanie. Więcej typów, to więcej pojęć, które wyłącznie istnieją dla jednego projektu więcej pojąć nie ułatwia zrozumienie domeny choćby nie wiem jaka ona była.

Poza tym to czy masz podział na pisanie i czytanie rzeczywiście ułatwia samo czytanie kodu? Drobnoziarniście tak, bo masz mniejsze porcje, mniej zmian do prześledzenia i łatwiej to testować/rozszerzać/ponownie używać, ale z perspektywy biznesowego przypadku masz jednak trudniej, bo żeby pojąć cały problem czytasz kod skacząc od jednego miejsca do drugiego. To nie jest obraz ułatwiający zrozumienie. To nie jest obraz ani scenariusz, lecz coś w postaci dania, które przed wydaniem zostało rzucone w szprychy.

Oczywiście oddzielenie odczytu od zapisu ułatwia oddzielenie fazy budowania od wykonania, i to ma szereg ciekawych własności, wpływających na elastyczność czy wydajność. Z tym drobnym zastrzeżeniem, że elastyczność nigdy nie upraszcza pracy, lecz wnosi do projektu dodatkową złożoność o jakiej należy pamiętać i jaka nieraz również komplikuje pojęcie przepływu.

W ciemno podziałów nie kupuje i nie polecam, bo z perspektywy kodu wszystko ma swój koszt. Jeśli masz trudny przypadek podział kodu może się zwrócić, a jeśli coś trywialnego to niekoniecznie. Wymuszona abstrakcja (wywołana unikaniem powtórzenia) prędzej pęknie i nim się obejrzysz, lekka zmiana wymagań i dochodzi Ci jeszcze więcej pracy.

w kodzie miałbym multum kruchych komponentów (bo ich api przeciekałoby przy zmianie wymagań). Czy to byłoby zrozumiałe? Wrażenia pracy z takim kodem byłyby jak podczas czytania umowy gdzie każde słowo jest specyficzne i charakterystyczne tylko i wyłącznie dla tej jednej umowy, a powtórzenie niedopuszczalne.

To o czym piszesz, to sytuacja kiedy ktoś na czuja próbuje wydzielić komponenty, zanim to będzie potrzebne, zanim zrozumie, po co to robi. A jak ktoś nie wie, co robi, nie jest w stanie przewidzieć wymagań biznesowych czy problemów technicznych, na jakie natrafi w przyszłości w danym projekcie, to nie jest w stanie zrobić dobrej abstrakcji, a tworzy jedynie "nazwane pojemniki na kod" albo "abstrakcje na czuja", które finalnie okażą się nieodpowiednie.

• I efektem może być to, co opisałeś, czyli Enterprise Hello World, czyli próby wydzielania kodu bezmyślnie, dla samego wydzielania
• Ale efektem może być też wrzucanie wszystkiego jak leci w jedno miejsce, np. do kontrolerów, bo przecież ciężko wydzielić abstrakcje, jak się nie wie jak, to po co próbować.

A wystarczyłoby trochę pomyśleć i zastosować refaktoring.

• Jeśli ktoś zrobił Enterprise Hello World, to może to zrefaktorować do czegoś bardziej sensownego. Raz wydzielone abstrakcje można niszczyć, łączyć, zamieniać w inne.
• Jeśli ktoś napakował logiki w jedno miejsce (np. do kontrolera), to może tę logikę zacząć wydzielać.

Niestety refaktoring to coś, o czym się dużo mówi, ale zwykle się tego nie robi, bo przecież "nie ma czasu" czy "to nie przyniesie wartości biznesowej".

Alternatywą byłoby zrobienie czegoś od razu dobrze, ale wtedy po prostu potrzebujesz mieć doświadczenie w pisaniu konkretnego rodzaju aplikacji i duże ogólne doświadczenie programistyczne, żeby odpowiednio zadecydować o abstrakcjach.

znowutosamo napisał(a):

Zakładam, że zaszywanie logiki w kontrolerze dla Ciebie oznacza antywzorzec, ponieważ nie ma wtedy odgórnego limitu na to co może bezpośrednio znaleźć się w kontrolerze. Potencjalnie mogłoby tam przecież wskoczyć wszystko, efekt z wymieszaniem szczegółów pochodzących z różnych warstw nie jest szczególnie ciekawym widokiem. To utrudnia wydzielania zarówno z myślą o ponownym użyciu jak i rozłożeniu kodu tak, aby dało się go czytać mniejszymi porcjami. Taki kod kod kontrolerów z pewnością nie raz może być zbyt obszerny i zbyt konkretny, w rezultacie trudny do pojęcia.

Tak, o to chodzi - spaghetti nie pomaga w czytaniu, testowaniu czy utrzymywaniu kodu, a kontrolery mają jasno sprecyzowaną odpowiedzialność.

Gdybym każdą taką drobną zmianę probówał opakować w coś niezależnego to każda rzecz jaka dosłownie chciałbym wyrazić w kodzie oznaczałaby nową definicję funkcji/metody/klasy, w kodzie miałbym multum kruchych komponentów (bo ich api przeciekałoby przy zmianie wymagań). Czy to byłoby zrozumiałe?

Tak, bo przy takim podejściu zmiana wymagań dotyczących X powodowałaby zmiany tylko w kodzie odpowiedzialnym za X, a więc bez ryzyka przypadkowego zepsucia innych obszarów aplikacji.

W tym wydaniu nadmierna specyficzność powoduje efekt odwrotny od zamierzanego. Nie raz, gdy próbuje coś przeczytać to co z tego, że metoda ma nazwę, co z tego, że problem jest podzielony na warstwy skoro i tak muszę zajrzeć co kryje się pod każdą nazwą, by zrozumieć sens głównej procedury i to czy jej zachowanie jest nadal zgodne z wymaganiami.

Skoro tak się dzieje, to znaczy, że podział na abstrakcje jest błędny.

Odnośnie oddzielenia odczytów od zapisów mam zbliżone zdanie. Więcej typów, to więcej pojęć, które wyłącznie istnieją dla jednego projektu więcej pojąć nie ułatwia zrozumienie domeny choćby nie wiem jaka ona była.

No jeśli wymyślamy nazwy losowe, to może być trudno. Jeśli trzymamy się jakichś konwencji, to jest łatwo.

Poza tym to czy masz podział na pisanie i czytanie rzeczywiście ułatwia samo czytanie kodu? Drobnoziarniście tak, bo masz mniejsze porcje, mniej zmian do prześledzenia i łatwiej to testować/rozszerzać/ponownie używać, ale z perspektywy biznesowego przypadku masz jednak trudniej, bo żeby pojąć cały problem czytasz kod skacząc od jednego miejsca do drugiego.

Jeśli czytanie i zapisywanie to oddzielne biznesowe przypadki, więc nie trzeba między nimi skakać, żeby zrozumieć jeden z nich. Mam wrażenie, że piszesz o czymś innym.

W ciemno podziałów nie kupuje i nie polecam, bo z perspektywy kodu wszystko ma swój koszt. Jeśli masz trudny przypadek podział kodu może się zwrócić, a jeśli coś trywialnego to niekoniecznie. Wymuszona abstrakcja (wywołana unikaniem powtórzenia) prędzej pęknie i nim się obejrzysz, lekka zmiana wymagań i dochodzi Ci jeszcze więcej pracy.

W abstrakcji nie chodzi o unikanie powtórzeń, za to kod podzielony prawidłowo na abstrakcje jest łatwiejszy do wprowadzania zmian niż taki, który podzielony nie jest.

Tak, bo przy takim podejściu zmiana wymagań dotyczących X powodowałaby zmiany tylko w kodzie odpowiedzialnym za X

Iluzja, błąd poznawczy. Niestety, ale wymagania nachodzą na siebie i oddziałują na siebie czyniąc pracę trudniejszą. Gdyby tak nie było miałbyś store z komponentami, a w niej zrealizowane pojedyncze wymagania jakie po prostu wrzucasz do swojego projektu. Niestety 2 bądź 3 dodatkowe wymagania potrafią zmienić podejście do zadania o 180' i to właśnie rzutuje na to, że zmiana X nie odnosi się do zmian odpowiedzialnych wyłącznie za X. Przykładowo jak zmienia Ci się model sprzedaży to nie zmienia Ci się tylko sposób płatności, to znacznie szersza zmiana.

Skoro tak się dzieje, to znaczy, że podział na abstrakcje jest błędny.

Abstrakcja jest dobra jeśli rzeczywiście ukrywa rzeczy nieistotne, ale jeśli ukrywa to co jest ważne to pojawia problem. Abstrakcje są dobre, żeby ukryć rzecz, która może być niezależna od domeny, ale Ty piszesz o odwrotnej rzeczy, o uniezależnieniu od instrastruktury. To siłą rzeczy powoduje tworzenie opakowań z domeną, które nie będą szczelne, bo wraz ze zmianami będą przeciekać, choćby pod tym względem, że nazwa która robi X będzie robić kilka dodatkowych operacji (niezgodnych z samą nazwą) o jakich na samym początku w ogóle byś nawet nie pomyślał.

No jeśli wymyślamy nazwy losowe, to może być trudno. Jeśli trzymamy się jakichś konwencji, to jest łatwo.

Nie losowe. Chodzi o to, że pisząc kod nie widzisz wszystkiego. Nie ma konwencji, która pozwala patrzeć w przyszłość.

Każda decyzja techniczna wnosi jakiś koszt. W przypadku pójścia w kierunku kodu niezależnego od infrastruktury, dostajesz znacznie więcej abstrakcji, które mają tendencję do przeciekania, a przeciekają, bo są tak silnie zależne od biznesu. Więcej abstrakcji to również więcej przecięć, więcej skoków w kodzie, jeszcze więcej typów i nazw.

Oczywiście są też i zalety, ale skoro już je znasz to uznam, że nie ma sensu dalej rozwijać tego tematu.

Dobra, ja trochę z biblii zaczerpnę "po owocach ich poznacie".

Pomijam umiłowanie agile, atmosferę w firmie - kwestia subiektywna. Ale jest parę innych pytań:

• Czy produkt robi to co ma robić?
• Czy jest dużo błędów?
• Czy jak się trafi błąd, to wiadomo gdzie go szukać?
• Jak się już znajdzie, to czy długo zajmuje jego naprawa?
• Ile czasu trwa dostarczenie nowej funkcji od jej wymyślenia na produkcję?

Nie twierdzę, że to jacyś geniusze, ale może kombinacja paru cech, np. burdel w kodzie i mały rozmiar każdej z usług się u nich sprawdza?

orchowskia napisał(a):

Jakiś czas temu zacząłem kontrakt w firmie która rozwija swój produkt z branży hotelarskiej. To jaka to branża to może mniej istotne.

Mylisz się. To jaka to branża ma w tym przypadku kluczowe znaczenie.
Turystyka i hotelarstwo to trudne rynki a do tego większość klientów jest zwyczajnie biedna (w porównaniu z innymi branżami).
Powyższe rzutuje dosłownie na wszystko. Systemy tworzone są po kosztach, bez wsparcia i sensownej analizy.. Dlaczego? Dlatego, że nikt za to nie zapłaci.
Pozostaje zatem pytanie dlaczego ktoś godzi się to pisać? Bo płacą zgadzając się na to, że otrzymają produkt niskiej jakości.
Pomimo dziwacznej sytuacji, klienci w tej branży w większości są rozsądni i mają świadomość, że mało płacą ale ich oczekiwania też nie są wygórowane.
Takie specyficzne miejsce... i dotyczy to zarówno klientów krajowych jak i zagranicznych.

Każda decyzja techniczna wnosi jakiś koszt. W przypadku pójścia w kierunku kodu niezależnego od infrastruktury, dostajesz znacznie więcej abstrakcji, które mają tendencję do przeciekania, a przeciekają, bo są tak silnie zależne od biznesu. Więcej abstrakcji to również więcej przecięć, więcej skoków w kodzie, jeszcze więcej typów i nazw.

Tworząc abstrakcje żeby uniezależnić kod domenowy od infrastruktury sprawiamy że do abstrakcje przeciekają... gdzie przeciekają i dlaczego jest to problem? Patrząc np. na heksagon, otaczając całą esencję danego serwisu fasadami itd. nie widzę za bardzo takiej możliwości. Czy porty i adaptery muszą się zmienić jeśli model się zmieni? No tak, ale to pożądany efekt, bo przy opisanym przeze mnie podejściu w firmie jest w drugą stronę, tj wszystko sterowane jest widokami/kontraktami api/konkretnymi bibliotekami do usług chmury takimi jak kolejki itd. I cały ten sajgon przecieka ci do domeny, do abstrakcji. Już pomijając aktualizację wersji takiej biblioteki, nie da się tego przeczytać dopóki nie zrozumiesz każdej z usług. Na azure przez pół roku mi się plątały usługi EventGrid/EventHub

Jeszcze więcej typów i nazw i skoków w kodzie. No okej, dlaczego to problem? Jeśli jakiś koncept istnieje to dlaczego ma zostać zmiksowany z całą resztą. Potem trzeba się maziać w takiej brei.
Skoki w kodzie przy współczesnych IDE chyba nie są problemem? Jeśli coś jest za abstrakcją to czytasz tylko nazwę abstrakcji, znacznie rzadziej interesuje cię jej implementacja. Powiedziałbym że ogranicza się ilość kodu potrzebnego do przeczytania żeby skminić co jest grane. A nie że czytasz sobie kod jakiejś metody kontrolera który ściąga ci rzeczy z bazy danych, wrzuca event na kolejkę i jeśli się udało to wysyła ci maila na skrzynkę usera, którą żeby mieć najpierw trzeba strzelić do serwisu z userami i dostać odpowiedź :)

Można to zrobić o wiele ładniej, czytelniej, nawet nie wydzielając stricte abstrakcji biznesowych, niech sobie biznes siedzi w serwisie jakimś ale zajmuje się tylko biznesem, ale żeby to zrobił to niech dostanie z innej warstwy wszystkie potrzebne informacje do wykonania decyzji i później zaaplikuje je w bazie. Dalej będzie pragmatycznie a i o wiele łatwiej będzie można rozwiązać problemy i później pomyśleć o abstrakcjach jak nam się wyklarują, będzie dla nich miejsce.

dzie przeciekają i dlaczego jest to problem?

Celem abstrakcji jest ukrywanie nieistotnych szczegółów dotyczących wybranego zadania. Odrywając mniej istotne szczegóły możesz skupić się na tym co istotne. W sytuacji odwrotnej, gdy abstrakcja ukrywa to co istotne to ze swojej definicji abstrakcja przestaje pełnić swoją podstawową rolę, a więc staje zasadniczą częścią Twojego zadania o którym musisz myśleć/pamiętać na etapie jego rozwiązywania.

Jeśli abstrakcja jest zależna od biznesu wówczas łatwo stracić szczelność. Biznes zmienia zdanie, a abstrakcja przecieka.

Mówisz, że na plus jest to, że widzisz w jakim miejscu to się dzieje, ale to nie jest rozwiązanie jakie powinno się cenić. To tak jakbyś budował budynek i użył materiału, który się szybciej się zużywa, ale i tak widzisz w tym jest plus, bo klientowi powiesz, że on będzie mógł sobie szybciej rozpoznać gdzie ściana częściej pęka / trwoni ciepło.

A problemem w przypadku nietrafionych abstrakcji jest ich koszt, ponieważ jest on znacznie większy niż brak abstrakcji, pewnie to znasz, ale podlinkuję: https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction

Czy porty i adaptery muszą się zmienić jeśli model się zmieni? No tak, ale to pożądany efekt (...)

Kupiłbyś laptop wiedząc, że wraz z wymaganą aktualizacją systemu za 3 miesiące będziesz musiał wymienić w nim jego porty?

przy opisanym przeze mnie podejściu w firmie jest w drugą stronę, tj wszystko sterowane jest widokami/kontraktami api/konkretnymi bibliotekami do usług chmury takimi jak kolejki itd. I cały ten sajgon przecieka ci do domeny, do abstrakcji. Już pomijając aktualizację wersji takiej biblioteki, nie da się tego przeczytać dopóki nie zrozumiesz każdej z usług. Na azure przez pół roku mi się plątały usługi EventGrid/EventHub

Na samym początku odpowiadając na ten fragment chciałbym zaznaczyć, że nie jestem przeciwnikiem wydzielania infrastruktury. Jak najbardziej rozumiem uproszczone interfejsy, aby dało się w razie potrzeb np. przełączyć jedną bazę na drugą. Jak najbardziej widzę sens w jdbc albo jakimś interfejsie do baz kv, by móc łatwiej zmienić bazę np. w czasie migrować z jednej chmury na drugą.

Natomiast nie widzę uzasadnienia w sytuacji, gdy interfejs infrastruktury łączy się z domeną, aby całkowicie oderwać się od infrastruktury. Po prostu jak widzę metody w stylu createAccount, a w środku jest jedynie uderzenie w bazę to widzę w tym jedynie krótkowzroczność.

Oczywiście to nie jest tak, że to nie działa. To działa, ale do pewnego limitu, wszystko zależy od zakresu użycia. Jeśli jakaś część infra obejmuje większą część projektu to wtedy nawet, gdybym miał wybór, nie próbowałbym tego wydzielać, lecz uznałbym to jako element architektury i sorry, ale wymagałbym, aby programista jednak posiadał wiedzę na temat tego narzędzia przed wejściem w projekt.

Sytuacje, gdy mamy biznesowe opakowanie na infra i tak nie pomogą zmienić postgresql na mongo (tu cały czas mam na myśli szerszy zakres użycia). Nawet posiadając testy trudno jest zagwarantować to samo zachowanie, poprawność transakcji w obrębie systemu, nie mówiąc już o samej spójności.

W przypadku infrastruktury, która w projekcie występuje z ograniczonym zakresem użycia to wtedy próbuję w oparciu o ten zakres rozpatrzeć możliwość zamknięcia całego infra wraz z powiązaną domeną. Czyli nie mam przejściówek per model, ale zamykam główną funkcjonalność za jednym interfejsem.

Takie moduły są większe niż mapery / adaptery, ale mają również większą decyzyjność i powodują, że jest mniej komunikacji między pozostałymi modułami (podejście tell don't ask), powstaje mniej nazw, pośrednich typów w tym również publiczne api samego modułu się kurczy. Rezultatem jest kompromis, biznesowa część jest zależna od części infrastruktury, a ta część infrastruktury jest zależna od części biznesu. Nie mówię, że wszystko jest wszystkim, lecz ograniczam zakres obu części łącząc wzajemnie w oparciu o powiązane dane, to tak jakby tworzyć mikroserwis, ale wciąż w obrębie monolitu.

W rezultacie nie robię interfejsów pod infrastrukturę, maperów, adapterów itp. oddalam ten moment jak najdłużej się da bo w przypadku infra nie jestem wróżbitą, w zasadzie to trudno mi określić jak uproszczone powinno być wybrane api, skąd mam wiedzieć czy za miesiąc nie będę potrzebował jakiejś wyszukanej funkcji z wybranej bazy. Zrobię zbyt szerokie lub zbyt wąskie api, utrudniam sobie możliwe przejścia.

@znowutosamo: Mógłbyś nakreślić co jest złego w metodzie w stylu createAccount?