Modularyzacja w dobie mikroserwisów

Jak chcesz pisać moduł który jest prostą wyszukiwarką na 4 czy tam 5 warstwach bo na tyle się umówiliście w projekcie działającą na zasadzie, przyjmij zapytanie, wyślij request do Elastic Searcha czy jakiegoś Azure Search i zwróć wynik to sobie rób. Nikt ci nie broni robić każdego modułu od linijki dla zasady. Ja sobie go napiszę na tylu warstwach ile będzie wymagane. Zapewne dwie będą wystarczające.

Potem trzeba się brandzlować z niepotrzebnymi warstwami, mapperami, abstrakcjami, żeby wykonać prostą operację request-response albo wrzuć komendę/zdarzenie na kolejkę.

proximus-prime napisał(a):

W web-dev masz zawsze do czynienia z banalnym flow'em: zaczyna sie od request'u, konczy sie na response'ie.

Tylko jeśli robisz front pod crudy, i ten front nie ma w sobie żadnej logiki.

Inaczej byłoby w sytuacji gdybyś robił np Edytor 3D online, albo np taki program jak Google Docs albo Google Slides.

proximus-prime napisał(a):

Trzymanie sie zasad przyjetych na poczatku jest kluczem.

Mało Agile'owej podejście.

To jaka jest jakosc tych zasad to juz loteria i odpowiedzialnosc spada na tego ktory je ustalil i innego ktory zatwierdzil te ustalenia. Produkt jest dla tego kto za niego placi, a nie dla dania mozliwosci rozwoju kazdemu "geniuszowi" ktory pojawia sie w miedzyczsie w projekcie.

Tak, produkt jest dla tego kto za niego płaci; ale utrzymanie go w stanie zdolnym do zmian jest kluczem żeby produkt był utrzymywalnym.

proximus-prime napisał(a):

Wystawiasz klientowi faktury wiec dostarcz mu taki kod jaki od Ciebie wymaga. Czytelny, jednolity, rozszerzalny, latwy w utrzymaniu i do ewentualnego przepisania.

Klient nie wymaga zadnego kodu od Ciebie - wymaga działającego produktu; to w jaki sposób osiągniesz ten kod, to kwestia programisty.

proximus-prime napisał(a):

Naduzywania coraz bardziej zawilej terminologii (ktora i tak za 5-10 lat nikt sie nie bedzie przejmowal) i robienie z tego dev'o woo-doo to jest najwiekszy kant w branzy IT.

Pełna zgoda. Za to mógłbym dać +2 (jakby się dało).

@markone_dev: Może powinienem tylko podpowiedzieć, że nawet w takiej "wertykalnej" strukturze, gdzie dzielisz aplikację na takie kawałki, z których każda ma "swoją" persystencję, kontrollery i inne rzeczy - to nadal to nie wyklucza podejścia o którym mówili przedmówcy - można zastosować zarówno podzielenie horyzontalne jak i wertykalne na raz, i nic złego w tym nie ma. Więc to nie jest tak że musisz wybrać albo albo.

@Riddle:

Mało Agile'owej podejście.

No i co z tego? Agile sluzy wylacznie radzeniu sobie z brakiem wiedzy/kompetencji klienta zamawiajacego produkt. Jest doskonalym uzasadniem metodyki pracy wykonawcy IT ktory wbrew wlasnemu PR'owi tej wiedzy rowniez albo nie ma, albo nie chce przekazac. To jest kolejny kant w sektorze IT. Wyobrazasz sobie budowlanca ktory buduje Ci chalupe Agile'owo?

@Riddle:

Klient nie wymaga zadnego kodu od Ciebie

Czepiasz sie slowek, ale zawsze jako programista na haslo produkt bedziesz mial swoj kod przed oczami czyli if'y i for'y za ktory wystawiasz fakture.

proximus-prime napisał(a):

@Riddle:

Mało Agile'owej podejście.

No i co z tego? Agile sluzy wylacznie radzeniu sobie z brakiem wiedzy/kompetencji klienta zamawiajacego produkt. Jest doskonalym uzasadniem metodyki pracy wykonawcy IT ktory wbrew wlasnemu PR'owi tej wiedzy rowniez albo nie ma, albo nie chce przekazac.

Nadal zasadne, bo jeśli cokolwiek jest pewne w IT to właśnie ciągły brak kompetencji klientów, więc takie podejście które radzi sobie z tym jest absolutnie konieczne.

@Riddle:

Klient nie wymaga zadnego kodu od Ciebie

Czepiasz sie slowek, ale zawsze jako programista na haslo produkt bedziesz mial swoj kod przed oczami czyli if'y i for'y za ktory wystawiasz fakture.

Nooo, właśnie nie.

Czasem możesz dostarczyć produkt bez kodowania, jeśli to czego klient potrzebuje tego nie wymaga.

@Riddle:

Nadal zasadne, bo jeśli cokolwiek jest pewne w IT to właśnie ciągły brak kompetencji klientów, więc takie podejście które radzi sobie z tym jest absolutnie konieczne.

I w perfidny sposob absolutnie nagminnie wykorzystwane przez niekompetentne IT. Pasuje Ci to bo to nie Ty placisz faktury. Tak jak pisalem wczesniej, przejdz "na druga strone", wez budowlanca i zbuduj sobie sobie Agile'owo chalupe.

@Riddle:

Nooo, właśnie nie.
Czasem możesz dostarczyć produkt bez kodowania, jeśli to czego klient potrzebuje tego nie wymaga.

Nie wiem w jakiej branzy robisz, ale w mojej produkuje sie kod (no chyba ze masz w zakresie obowiazkow rowniez wypiekanie kajzerek). To w jaki sposob klient to nazywa, widzi lub wykorzystuje efekty dzialania to jest jego sprawa. Takie mamy czasy ze co chwile pojawia sie jakas dysforia.

proximus-prime napisał(a):

@Riddle:

Nadal zasadne, bo jeśli cokolwiek jest pewne w IT to właśnie ciągły brak kompetencji klientów, więc takie podejście które radzi sobie z tym jest absolutnie konieczne.

I w perfidny sposob absolutnie nagminnie wykorzystwane przez niekompetentne IT. Pasuje Ci to bo to nie Ty placisz faktury. Tak jak pisalem wczesniej, przejdz "na druga strone", wez budowlanca i zbuduj sobie sobie Agile'owo chalupe.

Porównywanie wytwarzania oprogramowania do budowania domów jest niepoważne.

proximus-prime napisał(a):

@Riddle:

Nooo, właśnie nie.
Czasem możesz dostarczyć produkt bez kodowania, jeśli to czego klient potrzebuje tego nie wymaga.

Nie wiem w jakiej branzy robisz, ale w mojej produkuje sie kod (no chyba ze masz w zakresie obowiazkow rowniez wypiekanie kajzerek). To w jaki sposob klient to nazywa, widzi lub wykorzystuje efekty dzialania to jest jego sprawa. Takie mamy czasy ze co chwile pojawia sie jakas dysforia.

@proximus-prime: to zależy od tego co się robi, w jakiej fazie jest produkt i jakie są oczekiwania oraz możliwości. Dosyć często udaje mi się ubić pomysły które wołają o pomstę do nieba i rozwiązać problem tam gdzie rzeczywiście trzeba nie kodując ani jednej linii, bo np problem nie jest powiązany z produktem ale procesami biznesowymi na które jeszcze da się wpłynąć. No i każdy jest chyba wtedy zadowolony. Może poza managementem który musi się w tym momencie wziąć do roboty.