Drivery architektoniczne2023-08-30Cześć! Witaj w najnowszym wydaniu inżynierskiego newsletteru. Jeśli jesteś tu ze mną już jakiś czas, na pewno wiesz, jak duży nacisk kładę na to, by przekazywane przeze mnie wskazówki były skuteczne, przejrzyste i łatwe do wprowadzenia w życie. Dziś kontynuujemy temat najlepszych praktyk inżynierskich, ucząc się na praktycznych przykładach najlepszych firm produktowych. Na tapet bierzemy więc Drivery Architektoniczne. Dowiesz się, jakie problemy rozwiązują i w jaki sposób je definiować, a także wykorzystywać w pracy. Oczywiście, w ramach rozgrzewki, czeka też na Ciebie inżynierska prasówka. A więc w dzisiaj mam dla Ciebie: Miłego czytania 😀 Inżynierska prasówkaCo zdarzyło się w ostatnich dwóch tygodniach w branży inżyniersko produktowej? Wielka premiera, a może ciekawy artykuł, który pozwoli Ci spojrzeć na codzienne procesy w inny sposób? W ramach Inżynierskiej Prasówki zbieram dla Ciebie najciekawsze i najbardziej wartościowe treści. Do kawy, herbaty lub po prostu w ramach czasu poświęconego na rozwój.
Rozgrzewka zakończona? Pora głębiej wejść w dzisiejszy temat przewodni. 😎 Drivery architektoniczneCo się dzieje, kiedy projektujemy “na czuja”?Często rozmawiam z liderami technicznymi, których projektowanie opiera się na intuicji i subiektywnych przekonaniach. Osoby decyzyjne kierują się aktualnymi trendami i osobistymi preferencjami. Spotkałeś/aś kiedyś z taką sytuacją? Jeśli nie, zadaj sobie następujące pytanie:
Podejmując decyzje pod wpływem chwili, narażamy się na wpadnięcie w pułapkę overengineeringu. Systemy, które dotknęła ta bolączka są skomplikowane, przepełnione funkcjami i możliwościami. Zespół kończy z produktem coraz droższym i trudniejszym w utrzymaniu.
Co więcej, brak spójnej wizji w projektowaniu sprawia, że zespół nie dostosowuje się do potrzeb odbiorców. Optymalizujemy nasz produkt pod kryteria, które nikogo nie interesują. Bez jasności, co jest ważne dla biznesu, rodzą się nieporozumienia i konflikty, a ocena postępów zaczyna graniczyć z niemożliwością. W dłuższej perspektywie, brak jasnych kryteriów i ram dla produktu prowadzi do zwiększenia kosztów i opóźnień. Nieoptymalne rozwiązania wymagają częstych zmian. Niejasne miary sprawiają, że trudno jest ocenić, czy produkt jest na właściwie rozwijany. Efekt? Jakość leci na łeb na szyję. Organizacje z silną kulturą inżynierską pracują inaczej. Pracując jak inżynierowieWysoko rozwinięte organizacje inżynierskie podchodzą do projektowania systemów w sposób bardziej przemyślany i celowy. Kluczem do sukcesu jest skupienie na driverach architektonicznych – czynnikach, które kierują, wpływają i kształtują ostateczną architekturę oprogramowania. Aby skutecznie wykorzystywać drivery w pracy, musimy posiadać miary, które pozwolą ocenić, czy dany system spełnia oczekiwania. Dzięki temu możemy przeprowadzać dokładną ocenę różnych propozycji rozwiązań, bazując na jasno określonych kryteriach. W sytuacjach, gdy żadne z proponowanych rozwiązań nie spełnia wszystkich oczekiwań, niezbędne mogą być negocjacje z interesariuszami. Dzięki jasno zdefiniowanym driverom, widzimy na jakie kompromisy się zgadzamy. Możemy więc skuteczniej komunikować i argumentować nasze decyzje. Co więcej, odpowiednie dokumentowanie zarówno procesu projektowania, jak i podjętych decyzji, pozwala na zachowanie ciągłości wiedzy, ułatwiając przyszłe prace nad produktem. Przykład z branżyW tej edycji newslettera przykładem podzielił się Karol Kreft – Technical Leader w Volt.io, gdzie współtworzy infrastukturę do obsługi płatności w czasie rzeczywistym.
Ok, a więc jak tego wszystkiego dokonać?
Drivery architektoniczne w teorii i praktyceRozpocznijmy od podstaw – bez nich trudno iść dalej.😉 Czym są drivery architektoniczne? Simon Brown w książce “Software Architecture for Developers” opisuje je tak:
Czyli mówimy tutaj o głównych czynnikach, które mają wpływ na naszą architekturę. Nierozpoznane odpowiednio wcześnie powodują, że nasze rozwiązanie będzie rozwijane w nieodpowiednim kierunku. Wyodrębniamy cztery kategorie driverów architektonicznych w projektowaniu systemów:
Pierwszy z nich jest w miarę oczywisty. Projektujemy pod określone wymagania. Skupiamy się, aby zrealizować główne funkcje, zarówno w krótkim, jak i długim terminie. Musimy je zdefiniować jasno dla wszystkich członków zespołu. Ostatni zależy wyłącznie od nas – sami narzucamy sobie wybrane praktyki. Mówimy tutaj zarówno o praktykach programistycznych (jak testy jednostkowe), jak i architektonicznych (jak nacisk na modularność). Kwestie atrybutów jakościowych i ograniczeń rodzą natomiast najwięcej pytań i wątpliwości, dlatego dziś to je chciałbym Ci szerzej przybliżyć. Atrybuty jakościoweAtrybuty te, nazywane również wymaganiami niefunkcjonalnymi, to wewnętrzne miary systemu, przez które rozwiązanie może być oceniane. Nie widać ich na pierwszy rzut oka, jednak to od nich zależy czy produkt będzie dobrze przyjęty przed klientów. Część atrybutów jakościowych możesz zauważyć na grafice poniżej:
Kolejne atrybuty jakościowe możesz znaleźć w artykule Love Sharma lub w książkach „Software Architecture for Developers" Simona Brown, czy „Fundamentals of Software Architecture" Marka Richardsa i Neala Forda. W ramach pracy z atrybutami jakościowymi warto wybrać z interesariuszami kilka z nich i to pod nie optymalizować pracę systemu. OgraniczeniaRzadko kiedy pracujemy bez żadnych ograniczeń ze świata zewnętrznego. Zwykle mamy jednak ustalone deadline’y, współpracujemy z zewnętrznymi organizacjami czy kontynuujemy istniejące procesy. Nasza praca musi się do tego dostosować. Wyróżniamy trzy główne rodzaje ograniczeń , do których pownniśmy sobie zadawać następujące pytania:
Zadając takie pytania jesteśmy w stanie określić kluczowe ograniczenia. Poprawne miary dla driverówCo to znaczy, że system jest wydajny? Zapytaj 2 interesariuszy, a dostaniesz 3 odpowiedzi. 😅 Ale to właśnie dlatego warto pytać. Kluczowym jest, aby dla atrybutów jakościowych i ograniczeń zdefiniować dobre miary. Dzięki temu będziemy w stanie wiedzieć, czy podążamy we właściwym kierunku. Pierwsze, co mogę polecić to skupienie się, aby najpierw otworzyć dyskusję i ustalić czy dany driver jest istotny. Dopiero później przyjdzie czas na szczegóły.. Dlaczego? Trudno jest podać rozmówcy właściwe informacje, kiedy bez kontekstu zadajemy bardzo szczegółowe pytanie. Pracę można podzielić więc na 2 fazy:
Jeśli dalej nie macie właściwych miar, to polecam zajrzeć do książki How to Measure Anything. Jest tam świetna instrukcja jak mierzyć rzeczy „niemierzalne". Całość opiera się o decyzje, jakie chcemy podjąć za pomocą miar. W skrócie:
Projektowanie i ocena na podstawie driverówDrivery nie powinny zostać raz spisane, a następnie odłożone na półkę. Poszczególne drivery będą nas kierować podczas projektowania i wyboru rozwiązania. W ramach samego projektowania, warto podzielić pracę na 3 etapy:
Co zyskujemy, trzymając się tej kolejności? Dzięki temu unikniemy błędów poznawczych, takich jak efekt skupienia czy heurystyka zakotwiczenia. To zaś da nam większą szansę na wybranie dopasowanego rozwiązania. Jak to wygląda w praktyce? W przykładzie poniżej mamy 2 propozycje (funkcje serverless i aplikacje webową) oraz 2 drivery architektoniczne (ograniczenie czasowe i wydajność):
Dla każdej z ocen zostało określone ryzyko (w skali 1-10) oraz zwięźle wyjaśniony powód. Dzięki temu możemy:
Tak wykonana ocena jest również świetnym argumentem w negocjacji z interesariuszami, może też służyć do dokumentowania wybranych rozwiązań. NegocjacjeNajciekawszą sytuacją, jaka może wyjść w ramach oceny projektu rozwiązania jest ta, gdy uświadamiamy sobie, że żadne rozwiązanie nie jest w stanie nas zadowolić. 😬 Wtedy musimy rozpocząć trudny proces negocjacji z interesariuszami, które drivery możemy zmodyfikować i w jaki sposób. Na szczęście, jeśli:
to mamy wszystkie informacje potrzebne do tego, by takie negocjacje przeprowadzić. Jak więc się do tego zabrać? Na samym początku musimy wyjaśnić drugiej stronie skąd w ogóle negocjacja . Wykorzystanie tabeli oceny pozwala się lepiej porozumieć się nie tylko wewnątrz zespołu produktowego, ale również pomiędzy interesariuszami. Następnie musimy podjąć decyzję, które drivery zmieniamy. Mamy do wyboru na przykład:
Mając szerszą perspektywę, łatwiej jest odpuścić pojedynczy element. Wiemy nie tylko co tracimy, ale też co zostaje dalej zostaje. Dokumentowanie projektowania i decyzjiCała powyższa praca może być przeprowadzona w formie dyskusji na spotkaniach. Ma to jednak swoje wady:
Aby sobie z tym poradzić, organizacje z silną kulturą inżynierską zaczęły wykorzystywać formę pisaną do utrwalania informacji. Wyklarowały się 2 rodzaje dokumentów:
Oba te dokumenty mogą być wykorzystywane, aby przeprowadzać prace inżynierskie, jednak na nieco innym etapie działania i w innym celu.
Cały proces jest przystępnie opisany na stronie inżynierów Spotify (chociaż sam obrazek jest trochę za długi 😅):
Czy dokumentowanie nie będzie trwało zbyt długo?Dokumentowanie ma swoje zalety, z którymi identyfikuje się np. Amazon kultywując kulturę pisania:
Prowadzenie solidnej dokumentacji ma swoje koszta, ale długofalowo one się zwracają. MateriałyPowyższy tekst jest tylko pigułką najważniejszych informacji o temacie. Jeśli chcesz dowiedzieć się więcej, przygotowałem garść materiałów, które przybliżą Ci omawiane obszary:
PodsumowanieAby projektować właściwe rozwiązanie, należy wiedzieć pod co je optymalizujemy. W tym właśnie pomagają nam drivery architektoniczne. Dzięki nim sterujemy rozwiązaniem we właściwym kierunku. A jak wygląda projektowanie u Ciebie? Wybierasz z zespołem na podstawie widzimisię, czy macie zdefiniowane czynniki architektoniczne? 🤔 📧 Prześlij dalejDzięki, że doczytałeś(aś) do końca. 😊 Wszystkie poprzednie wydania newslettera są dostępne tutaj. Jeśli spodobał Ci się mój newsletter, prześlij go proszę osobom, którym też mógłby się spodobać. Z góry dziękuję. A jeśli nie jesteś jeszcze w newsletterze, to zachęcam do zapisania się. Polecam się na przyszłość!  "Inżynierskie podejście do produktów cyfrowych." P.S. Co myślisz o tym newsletterze? Odpisz :) |
