Szybszy rozwój aplikacji dzięki zaangażowaniu interdyscyplinarnych zespołów w podejściu micro frontendowym

Zoptymalizowany pod kątem sprzedaży, bardziej produktywny i odporny na ryzyko – tak może wyglądać twój proces tworzenia aplikacji webowych. Wystarczy zainspirować się mikroserwisami - rozwiązaniem znanym z back endu.

Hubert International Expansion Unit

24 czerwca 2022

Front end do niedawna: jeden zespół, wspólny kod

Tworzenie aplikacji webowych z czasem staje się uciążliwe. Obrastają one bowiem w kolejne funkcje i elementy, przez co coraz trudniej nimi zarządzać.

Niezależnie od rozmiaru większość współczesnych aplikacji internetowych opiera się na:

Rozbudowana strona przerasta możliwości jednego zespołu

Dopóki strona jest mała, jeden zespół i wspólny kod są wystarczające. Wszyscy programiści zaangażowani w projekt posiadają o nim taką samą wiedzę, więc praca i komunikacja postępuje bez przeszkód. Ale z czasem ilość kodu zwiększa się, aplikacja staje się bardziej złożona i konieczne jest poszerzenie zespołu o kolejnych programistów.

Wcześniej czy później projekt okazuje się zbyt duży, żeby mógł go ogarnąć w całości pojedynczy człowiek. Wtedy w zespole powstają „silosy wiedzy”. Rozbijają one komunikację i pogarszają wyniki. „Od pewnego momentu” – pisze Frederick Brooks w „The Mythical Man-Month” – “dodawanie kolejnych członków do zespołu przestaje zwiększać produktywność.”

„Od pewnego momentu dodawanie kolejnych członków do zespołu przestaje zwiększać produktywność.”
Frederick Brooks, „The Mythical Man-Month”

Back end zdążył się przystosować, front end (jeszcze) nie

Początkowo wszelkie aplikacje – nie tylko webowe – były od początku do końca rozwijane jako monolity, bez podziału na front i back. Mogły więc rozrastać się bez końca, zmieniając się w olbrzymy. Żeby ułatwić sobie życie, twórcy oprogramowania rozbili te olbrzymy na dwie części – front end i back end. W ten sposób łatwiej było je okiełznać. Po jakimś czasie tak samo potraktowano sam back end: został podzielony na mniejsze części zwane mikroserwisami. Łączyła je w jeden system tak zwana warstwa agregacji.

Niestety przez cały czas front end pozostawał w miejscu. Dziś często nadal jest nieporęcznym potworkiem, który „spoczywa” na ramionach mikroserwisów. (Rys. 1)

Rys. 1.: Ewolucja architektury back-endowej na tle stagnacji front endu

Problem w tym, że dzisiejszy front end dzielą od wczorajszego lata świetlne. Obecnie za pomocą samego HTML5 da się zrobić pełnoprawne gry wideo, zaś CSS pozwala na tworzenie imponujących animacji. Nie ma więc sensu pozostawać przy tej samej metodologii rozwijania oprogramowania, która obowiązywała w latach dwutysięcznych.

Micro frontend wprowadza pionowy podział zespołów: ważniejszy od technologii staje się interes klienta

Podejście micro frontendowe przejawia się na dwa sposoby. Pierwszy dotyczy człowieka, drugi technologii. W przypadku ludzi chodzi o to, w jaki sposób podzielimy ich na zespoły. Tradycyjnie we front endzie zasadą organizującą przydział do zespołów jest konkretna technologia – np. React, JavaScript, itp. W micro front endzie główną racją bytu zespołu jest wartość dla klienta, niezależnie od technologii.

Struktura zespołu odzwierciedla główne cechy architektury micro frontendowej

Struktura micro frontendu jest podobna do tej mikroserwisowej w back endzie. Rysunek 2. przedstawia widok z lotu ptaka na architekturę micro frontendową. Da się zauważyć wizualne podobieństwa do mikroserwisów z rysunku 1.: kilka pionowych filarów zespolonych u góry warstwą integracji.

Oto lista najważniejszych cech podejścia micro frontendowego, ukazanych przez pryzmat organizacji zespołów:

 

Rys. 2.: Schematyczny rzut na całe podejście micro frontendowe

Zespołom przyświecają specjalne misje, które dotyczą potrzeb konsumenta

Czym jest misja? To dokument, który definiuje, jakie potrzeby konsumenckie chcemy spełnić lub jakie przypadki użycia nas interesują. Spójrzmy na przykład na Rys. 3. Kiedy klient czegoś szuka, zespół „Inspire” pomaga mu to znaleźć. Gdy opcje wyboru się już zawężą, zespół „Decide” ułatwia podjęcie decyzji. I wreszcie, kiedy klient wie już, czego chce, zespół „Checkout” przeprowadza przez proces zakupu. 

Rys. 3.: Zespoły i ich misje

Zadaniem zespołów jest przeprowadzić klienta przez lejek sprzedażowy

Pewnie zauważyliście, że powyższe misje odpowiadają mniej więcej etapom podróży klienta lub lejka sprzedażowego. Lejek sprzedażowy dzielony jest na różne sposoby, ale w najbardziej podstawowej wersji może wyglądać tak, jak na Rys. 4. Widzimy tu następujące etapy:

Rys. 4.: Lejek sprzedażowy

Lejek sprzedażowy (podróż klienta) określa podział pracy w podejściu micro frontendowym

W web designie lejek sprzedażowy (często traktowany równoznacznie z „podróżą klienta”) często pokrywa się z elementami/funkcjami aplikacji webowej.

Na przykład: klient dowiaduje się, że dana opcja istnieje, odwiedzając naszą stronę (zyskuje świadomość); następnie przegląda dostępne produkty lub usługi (rozważa dostępne możliwości). I wreszcie podejmuje decyzję o zakupie poprzez umieszczenie wybranych elementów w koszyku i przejście do płatności.

Zespoły micro frontendowe, elementy oraz funkcje strony, a także etapy podróży klienta możemy połączyć w jedno – jak na Rys. 5:

Rys. 5.: Zespoły oraz elementy strony

Jeden zespół pracuje nad powtarzającymi się elementami na stronie

Związek między elementami oraz funkcjami strony a etapami podróży klienta nie zawsze jest jednoznaczny. Na przykład nagłówek albo stopka mogą powtarzać się na każdej podstronie. Angażowanie do pracy nad takim elementem wszystkich zespołów naraz byłoby mało produktywne, więc w micro frontendzie deleguje się do tego tylko jeden zespół. Te powtarzające się elementy nazywamy „wyizolowanymi interfejsami użytkownika” (Rys. 6).

Rys. 6.: Tylko jeden zespół jest odpowiedzialny za wyizolowane interfejsy użytkownika – tzn. powtarzające się elementy na stronie

Większa produktywność, skuteczniejsze rozwiązywanie problemów i komunikacja dzięki wielofunkcyjności zespołów

Interdyscyplinarność zespołów micro frontendowych to istotna cecha, która odróżnia to podejście od mikroserwisów w back endzie. W przypadku mikroserwisów mamy do czynienia z zespołami zorganizowanymi wokół konkretnej umiejętności lub technologii. Członkowie zespołów micro frontendowych są natomiast dobierani pod kątem konkretnego przypadku użycia bądź potrzeby klienta (Rys. 7).

Rys. 7.: Zespoły wyspecjalizowane (po lewej) kontra interdyscyplinarne (po prawej).

Zespoły interdyscyplinarne mają następujące zalety:

Spójność produktu zapewnia kontrolowana komunikacja między zespołami

Zespoły micro frontendowe pracują oddzielnie nad różnymi elementami strony, stosując takie technologie jakie najbardziej im odpowiadają, ale przecież produkt końcowy musi wyglądać spójnie. Gdyby między zespołami w ogóle nie zachodziła komunikacja, aplikacja webowa, nad którą pracują, mogłaby ostatecznie wyglądać jak potwór Frankensteina.

Żeby zapewnić spójność produktu końcowego, komunikacja między zespołami musi być dozwolona w dwóch krytycznych obszarach:

Szybszy rozwój funkcjonalności dzięki mniejszym i lepiej ukierunkowanym zespołom

Zespoły micro frontendowe są zwykle mniejsze i bardziej skupione na potrzebach konsumenta niż tradycyjne zespoły webdevowe. Dzięki temu nowe funkcje mogą powstawać szybciej, sprawniej, i w sposób bardziej zorientowany na konsumenta niż w starym modelu.

Większa odporność na ryzyko dzięki odseparowaniu zespołów

W tradycyjnym webdevie jeden błąd może wywołać efekt domina i pociągnąć za sobą konsekwencje dla całego projektu, bo cały kod istnieje w jednym miejscu. W micro frontendzie ryzyko awarii jest ograniczone do obszaru działania jednego zespołu.

Łatwiejszy refactoring dzięki rozdzieleniu kodu

Im więcej kodu w aplikacji, tym trudniejszy refactoring. Na przykład GitHub musiał poświęcić lata, żeby pozbyć się zależności od jQuery. W przypadku micro frontendu każdy zespół pracuje na osobnym kodzie, o wiele mniejszym niż w scalonym, finalnym produkcie. Z tego powodu refactoring w micro frontendzie jest łatwiejszy, mniej kosztowny i mniej czasochłonny, a ponadto można go wykonywać etapami.

Micro frontend pozwala unowocześnić stare systemy

Za pomocą micro frontendu można przekształcić gigantyczne strony internetowe w piękne i nowoczesne aplikacje zorientowane na klienta. W rezultacie te powolne i toporne giganty mogą skorzystać ze wszystkich zalet architektury micro frontendowej, które wymieniliśmy: pionowej struktury, nakierowania na klienta, zoptymalizowania pod kątem lejka sprzedażowego, zwiększonej kreatywności, skuteczniejszego rozwiązywania problemów, efektywniejszej komunikacji, szybszego rozwoju nowych funkcji, większej odporności na ryzyko, i wreszcie: łatwiejszego refactoringu.

Micro frontend w Clurgo

Dla jednego z naszych klientów, platformy SaaS obsługującej siłownie, stosujemy podejście podobne do micro frontendu. Zespoły są podzielone na podzespoły, z których każdy odpowiada za konkretną funkcjonalność, zwaną „sub-apką”. Każda z takich sub-appek może na przykład obsługiwać zarządzanie pracownikami, booking, analitykę, itp. Na końcu wszystkie one są dynamicznie integrowane w produkt końcowy za pomocą skryptów JS. 

Już wkrótce więcej technicznych szczegółów

Następnym razem przyjrzymy się technicznym szczegółom micro frontendu. Jesteście ciekawi, w jaki sposób warstwa agregacji łączy w jedno różne technologie wykorzystywane w projekcie? Zajrzyjcie tutaj niedługo, żeby się tego dowiedzieć.

bannerbanner

Your software development experts

We’re a team of experienced and skilled software developers – and people you’ll enjoy working with.

Start Your Projectadd