Aktywne Wpisy
Tortcebulowy +49
źródło: FB_IMG_1713073104021
Pobierz
WielkiNos +6
Wiedzieliście, że są ludzie wyrzucający książki na śmietnik? Bo ja nie wiedziałam. Dla mnie to niewyobrażalne.
#ksiazki #gdansk #bekazpodludzi
#ksiazki #gdansk #bekazpodludzi
źródło: temp_file6624736783794313526
Pobierz
1. Migracja monolitu do SOA.
W większości przypadków przynosi więcej szkody i niepotrzebnych kosztów niż utrzymanie solidnie zaimplementowanego monolitu. Zazwyczaj inicjowana na pewnym etapie życia produktu przez grupę doświadczonych inżynierów znudzonych codzienną pracą z monolitem i szukających wyzwań pozwalających im zdobyć nowe doświadczenie. Potrzeba tej zmiany jest argumentowana zazwyczaj lepszą w teorii skalowalnością systemu, łatwiejszym deploymentem i utrzymaniem wszystkich serwisów. W praktyce podobną skalowalność dużo łatwiej osiągalną przez dołożenie zasobów można uzyskać zostając przy monolicie. Zazwyczaj taka migracja dokłada tylko problemów z architekturą sieciową i integracją wszystkiego w jedną całość, dochodzi konieczność utrzymania brokera eventów i asynchronicznej komunikacji, etc. Przy braku odpowiednich nakładów świetnych inżynierów: zarówno programistów i devopsów firmy dokładają sobie tylko niepotrzebnego skomplikowania całości, nie wspominając o kosztach przepisania całości z monolitu na SOA co samo nie przekłada się na zysk firmy.
Z mojego doświadczenia w 99% przypadków dobrze napisany monolit, najlepiej napisany w podejściu: Loosely Coupled Monolith będzie o wiele korzystniejszym, prostszym i tańszym zarówno w implementacji jak i utrzymaniu rozwiązaniem.
Pokuszę się nawet o stwierdzenie, że przepisywanie monolitu na SOA w zasadzie nigdy nie może wyjść dobrze a pozwolić sobie na używanie tej architektury mogą sobie tylko wielcy gracze, dysponujący nieograniczonymi zasobami zarówno finansowymi jak i ludzkimi, pozwalającymi na napisanie a nie przepisanie wszystkiego od nowa przez wiele niezależnych teamów, każdy odpowiedzialnych tylko i wyłącznie za jeden serwis. Firma powinna również posaiadać dedykowany, doświadczony team devopsów to stworzenia i utrzymania architektury sieciowej dla SOA (niezależnie czy w cloudzie czy na serwerach dedykowanych)
2. Wdrażanie modnych rozwiązań na siłę - szlagierowy przykład to używanie GQL zamiast REST do API
Wdrażane z pobudek podobnych do migracji do SOA - chęć użycia i nauczenia się nowej technologii.
Problemy w zasadzie te same. W przypadku GQL jest to komplikowanie prostych rzeczy, problemy z optymalizacją zapytań i eliminacją problemu N+1, które w GQL rozwiązuje się w sposób nietrywialny jak ma to miejsce w api REST.
Często śmieję się z firm, które na siłę wrzucają GQL mając tylko jednego i to swojego klienta tego API, API które do tego nie zmienia się często. GQL ma w zasadzie sens tylko w projektach, które udostępniają różnorakie podzbiory API różnym klientom, co nie przeszkadza programistom wdrażać tego rozwiązania w prostych projektach tym samym robiąc klasyczny "strzał z potężnej armaty jaką jest GQL do muchy, jaką jest ich prosty w założeniach projekt"
3. Naiwne myślenie, że wytwarzanie oprogramowania skaluje się liniowo względem ilości inżynierów.
W przybliżeniu jest tak faktycznie do pewnego rozmiaru firmy. Słowem 2 programistów wykona pracę 2x szybciej niż 1, czy nawet 6 wykona ją 2x szybciej niż 3, ale od powiedzmy 5 programistów przestaje się to tak prosto skalować ponieważ dochodzi znacząca praca polegająca na po pierwsze podziale pracy między zespoły a po drugie komunikacji między nimi czy wreszcie po 3 scaleniu tej pracy. Najgorsze, że nawet doświadczeni managerowie czy tech-leadzi często zakładają że mając zespół 50 osób, dobiorą kolejne 50 osób i zrobią pracę 2x szybciej. Otóż często zrobią tę pracę nawet trochę wolniej.
#programowanie #pracbaza #pracait #it
Najlepsze to i tak w tym wszystkim jest to, że ZAWSZE i WSZĘDZIE leży podstawa tej roboty czyli komunikacja. Ciągłe dyskusje o SCRUM-ie, SAFE, Kanbanie, a zwyczajnie zero umiejętności rozmowy między biznesem, a IT. Tak jakby wrzucenie kompletnie zielonego
@wargi-sromowe-mniejsze: lol 200 programistow i po kilka releasow dziennie na monorepo. A smoki tam byly, bo brzmi jak jakas stajnia jednorozcow.
@Pit1337: 12 lat w branży, też mi się czasem odechciewa i się zastanawiam jak długo pociągnę. To co pomagało wcześniej i co mogę polecić, to między kwartałem a rokiem przerwy na lenistwo ew. jakieś prace fizyczne typu malowanie domu
Też czasami mam ochotę podbudowywać ego na mirko. Wiem jaki mechanizm psychologiczny za tym stoi. I cisnę bekę i pogardę do takich jak ty. Jest to niskie, i warto to kontrolować. A jeśli ktoś nie potrafi, oznacza to że wewnętrzne uniżone życiem ego jest silniejsze od siły charakteru.
Dwa, @damianooo8 ma trochę racji, to co napisałeś to przeintelektualizowane banały.