Over engineering lvl ultimate.

Tak trochę się żalę, trochę śmieję przez łzy. Trafiłem do nowego projektu, bo jak zwykle coś tam trzeba na kiedyś tam zrobić, bo klient chce, czeka i coś tam a projekt niby w Java. Aplikacja to typowy CRUD. Ile może trwać zadanie typu "obsłuż request, weź dane z bazy, zapakuj w zwrotkę i odeślij"? Zwykle chwila moment. Ale tutaj wchodzi do gry wybitna wręcz architektura tego cuda, na widok której barokowi mistrzowie architektury chlipaliby jak przedszkolaki w kątach zaprojektowanych przez siebie katedr.
Wygląda to tak:

• Jest warstwa w Javie. Nie robi prawie nic, poza tym, że istnieje, sprawdza jakieś tam uprawnienia i podobne pierdoły i oczywiście wystawia endpointy.
• Przyjętego requesta jakoś tam lekko modyfikuje i wywołuje synchronicznie serwis w Pythonie (P1)
• P1 pakuje to co dostał w wiadomość i umieszcza w kolejce
• Wiadomość z kolejki odbiera kolejny serwis z logiką biznesową, wywołuje sobie metodę wskazaną wprost w wiadomości
• Pakuje to co dostanie z monolitycznej bazy danych w kolejną wiadomość i wrzuca na kolejkę.
• Z kolejki wiadomość czekający na nią z utęsknieniem P1, szuka wiszącego requesta i likwiduje asynchroniczność
• Java dostaje response z P1 i nic z nim nie robiąc odsyła do klienta.

Żeby było śmieszniej, to Java (która nie robi nie...) jest napisana w technologii ogłoszonej 15 lat temu jako retired. Z jakiegoś nieznanego mi powodu baza danych jest "własnym silnikiem". No i żeby pozwolić na customizację tego cuda, na jakimś etapie stworzenia dołączono do tego jeszcze DSL'a do customizacji.

Niech zgadnę. Ludzie pracujący w tym projekcie uważają że "jest dobrze" i "nie ma co zmieniać"?

To nie wygląda mi jako świadomy overengineering, tylko bardziej jak nieukończona budowla. Były ambitne plany zbudowania np. wiaduktu, a postawione zostały tylko słupy. Ew. też dużo entropii i właśnie brak planu niż jakaś świadoma inżynieria. Może kilka programistów robiło i jeden znał Javę, drugi Pythona, a trzeci trochę tego, trochę tamtego i razem próbowali zrobić coś ambitnego, ale nie dogadali się i coś nie pykło.

Oczywiście gdybam, ale nie zdziwiłbym się, gdyby opisany w twoim poście flow był robiony bez żadnego planu, przez kilku ludzi w różnym czasie, którzy próbowali dodać swoją cząstkę do istniejącego burdelu. Ktoś zrobił serwis w Pythonie, bo nie znał Javy. Inny znał kolejki, to zrobił na kolejkach. Trzeci trafił do pracy przez przypadek, więc próbował nieudolnie to połączyć itp.

Ja byłem w projekcie, gdzie rozwiązaniem problemu jeden z serwisów nie wyrabia (faktycznie dużo processingu związanego z parsowaniem dużych i częstych eventów z zewnątrz) było dodanie kolejnego serwisu, który podmienia zwykłą synchroniczne wywołanie na message/czekanie na message przez MOM (czyli funkcjonalnie to samo). Nie wiem w jaki sposób miało to rozwiązać rzeczywisty problem, ale takie rzeczy się dzieją jak ktoś oderwany od ziemi wymyśla architekturę

Z ciekawosci - jaka to kolejka i jak mapuje oczekujace requesty w P1 z partycjami (albo czyms innym w zalenosci od uzytej kolejki) z wiadmoscia z serwisu z logika biznesowa?

Jest warstwa w Javie. Nie robi prawie nic, poza tym, że istnieje, sprawdza jakieś tam uprawnienia i podobne pierdoły i oczywiście wystawia endpointy.

Wygląda jak napoczęty i nigdy niedokończony strangler pattern. Jak stary jest kod Javy?

@LukeJL @kelog Tak, to wygląda na strangle pattern, tylko w wykonaniu anemicznego dusiciela. Owinąć ofiarę mu się udało, ale żeby coś udusić to już nie bardzo. Oczywiście, to że wygląda, nie oznacza, że faktycznie taki był zamysł. Mogło tak być, a być może jedynie próbujemy nadać temu sens i cel, których tam nigdy nie było.
Kawałek w Java jest aktywnie utrzymywany, czyli ktoś, kiedyś z jakiegoś nieznanego mi powodu podbił to całkiem świeżej wersji Java, Nie wiem po co i dlaczego przy okazji nie zrobiono tego nieco głębiej, bo to wciąż średniowieczne protokoły komunikacyjne na starożytnych fundamentach. Całość do zaorania i odtworzenia w tydzień.

Z drugiej strony, jak łatwo się domyślić, to nie jest oprogramowanie tworzone pod chmurę, multitenancy SaaS itd. Tylko instalowane na bare metal, no może VM. Tutaj też jest jakieś pudrowanie trupa i widać próby pakowania tego wszystkiego w kontenery. No i skoro to lata u iluś tam klientów, czyli realnie nie wiadomo kto gdzie i w jaki sposób z tego korzysta, jakie haki są zastosowane do integracji z resztą lokalnego otoczenia systemu, to zrobienie jakiejś grubszej zmiany jest ultra ryzykowne. Opis z pierwszego posta dotyczy jakiegoś tam wycinka systemu, którego reszta jest duża, zintegrowana na poziomie monolitycznej bazy danych.

Czy działa? Przynosi dochody? I jakie jest w sumie Twoje zadanie?

marian pazdzioch napisał(a):

Czy działa? Przynosi dochody? I jakie jest w sumie Twoje zadanie?

Czy wprowadzenie koniecznych zmian jest drogie? Czy dodawanie małego feature zajmuje dni zamiast minut/godzin? Czy błędy są kosztowne i trudne do naprawienia?

marian pazdzioch napisał(a):

Czy działa? Przynosi dochody? I jakie jest w sumie Twoje zadanie?

Działa (pojęcie względne), przynosi dochody, bo to nie jest tania rzecz, konkurencja nikła, a "gdzieś tam" za tymi wszystkimi warstwami, które opisuję jest kawałek dość unikalnej algorytmiki. Oczywiście mogłoby działać lepiej, w znaczeniu być szybsze, tańsze we wdrożeniu, wygodniejsze dla użytkowników końcowych, tańsze w rozwoju.
Moje zadanie - w sumie to ciężko powiedzieć. Niby mam tam dorobić parę prostych ficzerów (crud) i "przenieść to do chmury", co jest już zadaniem dość karkołomnym. Tak czy inaczej - zrobię swoje, pchać palców między drzwi nie zamierzam
Podejrzewam, że główny strumień przychodów to w tej chwili utrzymanie tego ulepa, bo architektura + liczba instancji powodują, że to zwyczajnie musi się walić jak króliki na wiosnę.
W mojej ocenie, w tej formie oprogramowanie jest prawie niesprzedawalne. Nie mam na myśli tego jak ono jest skonstruowane, tylko co jakie koszty obsługi generuje po stronie klienta.

Ja mam dużo wyrozumiałości dla technicznych niedostatków, wiem, że software ma dostarczać wartość użytkownikowi, a nie być pięknie napisany. Ale z drugiej strony, po co pisać coś źle, jeżeli można napisać dobrze? Po co zarabiać mało, skoro można dużo?

Życie rzadko wynajduje rewolucyjne rozwiązania albo zmienia wszystko od podstaw. W większości wypadków adaptuje to co jest - jak np. nerw błędny albo bierze coś co już działa (-> mitochondrium, chloroplasty). Póki co jeszcze nikt nie przebił tego w długowieczności.

Więc o co ci chodzi? Że rzeczywistość działa inaczej niż w szkole uczą? To powinno się już uświadomiać w wieku nastu lat.

Znam tego typu projekty. Autorzy najczęściej są przekonani o słuszności raz obranego podejścia i będą je powielać - IMO tutaj nie ma co ratować.

Jak spróbujesz to poprawiać - nie wiem, namawiać zespół by to uprościć, usunąć zbędne elementy - to w najlepszym razie pojawi się 100 niekoniecznie merytorycznych argumentów, dlaczego tak musi być, a w najgorszym Cię spałują, zbutują i przerobią na wycieraczkę.

Jedyna szansa, to że znajdzie się więcej ludzi, którym to nie pasuje, i będziecie mieć dość siły przebicia by na to wpłynąć.

@superdurszlak Niestety jestem już dostatecznie stary, żeby nie odczuwać potrzeby zmieniania niezmienialnego. W dodatku jestem w tym projekcie od machania łopatą, a nie martwienia się o jego stan, mam robić swoje, wiem do kiedy, szkoda mi czasu i nerwów na puste dyskusje nie prowadzące do niczego. Gdybym miał większą odpowiedzialność i zakres decyzyjny, to bym szukał sposobu na poprawienie tego projektu, ale że nie mam i nawet nie specjalnie się do tego rwę, a nawet nie wiem jakie były powody takich decyzji...

+--------------------+       +------------------+       +-------------------+
|   Klient (API)    | ----> |  Java (Gateway)  | ----> | Python Service P1 |
+--------------------+       +------------------+       +-------------------+
                                      |                           |
                                      |                           v
                                      |                 +-------------------+
                                      |                 |  Kolejka (MQ)     |
                                      |                 +-------------------+
                                      |                           |
                                      |                           v
                                      |                 +-------------------+
                                      |                 |  Python Service   |
                                      |                 | (Logika Biznesowa)|
                                      |                 +-------------------+
                                      |                           |
                                      |                           v
                                      |                 +-------------------+
                                      |                 |  Baza Danych       |
                                      |                 | (Custom Engine)    |
                                      |                 +-------------------+
                                      |                           |
                                      |                           v
                                      |                 +-------------------+
                                      |                 |  Kolejka (MQ)     |
                                      |                 +-------------------+
                                      |                           |
                                      |                           v
                                      |                 +-------------------+
                                      |                 |  Python Service P1 |
                                      |                 +-------------------+
                                      |                           |
                                      v                           v
                               +------------------+       +--------------------+
                               |  Java (Gateway)  | <---- |   Klient (API)    |
                               +------------------+       +--------------------+

@piotrpo dobrze to zrozumiałem czy inaczej, popraw mnie jak coś

W projektach transformacyjnych często dorzuca się pośrednie architektury, które mają ułatwić tranzycję do architektury docelowej. Interesująca byłaby historia, która doprowadziła do takiej sytuacji i jaki problem rozwiązywała. Który komponent jest najstarszy? Który najmłodszy?

@Mbappe_koksik Dobrze zrozumiałeś. Jakieś tam uwagi do diagramu można mieć, ale z grubsza to tak wygląda.
@yarel Jakieś powody pewnie były. Czy są jeszcze jakcyś weterani, którzy wiedzą jakie one były - wiątpię.

Custom DB engine?! To musiała być ciekawa historia, jak ktoś na to pozwolił 15 lat temu. OracleDB było za drogie? Postgres nie był cool?

ArchitektSpaghetti napisał(a):

Custom DB engine?! To musiała być ciekawa historia, jak ktoś na to pozwolił 15 lat temu. OracleDB było za drogie? Postgres nie był cool?

Ja tam nie jestem ciekawy takich historii. To trochę tak, jak kiedy widzisz parę bardzo grubych ludzi, którzy mają małe dziecko i z tyłu głowy pojawia się myśl, że to raczej nie było in-vitro.

Co Was dziwi custom db engine?
W firmach, ktore mają stare systemy i najczęściej też firmach produktowych logika na procedurach to klasyk, z którym nawet da się żyć bo masz jawnie informacje co się dzieje. Gorzej jak są jakieś inne cuda typu triggery poustawiane. Albo coś się gdzieś indziej samo wykonuje a nie z backendu.

Wręcz jestem zdania, że im gorzej napisane procedury (od góry do dołu) są lepsze niż te które ktoś próbował pisać w stylu clean code'a, bo łatwiej się to przepisuje i większa szansa, że nie wywalisz czegoś w kosmos.

@froziu Tu nie chodzi o jakiegoś PSQL, który coś robi w Oracle, tylko napisanie własnego Oracle.

froziu napisał(a):

Wręcz jestem zdania, że im gorzej napisane procedury (od góry do dołu) są lepsze niż te które ktoś próbował pisać w stylu clean code'a, bo łatwiej się to przepisuje i większa szansa, że nie wywalisz czegoś w kosmos.

No tak, kiedyś znaleźliśmy 3 procedury robiące dokładnie to samo, ale każda trochę inaczej. W efekcie mieliśmy niezły cyrk w BD, a ustalanie co jest grane w systemie pełnym magicznych numerków zamiast informacji, a ludzie którzy znali system w większości zostali zwolnieni - to jest dopiero jazda.