Jestem programistą od 20 lat. Oglądając Wasz kanał mam trochę mieszane uczucia. Na pewno robicie super robotę. Mistrzostwo. Nawet na zagranicznym YT nie ma chyba kanałów na tym poziomie, przynajmniej ja nie znam. Mam na myśli ilość i kompleksowość wiedzy jaką dostarczacie. Dzięki Waszemu kanałowi podnosi się poziom mózgowia programistycznego w Polsce. Z drugiej strony zastanawiam się ile z tej wiedzy faktycznie może wykorzystać przeciętny programista. Na przykład w moim przypadku (mała firma) sporo tematów poruszanych na Waszym kanale po prostu nie ma racji bytu, bo wielu klientów nie ma kasy na oprogramowanie wytwarzane takimi metodami (potrzebny jest ktoś od architektury, ekspert domenowy itp.). Zastanawiam się ile czasu potrzeba aby zrobić aplikację X zgodnie z DDD, a ile czasu metodami "na żywioł". Oczywiście ktoś może powiedzieć że wytwarzanie oprogramowania "na żywioł" jest bez sensu, głupie, że to druciarstwo, ale istnieje bardzo dużo oprogramowania które powstało w ten sposób, ono działa i zarabia/zarobiło jakieś przyzwoite pieniądze. I kosztowało znacznie mniej niż dopieszczone oprogramowanie zrobione z użyciem DDD, SOLID, CQRS, H20, BMW itp. Podsumowując - uważam, że należy się doskonalić, każda minuta Waszych materiałów jest wartościowa, ale nie zawsze taka doskonałość jest osiągalna w okolicznościach w jakich się znajduje programista. Fajnie by było, gdybyście informowali, że te fajne rzeczy które pokazujecie kosztują i nie zawsze można sobie na takie podejście pozwolić. Bez klienta srającego pieniędzmi, którego dochody są w jakiś sposób zależne od wytwarzanej aplikacji to po prostu nie zadziała.
Problem zaczyna się w momencie kiedy aplikacja działa już jakiś czas. Wtedy koszt jej utrzymania bardzo mocno wzrasta, a po kilku latach najczęściej zapada decyzja o przepisaniu kodu.
20:20 nie no, piękny wzorzec, tak czysto zaimplementowany :) zamiast zwykłego ifa który był poprawny i po prostu działał zrobiliście klasę, która dziedziczy z innych i która jest taka prosta do sprawdzenia, czy wszystko jest z nim ok, że... nie zadziała prawidłowo :) tzn. wywali się, jeśli użytkownik wybierze płatność inną niż gotówką. oryginalny if to przepuszczał (bo powinien), nowy wzorzec wywali wyjątek. siedziało nad tym dwóch seniorów i tak prostego błędu logicznego nie zauważyło. może dlatego że błąd jest rozrzucony pomiędzy kilkoma klasami zamiast siedzieć w jednym ifie (gdzie wszystko byłoby oczywiste)? nasuwa się oczywiste pytanie: czy aby na pewno ten wzorzec jest łatwy do ogarnięcia?
Świetny odcinek :) Mam 2 pytanka: 1. Dlaczego `CanPayWithCash` przyjmuje w parametrze wartość płatności, a nie `Payment`? jeżeli chcielibyśmy specyfikację budować dynamicznie, to tym bardziej do instancjonowania potrzeba informacji z `Payment`. 2. W sumie, można by jeszcze bardziej to zgeneralizować i nazwać `CanPayWithPaymentType`, bo np. Blik też ma swoje limity. Zatem uwaga z poprzedniego punktu tym bardziej aktualna. Podsumowując, wydaje mi się, że większy sens jest w instancjonowaniu tej specyfikacji specyfikacji z `Payment`, a może też z wartością, a wywołanie `Check` robić puste lub tylko z wartością płatności.
Pełna zgoda :) Tu bardziej chcieliśmy pokazać ideę niż starać się odpowiedzieć na wszelkie wymyślone wymagania biznesowe, które i tak by wyszły od nas :D
Świetny materiał jak zawsze. Natomiast mam pytanie jak wygląda u was kwestia testowania komponentu który używa takiej specyfikacji. Czy instancjonowanie tej klasy bezpośrednio w metodzie nie uniemożliwia testowania?
Czemu w tagach jest #ruby i #python xdd, btw robiliście kiedyś specyfikacje która zamiast implicit konwersji do expressiona, zamieniana była na raw sql'a do dappera ?
Wzorzec jest uniwersalny, dlatego wrzucamy inne języki jako tagi. 😉 Oczywiście zaleznie od jezyka zaaplikowanie w ORMie może być ciezsze. W EF Core akurat jest to proste. Co do Dappera - natywnie nie ma wsparcia dla Expression ale nic imho nie stoi na przeszkodzie, żeby chociażby w Repository (albo jako jakimś extensionie w Infrastructure) zrobić mapowanie na SQLa uzywajac chociażby: github.com/tmsmith/Dapper-Extensions albo forka w/w: github.com/ryanwatson/Dapper.Extensions.Linq /Michau
Jestem programistą od 20 lat. Oglądając Wasz kanał mam trochę mieszane uczucia. Na pewno robicie super robotę. Mistrzostwo. Nawet na zagranicznym YT nie ma chyba kanałów na tym poziomie, przynajmniej ja nie znam. Mam na myśli ilość i kompleksowość wiedzy jaką dostarczacie. Dzięki Waszemu kanałowi podnosi się poziom mózgowia programistycznego w Polsce.
Z drugiej strony zastanawiam się ile z tej wiedzy faktycznie może wykorzystać przeciętny programista. Na przykład w moim przypadku (mała firma) sporo tematów poruszanych na Waszym kanale po prostu nie ma racji bytu, bo wielu klientów nie ma kasy na oprogramowanie wytwarzane takimi metodami (potrzebny jest ktoś od architektury, ekspert domenowy itp.). Zastanawiam się ile czasu potrzeba aby zrobić aplikację X zgodnie z DDD, a ile czasu metodami "na żywioł". Oczywiście ktoś może powiedzieć że wytwarzanie oprogramowania "na żywioł" jest bez sensu, głupie, że to druciarstwo, ale istnieje bardzo dużo oprogramowania które powstało w ten sposób, ono działa i zarabia/zarobiło jakieś przyzwoite pieniądze. I kosztowało znacznie mniej niż dopieszczone oprogramowanie zrobione z użyciem DDD, SOLID, CQRS, H20, BMW itp.
Podsumowując - uważam, że należy się doskonalić, każda minuta Waszych materiałów jest wartościowa, ale nie zawsze taka doskonałość jest osiągalna w okolicznościach w jakich się znajduje programista. Fajnie by było, gdybyście informowali, że te fajne rzeczy które pokazujecie kosztują i nie zawsze można sobie na takie podejście pozwolić. Bez klienta srającego pieniędzmi, którego dochody są w jakiś sposób zależne od wytwarzanej aplikacji to po prostu nie zadziała.
Problem zaczyna się w momencie kiedy aplikacja działa już jakiś czas. Wtedy koszt jej utrzymania bardzo mocno wzrasta, a po kilku latach najczęściej zapada decyzja o przepisaniu kodu.
w każdym if-ie tworzycie nowy obiekt, nie boicie się o performance? Co kiedy taka specyfikacja byłaby w pętli?
20:20 nie no, piękny wzorzec, tak czysto zaimplementowany :) zamiast zwykłego ifa który był poprawny i po prostu działał zrobiliście klasę, która dziedziczy z innych i która jest taka prosta do sprawdzenia, czy wszystko jest z nim ok, że... nie zadziała prawidłowo :) tzn. wywali się, jeśli użytkownik wybierze płatność inną niż gotówką. oryginalny if to przepuszczał (bo powinien), nowy wzorzec wywali wyjątek. siedziało nad tym dwóch seniorów i tak prostego błędu logicznego nie zauważyło. może dlatego że błąd jest rozrzucony pomiędzy kilkoma klasami zamiast siedzieć w jednym ifie (gdzie wszystko byłoby oczywiste)? nasuwa się oczywiste pytanie: czy aby na pewno ten wzorzec jest łatwy do ogarnięcia?
Dzięki Panowie
Świetny odcinek :)
Mam 2 pytanka:
1. Dlaczego `CanPayWithCash` przyjmuje w parametrze wartość płatności, a nie `Payment`? jeżeli chcielibyśmy specyfikację budować dynamicznie, to tym bardziej do instancjonowania potrzeba informacji z `Payment`.
2. W sumie, można by jeszcze bardziej to zgeneralizować i nazwać `CanPayWithPaymentType`, bo np. Blik też ma swoje limity. Zatem uwaga z poprzedniego punktu tym bardziej aktualna.
Podsumowując, wydaje mi się, że większy sens jest w instancjonowaniu tej specyfikacji specyfikacji z `Payment`, a może też z wartością, a wywołanie `Check` robić puste lub tylko z wartością płatności.
Pełna zgoda :) Tu bardziej chcieliśmy pokazać ideę niż starać się odpowiedzieć na wszelkie wymyślone wymagania biznesowe, które i tak by wyszły od nas :D
Świetny materiał jak zawsze. Natomiast mam pytanie jak wygląda u was kwestia testowania komponentu który używa takiej specyfikacji. Czy instancjonowanie tej klasy bezpośrednio w metodzie nie uniemożliwia testowania?
Czemu w tagach jest #ruby i #python xdd, btw robiliście kiedyś specyfikacje która zamiast implicit konwersji do expressiona, zamieniana była na raw sql'a do dappera ?
Wzorzec jest uniwersalny, dlatego wrzucamy inne języki jako tagi. 😉 Oczywiście zaleznie od jezyka zaaplikowanie w ORMie może być ciezsze. W EF Core akurat jest to proste.
Co do Dappera - natywnie nie ma wsparcia dla Expression ale nic imho nie stoi na przeszkodzie, żeby chociażby w Repository (albo jako jakimś extensionie w Infrastructure) zrobić mapowanie na SQLa uzywajac chociażby:
github.com/tmsmith/Dapper-Extensions
albo forka w/w:
github.com/ryanwatson/Dapper.Extensions.Linq
/Michau
18:02 nie ma spacji po : a 18:06 jest 😩
super odcinek
Strasznie toporny ten gość w czapce z gadki.