Видео

Mógłbyś bardziej rozwinąć co masz na myśli? Czego byś potrzebował?

@@adambanaszkiewicz 14:54 metoda _addToCart_ korzysta ze zmiennej _repository_. _repository_ jak i kiedy zainicjowane, jak przekazane do _addTo_Cart_ tak żeby odpowiadało konkretnej instancji _MysqlCartRepository_ ? Na niewtajemniczonym w Clean Architecture robi to spore wrażenie ;)

Teraz rozumiem. Wszystko zależy od języka i frameworka w którym piszesz. W większości będzie to wyglądało tak samo, czyli definiujesz serwis z nazwą interfejsu, ale z instancją klasy. Symfony zrobi to w sumie za nas gdy zrobimy autowire i gdy jest tylko jedna implementacja interfejsu. Nie chciałem dodawać zbyt dużo szczegółów do repozytorium by go nie "rozwodnić" zbytnio. Napisz do mnie na LinkedIn albo na FB, pociągniemy temat dalej jeśli jesteś zainteresowany :)

@@adambanaszkiewicz Dzięki za odpowiedź. Roztrząsanie tego wątku w rzeczy samej zaciemniłoby jasność przekazu w materiale.

Masz rację... "powinno" :)

Praca z AI nie zawsze jest możliwa - to zależy od projektu i ilości kodu. I tak, nie ma efektu skali w pracy po godzinach. Z drugiej strony, gdy jednocześnie myślisz o skali projektu i rozwiązaniu problemu, najzwyczajniej jedno z tych dwóch zostanie zrobione po łebkach.

W przypadku "package by feature" musisz sprostać jednemu wyzwaniu - w module z 30 features'ami, gdy część z nich używa tego samego kodu współdzieląc go, musisz znaleźć złoty środek na to by go nie duplikować, a mimo wszystko nadal trzymać wszystko podzielone per feature. Zgadzam się z tym, że przy dodawaniu feature musisz dotykać każdą z warstw, ale zwróć uwagę, że w warstwach UserInterface i Application jest w 90% to samo (kontroler i UseCase wyglądają bliźniaczo) więc robi się je w 15 minut. Reszta to domena i infrastruktura. Gdy masz wszystko w jednym katalogu możesz nieumyślnie zacząć mieszać odpowiedzialności klas przez co zacznie się robić chaos. Podział na cztery warstwy sprawdza się dobrze w nietrywialnych modułach (nie-CRUDach), ponieważ pozwala oddzielić odpowiedzialność za poszczególne rzeczy na poziomie folderów w projekcie. Projektowałem kilka systemów, które posiadały w wybranych modułach takie podziały i spisywało się idealnie. Warto jednak podchodzić do takiego podziału racjonalnie - jak do wszystkiego. To nie jest rozwiązanie uniwersalne, nie wszędzie będzie pasowało - nie ma rzeczy uniwersalnych. Być może zdarzą się przypadku, że nie będzie to miało sensu. Natomiast, wiedza o tych czterech warstwach, o ich odpowiedzialności, pozwala lepiej organizować klasy i relacje między nimi. Możesz nie mieć struktury czterech warstw w strukturze projektu, a mimo to nadal posiadać ten podział na poziomie klas - dzięki CQRS właśnie. Dodatkowo taki podział wspiera różnego rodzaju testy (jednostkowe, funkcjonalne, integracyjne) osobno na każdej z tych warstw. O tym będę robił osobny odcinek.

Dziękuję, cieszę się że weszło :D Co do nazywania to siedzi mi z tyłu głowy osobny materiał "Czemu nie umiemy nazywać?" - Keep in touch :D

A możesz powiedzieć gdzie dostałeś zaproszenie? :) Jeśli na YT to przez proponowane filmy przez algorytm :)

Wszystko w ramach recjonalnego pożytku. Nie wszystkim siedzenie po godzinach będzie się opłacało, zgadam sie. Jest to rozwiązanie raczej dla osób które nie mają innej możliwości a chcą się rozwijać.

@@adambanaszkiewicz ale to już nie ma sensu... Oczywiście tak było i w takim kontekście miało to rację bytu, ale... już nie ma :) Czy zaszkodzi? Pewnie nie, ale to już para w gwizdek, czyli strata czasu.

Jakoś trzeba odreagować gdy coś nie idzie po naszej myśli :D

Muszę się zgodzić, niestety to nie wpłynie bezpośrednio od razu na kwestie finansowe. Jest to kwestia rozwoju osobistego gdy nie mamy innej opcji w firmie a chcemy się rozwijać. Kwestie finansowe najszybciej wyjdą gdy zmienimy pracę, ale gdy można zmienić pracę to w tedy nie trzeba ogarniać projektu po godzinach bo rozwój jest w nowym projekcie :)

Milo to słyszeć :) Z motywacja jest chyba ten problem, że traktujesz to jako drugą pracę :) Z mojej perspektywy to była frajda robienia czegoś innego niż w pracy, i pewna odskocznia od codziennego klepania kodu w legacy. Po wakacjach nawet tęskniłem aż wrócę do tego małego projektu bo tam robiłem to co lubię :)

@@morelia9718 Gitara po pracy sprawdza się idealnie :)

Szacun za podejście. Jeśli ktoś jest w stanie zmienić pracę bo się nie rozwija to zdecydowanie najlepsza opcja :)

Wszystko z głową, masz rację. Nie namawiam do siedzenia po 10 godzin bo to tortury są :D Jeden rabin powie tak, drugi inaczej. Rozumiem Twój punkt widzenia i zdaje sobie sprawę że są takie zakamarki IT gdzie wiedza szybko się dezaktualizuje. Jeśli jednak dana osoba nie może się rozwijać w inny sposób to jest to jedyna opcja by liznąć czegoś nowego. Ale, wszystko w granicach zdrowego rozsądku, na tyle ile komuś pasuje :)

@@adambanaszkiewicz myślę, że jeśli na przykład dana technologia kończy cykl życia i musimy się przesiąść na coś nowego to będzie dobrze posiedziec nad jakimś projektem, natomiast i tak z reguły firmy chcą brać kogoś kto już w pracy to robił. Ale dla samego doskonalenia umiejętności uważam to za przesadę. A już szczególnie w tym momencie, gdy rynek tak siada, że może się okazać że za parę lat będziemy zarabiać dwie średnie krajowe. Wtedy szkoda pleców i dupy na takie wyniki. Nie neguje mimo wszystko rozwoju, ale nie powinno być normalnością siedzenie rok po roku nad prywatnymi projektami żeby zostać na rynku pracy. To jest patologia. Lekarze może dużo pracują, ale chyba nikt nie wierzy, że czytają po godzinach Lancet. Raczej robią dwa etaty.

Akurat z mechanikiem nie trafiłeś, bo większość ludzi z tego fachu klepie graty w wolnym czasie. Głównie dla przyjemności, nie dla rozwoju, ale na pewno przy okazji się czegoś uczą.

@@tomek3880 no jak dla przyjemności, to inna sprawa. Ja mówiłem o robocie dla rozwoju, z etosu pracy i obowiązku.

Jesteś Włochem, że aż tak bardzo lubisz spagetti? :D

@@adambanaszkiewicz nie. Jestem ze śląska więc lubie burdel i patologie :D xD

Sobótka na VHS... Nie sądziłem że on aż tak wiekowy jest :D Może nie od Sobótki tylko generalnie temat zaczął być popularny w firmie a gdy nadarzyła się okazja to skorzystaliśmy :)

Pogratulować współpracy :) Wilk syty i owca cała :)

💪💪💪

Najpierw musimy zdefiniować kto z kim rozmawia, potem co jeden potrzebuje od drugiego, a na końcu w jaki sposób to zaimplementować. OHS jest właśnie tą implementacją. Zwroty potrzebują informacji z Zamówień o tym czy dane zamówienie które klient chce anulować w ogóle istnieje w systemie. OHS jest tutaj właśnie pewnym API, udostępnianym na zewnątrz przez Zamówienia. Czyli to Zamówienia pozwalają innym pytać o dane. Dlatego Zamówienia są niżej, a Zwroty powyżej - bo to Zwroty pytają się Zamówień o dane. Mapa kontekstów z nagrania jest moją interpretacją. Zwroty są wyżej niż Zamówienia ponieważ relacja jest właśnie w tę stronę. Wiele źródeł OHS mówi o tym, że do OHS jest "hostem" lub "suplierem" a wszystko co używa tego OHS jest "comsumerem". Mimo to dla mnie ważna była relacja na diagramie.

@@adambanaszkiewicz Dzięki za wyjaśnienie :)

Bardzo dobre, nietrywialne pytanie :) Najpierw zadałbym pytanie, czy obsługa optimistic lockingu jest biznesowa czy techniczna. Jeśli techniczna, to nie przejmowałbym się tym w implementacjach InMemory. To mają być proste implementacje, implementujące interfejs. Sam OL można przetestować na co najmniej dwa różne sposoby, i tego bym się trzymał. InMemory bez $version, a integracyjnie przetestować czy dane repo poprawnie obsługuje wersjonowanie. Natomiast gdy OL jest biznesowy, to warto w tedy to bardziej uwydatnić, ale już nie tylko przez $version w encji, ale przez interfejs Repozytorium, rzucane wyjątki, ich obsługę, ewentualnie jeśli potrzeba to nawet nazwy metod. W tedy powinieneś przetestować OL jako część Twojego kontraktu. Tutaj wchodzimy na grząski grunt, nie mając wiedzy biznesowej więc na tym się zatrzymam :D Pytanie ma o wiele więcej niuansów, zakładam, że mogę nie wiedzieć czegoś co mogłoby wpłynąć na moją odpowiedź, więc poproszę byś nie traktował tego jako wyroczni, jeśli popełniłem błąd przez niewiedzę o Twoim przypadku :)

​@@adambanaszkiewicz Nie mnie oceniać czy popełniłeś błąd czy nie :D Dzięki! Załapałem Twój sposób myślenia, mam nadzieję :) Biznesowe rzeczy - unitowo i wtedy OL tak; Technicznie - proste testy integracyjne dla OL Czy do transakcji i innych podobnych rzeczy też podchodzimy tak samo? Jeśli w kodzie jest startTransaction(); commit() i rollback()

Transakcje są częścią warstwy Aplikacji (jestem swoją drogą w trakcie pisania tego odcinka :D ). Ta warstwa raczej średnio nadaje się do testowania jednostkowego - bardziej Funkcjonalnie lub nawet Integracyjnie z racji jej przeznaczenia. Testy jednostkowe nie powinny dotykać kodu, który dotyka infrastruktury, a transakcje są właśnie częścią infrastruktury, ale używane są w warstwie Aplikacji bo to ona odpowiada za orkiestrację całego procesu biznesowego i decydowanie co zrobić gdy coś wewnątrz transakcji zawiedzie. Na pewno będę o tym temacie mówił obszernie w odcinku o warstwie Aplikacji. Poproszę o troszkę cierpliwości, i jeśli po obejrzeniu odcinka nadal będziesz miał pytania to w tedy wal śmiało :) Nie chciałbym zwyczajnie pisać tutaj litanii tekstu, skoro o wiele łatwiej i przyjemniej będzie zapoznać się z materiałem video :)

Problemem jest "dodatkowo w serwisach jawnie korzystamy z transakcji". Wycieka wam infra.

@@mleczakm Warstwa aplikacji wie o infrastrukturę. A jeśli potrzebujesz się jej jakkolwiek pozbyć, to możesz spróbować zrobić abstrakcje na transakcję bazodanowa. W jednej z aplikacji tak zrobiliśmy, nazywaliśmy to Operacją Atomową. Pod spodem była zwykła transakcja.

Clean i Hexagonal nie narzucają struktury projektu, a tylko reguły którymi mamy podążać w kodzie :) Tak samo DDD i MVC to też reguły. Od każdej reguły można odejść lub ją złamać jeśli jest ku temu racjonalny powód. Ja sugeruję takie a nie inne struktury w filmach, ponieważ z mojej perspektywy są one najpopularniejsze, przy używaniu DDD i MVC, ale nie oznacza to, że są jedyne albo prawidłowe w każdym możliwym przypadku :) Widziałem różne struktury dla DDD, i w większości przypadków po poznaniu powodów dla których podjęta była taka decyzja miało to sens :)

Miałem styczność z czymś takim i ciężko to niestety przeskoczyć. Każdy z nas jest inny - jedni chcą się rozwijać i uczyć, innych zadowala to co mają. Jeśli chcesz to napisz do mnie na LinkedIn, podrzucę Ci trochę info jak można spróbować rozruszać zastygłe tryby w firmie :) Pamiętaj, że to tylko sugestie, i nie w każdej sytuacji mogą zadziałać, to zależy od człowieka z którym masz styczność :)

kurde, ja siedze w aplikacji 13sto letniej, napisanej w zend 1 oraz laminas :D i mimo to, że to tak potężne legacy to w każdym module nowy kod wyciągamy jak tylko się da do warstw właśnie :) aplikacja, domena, infra - jedynie kontrolery trzymamy w starym miejscu :) Podział kontextów jest ubogi, bo bazujemy na modułach wydzielonych przez rzeczowniki (czyli moduł = tabelka w bazie :) ) a nie wydzielonych na zachowaniach. No ale tak czy siak, bez bounded contextów nowy kod i ląduje z pdziałem na warstwy, które są pisane w 100% w oderwaniu od frameworka, czyste php :) Da się, tylko trzeba chiceć :)

@@DanielŚmigiela Jak są ludzie którzy chcą coś zmienić to jest więcej niż pół sukcesu :)

Masz rację 😎 Używałem tego zamiennie w celach czysto skrótowych, by nie wydłużać filmu, by nie wchodzić w rozważania czym jest BC a czym moduł, bo film musiałby być dwa razy dłuższy 😄

Mass rację, tak to powinno wyglądać :) Będę o tym opowiadał w kolejnych częściach dotyczących właśnie warstw Aplikacji i UserInterface/Presentation. Skupiam się po kolei na każdej z warstw, żeby film był kompletny ale nie zbyt obszerny.

@@adambanaszkiewicz ok 👍 w takim razie wybiegłem trochę wprzód 😄 Powodzenia w tworzeniu kanału! 👍

T. Hanks :)

Czuję się zaszczycony :) Postaram się by jakość pozostała na tym samym poziomie w kolejnych częściach :)

Ah, z tą nazwą to masz racje. Nie pomyślałem by ją zmienić. Za bardzo skupiłem się na wydzieleniu odpowiedzialności :)

Możesz lookać :) github.com/adambanaszkiewicz/four-layers-of-application-example

Mam w planach odcinek poświęcony wszystkim rodzajom dublerów testowych :) Tutaj chciałem się skupić tylko na problemie mocków i jak je zastąpić :)

Jest szmoc!

Bardzo dobre spostrzeżenia waćpan masz :) Celem było pokazanie problemów z Mockami, cała metoda i test był dla zobrazowania problemu pokazany. Faktycznie, to też powinno być zrefaktoryzowane, natomiast traktuj ten przykład jak taki jeden z wielu, który masz w kodzie legacy, który ma problemy nie tylko w Mockach ale też właśnie w tych miejscach o których wspominasz. Mam w planach zrobić odcinek właśnie o tym używaniu now() i paru innych rzeczach w testach, które jebitnie je rozpierdalają, ale na pierwszy rzut oka :D

Tylko co chcesz tak przetestować? Powinniśmy testować zachowanie. Jeśli częścią zachowania jest odpytanie innej klasy to ta "inna" klasa powinna być używana bezpośrednio jako zależność, nie jako Mock/Spy/Fake. Jeśli podrzucisz więcej info to będę mógł odpowiedzieć bardziej konkretnie :)

​@@adambanaszkiewicz Niech będzie, że jest zachowanie "wygenerujToken", który korzysta z trzech innych klas. Nie dotykają żadnego API, żadnej bazy danych, nic z zewnątrz. W sumie załóżmy, że tylko do frameworka Symfony mają zależności. W takiej sytuacji najlepszym pomysłem integracyjnie to przetestować i bez żadnych mocków i dublerów? Czy gdyby nie było zależności do frameworka to wtedy można by jednostkowo to przetestować budując graf obiektów i też bez korzystania z mocków?

Test integracyjny to test który wychodzi poza proces, czyli idzie do bazy, do systemu plików, do jakiegoś API zewnętrznego. Jeśli Twoja klasa używa Symfony, ale te klasy SYmfony nie wychodzą "na zewnątrz" to nadal to jest test jednostkowy :) A odpowiadając na Twoje pytanie, "wygenerujToken" jest Twoim zachowaniem, zakładam, że zwraca ten token i jego testujesz. W tedy w teście jednostkowym musisz stworzyć obiekt klasy, którą testujesz, plus wszystkie zależności tej klasy, niezbędne do wykonania tego zachowania (zakładając, że to nie jest test integracyjny jak opisałem wyżej). Nawet mając zależność do frameworka, powinieneś zbudować pełny graf obiektów, zależności, który jest potrzebny by wygenerować ten token. Oczywiście nadal mając na uwadze, że te zależności operują nadal w tym procesie, i nie "wychodzą na zewnątrz", jak opisałem w pierwszym akapicie. Mam nadzieję, że w miarę jasno opisałem, ale jak masz jeszcze pytania to wal, chętne podyskutuję :)

@@adambanaszkiewicz Czy test jednostkowy to będzie zawsze dziedziczył po TestCase? Czy po KernelTestCase też może? Czy w teście jednostkowym taki graf obiektów można sobie wyciągnąć z kontenera zależności czy musimy go budować ręcznie? W sumie zawsze rozróżniałem testy jednostkowe i integracyjne według tego czy dany test dziedziczy po TestCase (unitowy) czy KernelTestCase (integracyjny). Czy taki sposób myślenia jest poprawny?

Tak, taki sposób myślenia jest ok. WebTestCase/KernelTestCase uruchamia cały kernel, więc niejako od razu masz dostęp do bazy danych itp. Nie musisz oczywiście z tego korzystać, ale już sam fakt zbudowania całego kernela i kontenera DI świadczy o tym, że to test integracyjny. Test jednostkowy ma za zadanie przetestowanie tylko jednego zachowania, i do tego mamy TestCase. Co do grafu obiektów z kontenera DI - jeśli masz kontener to to nie jest test jednostkowy. Graf obiektów, które są wymagane do przetestowania danego zachowania, MUSI być stworzony ręcznie w teście. Albo przez jakiś pattern typu Fabryka lub ObjectMother, jeśli wygodniej. Natomiast samo użycie DI automatycznie przenosi test na półkę testy integracyjnego.

A dziękuję, dziękuję :)

Skont wiesz?! :D

@@adambanaszkiewicz Po deptracu, ale w moim serduszku też gości PHP i za to poleciała łapka w górę :D

@@kosaa03 Dzięki :)