BNF odc. 21 Ten o wzorcach i dobrych praktykach

No dobra, no to jak już jesteśmy rozgrzani, to chcieliśmy sobie porozmawiać o tych wzorcach, o tych dobrych praktykach i odczarować niektóre albo zaczarować w związku z tym. I właśnie, no mamy tych wzorców, mamy dobrych praktyk ostatnio bardzo dużo, tak naprawdę wysyp mam wrażenie w ostatnich latach. Bo kiedyś jak sobie programowaliśmy na froncie, w webie, to na froncie nie programujemy absolutnie, tak nisko się nie będziemy pochylać, ale właśnie. Ale kiedyś mieliśmy MVC, nie? I MVC nam wystarczało, a nagle się zaczęło pojawiać Clean Architecture, Repository, jeszcze jakieś inne stwory.

Więc tyle, jeżeli chodzi o repozytorium. No i wiesz, rzeczywiście te dyskusje na temat, co jest dobre, co nie jest dobre. Ja ostatnio na przykład na Twitterze widzę, że nowy trend jest, że polegający na tym, że clean architecture jest złe. Ale to nie chodzi o to, że to, co wymyśliliśmy, to jest złe, tylko bardziej chodzi o to, że ludzie zdają sobie sprawę, że dobra, to my mamy te warstwy. Te warstwy muszą mapować swoje obiekty z jednej na drugą. Wiadomo, musi być to strzykiwanie zależności. Potem ktoś zadaje sobie pytanie, zaraz, jeżeli mam te warstwy i jest te mapowanie, powiedzmy z tego obiektu właśnie, na przykład tego obiektu, co wysłałeś do Aspen. Client wysłał z jakimś JSON-ikiem Aspen. Core'a, trafia to tam albo do minimalnej aplikacji, albo do kontrolera trafia ten właśnie zrealizowany sobie obiekcik, no to później ten obiekcik DTO sobie mapujesz na obiekt domenowy i teraz też rodzi się pytanie, czy domen domenowy później na przykład nie mapujesz na coś, żeby jeszcze warstwa dostępu do danych nie była na przykład

A wiadomo, jeszcze jest Cezary Piątek zrobił jakiś tam swój dodatek do Visual Studio, który chyba automatycznie generuje taki kod mapujący. A ja w swojej karierze wiesz co, nawet kiedyś nie wiedziałem, że w ogóle takie coś jak automapry istnieje. To pamiętam, że w refleksji napisałem właśnie taką metodę, że jeżeli te pole ma taki typ i nazywa się tak samo, no to przyrównaj. I to oczywiście tylko moja refleksja była prymitywnie napisana. Jeżeli typ był bardziej zagnieżdżony, to oczywiście to nie działało, ale pamiętam, że to mi usprawniało właśnie pisanie Jak widzisz, jak ludzie tak dyskutują, nie tak, że nikt nie ma racji, tylko każdy ma jakąś swoją wizję albo swoje cele. Jeden chce, żeby ten kod był luźno powiązany, dlatego ta cebula, clean architecture, te mapowania i tak dalej i tak dalej, a innego interesuje po prostu, żeby kod szybko działał, a jak ma szybko działać, no to nie będę mapował obiektów i będą one podróżować nie wiadomo po co, bo to na przykład nie jest moim celem.

Więc warto sobie, wiesz, takie drivery albo zastanowić się, czym się kierujemy. Czy ja chcę, żeby kod był luźno powiązany? Czy chcę, żeby kod działał szybko? Co ja właściwie chcę osiągnąć? Co jest dla mnie na przykład najważniejszym priorytetem? I tak dalej, i tak dalej. Jeśli chodzi o clean architecture, to też widzę, że ludzie nie tak, że mówią, że clean architecture jest złe, tylko chodzi o to, że to jest tak obszerne pojęcie, że jedni mogą je zrozumieć inaczej, inni mogą zrozumieć jeszcze inaczej. Ja na przykład rozumiałem, że Clean Architecture to jest troszeczkę wydzielone, mamy foldery, ale ktoś może zrozumieć, że Clean Architecture to po prostu są te warstwy, że jest ta warstwa właśnie UI, potem jest warstwa Application Core, czyli ta warstwa domenowa, a potem masz warstwę infrastruktury, tam zapewne siedzi baza danych, być może odpytywanie jakiegoś innego serwisu i tak dalej, i tak dalej.

To oczywiście reprezentacje jak dodawanie rekordu wygląda po stronie klienta. Potem jak dodawanie rekordu być może wygląda jako jakiś obieg domenowy. Później mam np. quera, bo comment, czyli te cqrs i to wszystko. Potem może jakaś metoda, która dodaje mi ten właśnie rekord. I to wszystko wiadomo siedzi w jednym folderze, w jakimś jednym projekcie, że jak chcesz konkretnie tę jedną rzecz zmienić, to wiesz, gdzie to szukać, a nie tak, że to jest porozsypane, że to jest w tym projekcie, to jest w tamtym projekcie. I tak właśnie, tak słyszałem, że Clean Architecture jest złe, Vertical Slices to jest jakby następna ewolucja tego, a tak naprawdę te dwie definicje same siebie nie wykluczają, tylko po prostu ktoś źle zrozumiał Clean Architecture, bo dla mnie jest na przykład oczywiste, że ty chcesz łatwiej znaleźć dany feature w kodzie.

A nie tak, że po prostu masz gigantyczne projekty i ty się potem gubisz, bo one tylko reprezentujesz jakąś warstwę całościową, bo można przecież te projekty sobie też powydzielać i potem znajdywać i nawet połączyć i można powiedzieć, że oba rozwiązania, że masz i podzielone i na warstwy i masz ten vertical slices, żebyś mógł tak odnaleźć się, ale to wiesz, to są akurat takie Ciekawe dyskusja, a tak naprawdę chodzi o to po prostu, jak poukładać te foldery, projekty, nawet w C Sharpie, żeby potem wiedzieć, że jak chcesz coś zmienić, to gdzie to dokładnie jest, żeby to tak długo mi to nie zajmowało. Więc jak widzisz, takie ciekawe zgrzyty, że Clean Architecture niektórzy są bardzo z tym zżyci. Jak ktoś powie, że to jest złe, a potem się dowie, że o co go nie chodzi, o te Vertical Slices, ktoś powie, zaraz, to ja tak troszeczkę robię, więc to tak trochę nie wiem, o co jest w ogóle ta cała dyskusja.

No dobra, to my tutaj robimy w projekcie Vertical Slices i czy ty pracowałeś w Vertical Slices? Nie, ja robiłem tylko Anian Architecture. O nie, no to nie, to chyba się nie dogadamy. No i to są takie mam wrażenie czasami bzdurne rozmowy. Natomiast z drugiej strony to też chyba moim zdaniem dobrze jest nauczyć się Kajetan Duszyński. Łatwiej nam zamokować jakieś dependencji, łatwiej nam w związku z tym testować, ale jeżeli zapomnimy o testowaniu, bo umówmy się, nie we wszystkich projektach jest tak różowo, jakbyśmy tego chcieli, no to to też jest tak, że mówimy, że tworzymy interfejsy ze względu na to, że kiedyś jakbyśmy coś podmieniali, no to od razu mamy ten interfejs wystawiony i nic więcej nam się nie zmienia, tylko implementację musimy zmienić.

Ok, w większości przypadków to się nigdy nie wydarzy, bo tak jak mówisz, to się może wydarzyć na webinarze, jak nagle wpadniesz na genialny pomysł, że właściwie coś innego mógłbyś zrobić, ale w takim realnym projekcie szansa jest mała. Natomiast jak się uczymy i ostatnio widziałem takiego fajnego mema, jaki jest moment rozwoju programisty, jak wchodzi i wie, że ma napisać po prostu funkcję, ma napisać metodę, która ma działać. Potem przechodzi na poziom mida i poznaje te wszystkie interfejsy, te wszystkie clean architecture, DDD, no nie wiadomo co i po prostu wszystko i wie, że nagle chce tego wszystkiego używać w każdym projekcie, po czym idzie na seniora i znowu po prostu pisze tą funkcję, żeby to po prostu jak najszybciej zadziałało i żeby to wypchnąć na proda.

No taka jest trochę prawda. Więc mam dziwne wrażenie, że czasami Zbyt bardzo się skupiamy na tym, żeby coś konkretnie nazwać, a za mało się skupiamy znowu niestety na rozwiązywaniu problemów, bo na tym tak naprawdę powinniśmy się skupić. I czy sobie to nazwiemy Vertical Slice, czy nazwiemy sobie to Onion Architecture, to ostatecznie chyba kończymy z tym samym projektem i z tym samym rozwiązaniem, ewentualnie troszeczkę inaczej napisanym. Natomiast jest to jedno i drugie rozwiązanie, czy jak ktoś robił Onion Architecture i tworzył projekty, czy tworzył foldery, czy cokolwiek, to jak wejdzie sobie do Vertical Slices, to też sobie zobaczy, że właściwie OK, robisz dokładnie to samo, tylko w jednym pliku.

No to dobra, to myślę, że jestem w stanie sobie z tym jakoś poradzić. Ale właśnie, ale to tak jak myślimy o architekturze, tą architekturę wiemy albo myślę, że możemy się zgodzić z tym, że trochę rozdmuchaliśmy, być może trochę niepotrzebnie, ale ważne jest, żeby rozwiązywać problemy, rozwiązywać się szybko, a to jak będziemy sobie to nazywać, to jest zupełnie inna sprawa. Kiedy rozmawialiśmy przed naszą rozmową i dyskutowaliśmy, o czym dzisiaj porozmawiamy, wrzuciłeś jedną rzecz, która mnie ciekawi. Bardzo mnie ciekawi właśnie, jakie masz do tego podejście, to znaczy dziedziczenie.

Created Daytime i Created By. I właściwie tyle. I na tym się kończy dziedziczenie w dzisiejszych czasach. Także też warto pamiętać, szczególnie tym bardziej, że mój podcast jest chyba najczęściej słuchany przez młodszych programistów, że to nie jest tak, że uczymy się czegoś i ktoś kiedyś powiedział, Zwykle jest to jakiś Uncle Bob czy ktoś tam, że coś tam jest święte i musimy o tym zawsze pamiętać, bo czasy się zmieniają. Uncle Bob też zmienia zdanie, o czym też chciałbym chwilę porozmawiać. No właśnie i trzeba zawsze pamiętać. Natomiast zarówno jeśli chodzi o repozytorium, jeśli chodzi o Clean Architecture czy dziedziczenie, myślę, że warto się tego uczyć i warto się z tym zapoznać ze względu na to, że

Więc tak powiedzmy, jakby miałem skrócić, jakie są zalety tych mikroserwisów, jak zrobić te mikroserwisy dobrze, to tak by to wyglądało. A jak to oczywiście tak nie zrobisz, no to w rezultacie masz po prostu monolit, tylko ukryty pod nazwą mikroservice, stąd te potem są problemy. No i stąd też właśnie nazwisko się zmieniło, bo jak monolit był tym złym, że jest fatalny, a potem pomyślisz sobie, zaraz, przecież monolit można także podzielić na moduły, co nie? Na jakieś małe części, dependency injection, właśnie te mapowanie, no w sensie w Clean Architecture to łatwo to moim zdaniem widać, te vertica sites, co tak mówiliśmy nawet na samym początku. I w rezultacie właśnie masz modularny monolit, tylko dlaczego musimy to nazywać modularny monolit, a nie monolity? No, bo słowo monolit źle brzmi do tego stopnia, że musimy wymyślić nowe słowo, które mówi, że to jest jakby monolit plus, co nie?

Szybkiego reagowania na zmieniające się wymagania i to wszystko. Dobra. Cezary, dziękuję Ci bardzo, bo faktycznie myślę, że jakbyśmy chcieli, to moglibyśmy jeszcze gadać tutaj kolejną godzinę, ale fajnie, że udało nam się tutaj, mam wrażenie, trochę odczarować niektóre tematy, trochę sprowadzić co po niektóre rzeczy na ziemię, żebyśmy pamiętali, że gdzieś tam u podstaw jest to, żeby tworzyć dobre oprogramowanie, a niekoniecznie to Nazywać, bo tak samo jak powiedzieliśmy o Clean Architecture, że w zależności czy zrobimy Onion, czy zrobimy Vertical Slices, przepraszam, to i tak będzie Clean Architecture.