Backend

Wzorce projektowe. Architektura IT zorientowana na rozsądek

8 stycznia 2021 Piotr Kokoszka

Projektowanie architektury systemów informatycznych to spore wyzwanie. Dziś co „chwila” mówimy o nowych technologiach, nowych metodykach prowadzenia projektów, czy nowym podejściu do projektowania. Problemem jest jednak to, że architektura na koniec dnia… ciągnie się, przez co nie do końca wiadomo, czy goni czy… ją gonią.

Zobacz też

Wywiady Kim jest IT Architect? Wywiad z Pawłem Pietrzakiem

Piotr Kokoszka. Full Stack Engineer w KMD Poland. Zainteresowany szeroko pojętym webdevelopmentem od 16 roku życia, swoją profesjonalną przygodę z programowaniem zaczął w wieku 19 lat. Wieloletni mentor techniczny w programie studenckim KMD TalentLab. Od wielu lat związany z duńską firmą KMD. Poprzednio pracował zarówno dla dużych firm IT jak i dla startupów z branży fintech oraz medical care.

Pracowaliśmy kiedyś nad oprogramowaniem, które nazwano silosami/monolitami. Później pojawiły się warstwy i aplikacje wielowarstwowe. Następnie z warstw wydzielano komponenty, które same również mogły składać się z warstw. Zaczęliśmy wyróżniać tzw. „klienta” i „serwer”. Z kolejnym rozwojem już rozróżnialiśmy czy ten klient jest „cienki”, czy „gruby”, a w ostatnim czasie – czy ten cienki jest „responsywny”, czy nie.

Spis treści

Co to są wzorce projektowe?

Od tamtej pory wszystko już znacznie przyspieszyło. Pojawiały się nowe języki, nowe platformy, no i… wzorce projektowe. Ciekawe jest jak z biegiem czasu można łatwo rozpoznać osobę, która dopiero co zajęła się tym tematem. Taka osoba wszędzie zaczyna widzieć potencjał do użycia tych wzorców, wskazuje miejsca gdzie źle zostały użyte, naciąga rzeczywistość, aby tylko ich użyć, itd. itp.

Co nam dają te wzorce? Czy warto je stosować? Oczywiście, że warto, ale wszystko z głową. Wzorce projektowe to skuteczne i sprawdzone rozwiązania dla powtarzalnych problemów pojawiających się przy projektowaniu oprogramowania. Typowe wzorce projektowe zawierają nazwy, opisy problemu, możliwe rozwiązania i przewidywane efekty, oraz sposoby implementacji i przykłady zastosowania.

Wzorce projektowe pokazują zależności pomiędzy poszczególnymi elementami kodu, klasami i obiektami, ułatwiając modyfikację i utrzymanie kodu źródłowego. Podstawowo dzielimy wzorce projektowe na kreacyjne, strukturalne i behawioralne – dotyczą one odpowiednio procesu tworzenia obiektów, struktury klas lub obiektów, oraz ich wzajemnego oddziaływania.

W definicji tej jest zawarta główna idea wzorców – są opisem proponowanego rozwiązania, które zwykle się sprawdza. Ja to dodatkowo określam prostym stwierdzeniem „wzorce są dla projektu, a nie projekt dla wzorców”.

Wielokrotnie można spotkać się z sytuacją, w której użyto kiedyś wzorców projektowych, a teraz szybko trzeba się z nich wycofać (lub zmienić). Pierwszym z brzegu przykładem jest singleton. Bardzo dobre rozwiązanie, aby mieć pewność, że mamy tylko jedną instancję danego obiektu. Ale co w sytuacji, gdy wcześniej kod był używany przy aplikacji desktopowej, a teraz chcemy go użyć do aplikacji webowej? Nie wiemy, ile będzie instancji tego serwera, mamy jedynie pewność, że singleton będzie nim w ramach tylko danej instancji serwera.

Dobór technologii w architekturze i projektowaniu systemów informatycznych

Każdy biznes na swoje specyficzne wymagania, a systemy informatyczne tworzone są do wsparcia biznesu. Oznacza to, że dobór narzędzi i rozwiązań musi być zgodny z wymaganiami na system. Najistotniejszym, wbrew pozorom, elementem dokumentacji są przyjęte założenia projektowe. Wszelkie narzędzia, konstrukcje (do tej kategorii możemy zaliczyć wzorce projektowe), protokoły, platformy możemy traktować jako pewnego rodzaju klocki.

Architektura IT i projektowanie systemów informatycznych to dobór (architektura) i układanie tych klocków (projektowanie), w taki sposób, aby efektywnie zrealizować zadanie. Może być na początku niezrozumiałe dlaczego nie zostało wskazane, że istotne są wymagania klienta co do technologii. Okazuje się, że często zdarza się sytuacja, w której klient chcąc określone rozwiązanie, przy spełnieniu założonych wymagań niefunkcjonalnych (np. maksymalny czas odpowiedzi), musi zmienić swoje zdanie w zakresie wymaganej technologii. Zadaniem architekta jest w tym momencie znajomość przekroju technologii, narzędzi, wzorców i ich odpowiedni dobór do danego rozwiązania.

Jedno czego oczywiście nigdy nie powinniśmy ignorować to wymagania dotyczące bezpieczeństwa. Niezależnie od tego jakie „lepsze” rozwiązanie proponowalibyśmy klientowi, zwykle nie zmieni on ustaleń jeśli wymagałoby to zmiany przyjętych przez niego polityk.

Czasem warto też myśleć nieszablonowo. Kiedyś przy pracy nad pewnym projektem pojawił się problem wydajności jednego z algorytmów. Wyszukiwanie po bazie dawało wynik w czasie przekraczającym znacznie podane założenia, wyszukiwanie w pamięci szybko zużywało dostępną pamięć w maszynie. Jednym z rozwiązań była oczywiście modyfikacja algorytmu i inny sposób pobierania/wyszukiwania danych.

Zmiana została oceniona na co najmniej 2 tygodnie pracy. Gdy przyjrzano się dokładnie problemowi, okazało się, że przetwarzanych algorytmem metadanych, w perspektywie kilkuletniej, nie będzie więcej niż kilka GB. Wybrano rozwiązanie najprostsze z możliwych – zamówiono więcej RAMu, a w międzyczasie przełączono z wyszukiwania po bazie na wyszukiwanie po pamięci. W efekcie problem rozwiązano w ciągu jednego dnia.

Jak projektować architekturę oprogrowania?

Dzisiaj mamy mnóstwo decyzji do podjęcia. Czy planujemy usługi sieciowe, czy mikrousługi? Czy użyć wirtualizacji, czy konteneryzacji? Czy komunikacja ma być w formacie XML, czy JSON, a może jednak format binarny? Jaki protokół? Każde z rozwiązań ma swoje wady i zalety.

Usługa tworzy nam jedną większą całość, więc łatwiej jest czasem objąć pewien problem całościowo. Z drugiej strony aktualizacja jednego fragmentu obszaru funkcjonalnego wiąże się z aktualizacją i, przynajmniej chwilową, niedostępnością całej usługi. To może mikroserwisy? Dają nam drobny fragment funkcjonalności, w której się specjalizują, jednak wprowadzają rozdrobnienie i bardzo dużą złożoność przy przetwarzaniu transakcyjnym. Przy serwisach transakcyjnych, w ogóle nie zaleca się stosować architektury opartej o mikroserwisy.

Dzisiejsze trendy jasno wskazują drogę w kierunku mikroserwisów, jednak tak jak i ze wzorcami projektowymi, warto ich przesadnie nie przeceniać. Przynajmniej nie jeszcze. Czasem warto zachować zdrowy rozsądek i rozważyć wszelkie za i przeciw. Może warto pomyśleć bardziej perspektywicznie i swój system przygotować na mikroserwisy, a póki co wystawić system jako usługa?

Nie oznacza to jednocześnie, że całkowicie należy zrezygnować z tego typu architektury. Wszelkie działania związane z CI/CD (Continuous Integration / Continuous Delivery) idealnie nadają się na rozwiązania konteneryzacyjne. Jeśli same wymagania wskazują ewidentnie na mikroserwisy, to też nie powinniśmy na siłę z nich rezygnować. Zawsze najlepiej odsunąć się od danego problemu i postarać się na niego spojrzeć z pewnym dystansem, chwytając przy okazji pewien horyzont czasowy. Nie bez znaczenia jest też monitoring technologii i weryfikacja czy się ona rozwija, czy też jest sukcesywnie wygaszana.

Wielu klientów nie chce najnowszych bibliotek, najnowszych technologii, gdyż obawiają się ryzyka. To ryzyko jest realne i często zwane „chorobą wieku dziecięcego”. Należy rozważyć, a najlepiej skonsultować z klientem, jaki poziom ryzyka jest akceptowalny. Czas tworzenia systemów coraz bardziej się skraca, nie każda nowa technologia w tym czasie się „wyżarzy” (ustabilizuje).

Architektura IT – podsumowanie

Architektura i projektowanie systemów informatycznych to niezła zabawa. Jeśli do tego uda nam się przewidzieć trendy i wpasować się w nie tym systemem, to podwójna frajda. Należy pamiętać, że zarówno wzorce projektowe, jak i architektura nie są „przyspawane” do określonego języka, czy technologii. Na pewno nie należy się bać łączyć technologii. Wykorzystanie różnych mechanizmów na różnych platformach, w różnych językach programowania, aby z każdego elementu wyciągnąć to co najlepsze i w efekcie uzyskać efekt synergii to coś, do czego powinniśmy dążyć.

Słyszeliśmy kiedyś jak jeden z kolegów opowiadał, jak przyszedł na spotkanie, gdzie głowiono się nad rozwiązaniem pewnego problemu. Porozmawiał, pomyślał, przeanalizował i zadowolony narysował jedną kreskę pomiędzy dwoma komponentami systemu. Realizacja tej „kreski” wymagała pewnych nakładów finansowych (jak to się później cieszył: „przeciągnąłem linię za kilkaset tysięcy USD”), jednak rozwiązała całkowicie problem. I takiej radości z pracy wszystkim życzę.

Zobacz też