Trochę o szkoleniu młodzieży

Właśnie zdałem sobie sprawę, że niedawno minęło 10 lat od kiedy zacząłem moją przygodę z programowaniem. Przypominam sobie od czego ja zaczynałem i na samą myśl o kodzie, który wtedy tworzyłem pojawia się uśmiech na mojej twarzy 🙂

Jako młodzi programiści na początku zawsze popełniamy błędy i często podążamy niewłaściwą drogą. Jak zatem poradzić sobie na początku, na co zwrócić szczególną uwagę, a czego się wystrzegać?

Na początek odpowiedzmy sobie na pytania, dlaczego pomimo tego, że w dużej mierze nasze projekty nie są jakieś strasznie skomplikowane i głównie polegają na odebraniu jakiś danych z formularza użytkownika, zwalidowaniu poprawności i zapisaniu w jakiejś bazie danych. To dlaczego większość z tych projektów kończy się klęską albo w najlepszym przypadku strasznym skomplikowaniem? Każdy kto przejmuje ten kod w utrzymanie zaczyna przeklinać…?

To co pierwsze przychodzi mi do głowy to skłonność do nadmiernego kopiowania cudzych rozwiązań. Metoda copiego pasta? Pomijam już takie przypadki, które zdarzyło mi się niestety widzieć w swojej karierze jak skopiowana metoda mająca 1000 linijek, wklejona pod spodem, a w niej zmieniona jedna linijka i jeden parametr – tego chyba nie trzeba komentować… Ucząc się programować czy to w ogóle szukając rozwiązań problemów korzystamy z dobrodziejstw Internetu. No i niestety często zdarza się, że kopiowane są rozwiązania bez przemyślenia jak to się wpisuje w aplikację, którą tworzymy, jaki ma to wpływ na architekturę? Moja rada jest taka, jeśli już kopiujemy jakieś rozwiązanie, spróbujmy je napisać po swojemu, coś pozmieniać, uruchomimy być może w ten sposób proces myślowy, który doprowadzi nas do lepszego rozwiązania? To samo tyczy się tzw. kodu legacy, który otrzymujemy w spadku w utrzymanie, często zdarza się, że nie zastanawiamy się nad tym jak to jest zrobione, wychodzimy z założenia, że skoro działa to po co coś zrobić lepiej, a często jeszcze bardziej bałaganimy… Jeśli jesteśmy na początku swojej przygody z programowaniem, nie róbmy tak, w ten sposób nie uczymy się niczego nowego, tylko stajemy się bezmyślnymi koderami, zawsze każde własne rozwiązanie, nawet jeśli jest niedoskonałe ale było próbą zrobienia czegoś lepiej to dobry pomysł – dzięki temu zdobywamy cenne doświadczenie.

Druga sprawa to nadmierne przywiązywanie się do frameworków i buzzwordów, tak sam pamiętam swoją fascynację MVC, po prostu musiałem tego gdzieś użyć, nieważne co to za projekt czy klient chce aplikację desktopową – musi być przy użyciu MVC. Jasne, że frameworki i różnego rodzaju fajne nowinki zawsze będą nas najbardziej kręcić, w końcu jesteśmy programistami, czyli osobami technicznymi i technologia zawsze będzie nas najbardziej kręcić. Po prostu zachowajmy umiar, nie starajmy się na siłę wciskać rozwiązań tylko dlatego, że są fajne albo modne. Co z tego, że nasza aplikacja jest napisana w Angularze, przy użyciu EntityFramework i SignalR skoro działa wolno i nie spełnia wymagań biznesu? W tej branży chodzi o to aby dostarczyć klientowi rozwiązanie jakiego potrzebuje, biznes nie potrzebuje frameworków, biznes chce zarabiać pieniądze, frameworki mają nam pomóc osiągnąć ten cel.

Jeśli Uncle Bob się nie myli pisząc na swoim blogu, że co 5 lat liczba programistów się podwaja to przed senior developerami, dev leadami, architektami stoi niezłe wyzwanie. Jak ogarnąć młodzież, jak sprawić, aby czerpali radość z poszukiwania rozwiązań, aby chcieli się uczyć nie tylko nowych frameworków ale też wzorców projektowych i dobrych praktyk. Jeśli jesteś starym wyjadaczem, guru czy zwał jak zwał to właśnie przed Tobą stoi największe wyzwanie. To Ty musisz być wzorem do naśladowania, ale Twoim zadaniem nie jest tylko nadawanie kierunku projektu i określania żelaznej architektury, którą robiłeś już setki razy. Jeśli sam nadal programujesz to dobrym pomysłem będzie, aby Ci ludzie poznali procesy myślowe, które doprowadziły do końcowego rezultatu, może wykorzystać do tego celu code review? Twoją najważniejszą misją powinno być przekonanie tych ludzi do ciągłej nauki, do szukanie samodzielnie rozwiązań, tak aby czerpali z tego co robią satysfakcję.

SMessaging – prosta architektura oparta o wiadomości

Nie ukrywam, że od dawna podoba mi się podejście do budowy aplikacji w oparciu o wiadomości. Zdecydowałem się zebrać wszystkie mi znane materiały i napisać prosty framework (przynajmniej narazie prosty), którego zadaniem będzie umożliwienie budowy aplikacji w oparciu o wiadomości i handlery.

Dzięki temu w łatwy sposób możemy w naszej aplikacji zaimplementować CQRS ale nie tylko. W internecie można znaleźć bardzo wiele implementacji tego patternu ale ja chciałem maksymalnie uprościć architekturę, przecież nie zawsze nasza aplikacja musi być tak skomplikowana aby implementować odrazu CQRS.

Kod zarówno frameworka jak i przykład wykorzystania w aplikacji znajdziecie na GitHubie. Przedstawię w skrócie przykładową implementację w oparciu o prosty system rezerwacji.

Zaczynamy od kontrolera WebAPI, gdzie wstrzykujemy interfejs IMessaging:

To jest już pierwsza równica w budowaniu aplikacji w oparciu o wiadomości. Tradycyjnie tu mielibyśmy jakiś serwis aplikacyjny lub odrazu repozytorium dostępu do DB i w metodach robili jakieś operacje CRUD. Natomiast w tym podejściu zawsze do kontrolera będzie wstrzykiwany jeden interfejs, którego zadaniem jest przekazanie wiadomości przychodzącej „gdzieś” dalej, a przecież każdy request od użytkownika, każdy json, który leci do naszego API to tak naprawdę jakaś wiadomość, np. CreateOrder, GetOrder czy ShowListOfCars.

W takim podejściu nie ważne czy implementacja jest w serwisie, czy może w zupełnie innym miejscu. Bardzo upraszcza to kontroler WebAPI, jego odpowiedzialność to teraz tylko odebrać wiadomość, przekazać ją dalej i obsłużyć wynik lub ewentualny wyjątek:

Czy nie jest prościej?

Obsługę wiadomości implementujemy w handlerze, w dowolnym miejscu naszej aplikacji:

Zadaniem handlera jest wykonać daną operację i zwrócić wynik w postaci bardzo prostej struktury MessageResult. Dla operacji typu command czyli takich, które zmieniają stan aplikacji będzie to wyglądało podobnie ale wynik nie będzie potrzebny:

W taki sposób nasza aplikacja właściwie „sama” implementuje część patternów CQRS, stosując podejście handler per wiadomość właściwie w naturalny sposób odeseparowywujemy wiadomości pobierające dane od zmieniających stan aplikacji.

Aby włączyć framework należy go dodać w klasie konfigurującej zależności, w przypadku ASP.NET Core w klasie Startup:

To chyba tyle jeśli chodzi o prosty przykład. W przyszłości planuję rozwinąć framework o obsługę prostej kolejki i możliwość przesyłania wiadomości po sieci tak aby możliwe było zbudowanie rozproszonego systemu. Zapraszam do pobierania kodu z GitHuba.

Framework jest również dostępny do pobrania w NuGet.