Od zrozumienia wymagań biznesowych klienta po opisanie ich zespołowi, zrozumienie, dlaczego robisz to, co robisz, pomaga stworzyć architekturę, którą każdy może zrozumieć. Ale nawet jeśli przestrzegasz wszystkich zasad, skąd możesz mieć pewność, że projektujesz dobrą architekturę?
To było pytanie, na które chcieliśmy odpowiedzieć. Jako architekci musimy wiedzieć, że proponowane przez nas rozwiązanie jest najlepsze z możliwych dla klientów. Że to, co robimy, jest właściwym wyborem, właściwym kierunkiem i właściwym rozwiązaniem. Właśnie dlatego wzięliśmy udział w O'Reilly Winter Architectural Kata. Chcieliśmy się sprawdzić i zobaczyć, jak możemy poprawić naszą pracę.
Dlaczego warto brać udział w katas?
Zacznijmy od pewnego tła, jakiś czas temu podczas Global Software Architecture Summit GSAS, Wojciech Kasa i Sebastian Dąbkowski (dwóch innych członków zespołu) zwrócili się do Marka Richardsa z prośbą o radę. Planowaliśmy prowadzić własne wewnętrzne kata i sesje szkoleniowe.
Mark poświęcił czas na wyjaśnienie, że trudno jest porównywać architekturę. Najważniejszą częścią jest prezentacja. Nie tylko używane narzędzia, ale także sposób, w jaki programiści przekonują, że są najlepsi do tego zadania.
Ale przede wszystkim przekonał ich, że dobrym pomysłem jest zdobycie własnego doświadczenia. Przetestować to, co wiedzieli i uczyć się od najlepszych architektów na świecie. I wykorzystać to, czego się nauczyli, aby szerzyć tę wiedzę.
To właśnie popchnęło nas do dołączenia do kata. Do zawodów przystąpiliśmy pod nazwą Bluzbrothers. Zespół składał się z czterech osób: Sebastiana Dąbkowskiego, Piotra Filipowicza, Artura Kruszewskiego i Wojciecha Kaszy. Byliśmy podekscytowani możliwością sprawdzenia, ile wiemy o architekturze i czego możemy się nauczyć.
Czym są Katas i dlaczego są ważne?
Kata architektury oprogramowania to ćwiczenie szkoleniowe zaprojektowane, aby pomóc programistom i architektom ćwiczyć i doskonalić swoje umiejętności w projektowaniu systemów oprogramowania. Obejmuje ono rozwiązywanie hipotetycznych problemów projektowych, w ramach których uczestnicy mogą eksperymentować z koncepcjami i technikami architektonicznymi. Ćwiczenie to pomaga poprawić umiejętności rozwiązywania problemów, zrozumieć różne wzorce architektoniczne i poprawić komunikację w zespole.
Jak podeszliśmy do architektury
Jednym z częstych błędów w architekturze jest zbyt głębokie zagłębianie się w każdy element bez uwzględnienia szerszego obrazu. Prowadzi to do złożonych rozwiązań, które nie opowiadają ogólnej historii. Interesariusze często nie widzą "lasu przez drzewa". Skupiają się tylko na szczegółach technicznych, ale nie ma to znaczenia dla użytkowników i innych osób, które nie dbają o najdrobniejsze szczegóły. Pomyśl, jak dyrektor generalny ze środowiska biznesowego postrzegałby architekturę.
Zazwyczaj diagramy i dokumenty pokazują, jak działają systemy, ale nie wyjaśniają , dlaczego podjęto określone decyzje. Kiedy osoby nietechniczne przeglądają te materiały, pytają "dlaczego?".
Wymagania projektu szczegółowo opisują "jak", ale dodatkowa dokumentacja - taka jak ADR - wyjaśnia "dlaczego" wybrano określone ścieżki, zapewniając punkt odniesienia.
Podobnie jak w architekturze budynków , gdzie struktura odzwierciedla swój wewnętrzny cel i dodaje emocjonalny kontekst dla klienta, architektura oprogramowania musi robić to samo. Jest to forma architektonicznego opowiadania historii, która stała się podstawą naszego podejścia.
Czym jest opowiadanie historii architektury?
Narracja architektoniczna skutecznie komunikuje projekt wszystkim, od liderów biznesowych po programistów. Łączy wymagania funkcjonalne, decyzje architektoniczne i możliwe do wykonania kroki w jasną narrację. Takie podejście pomaga wszystkim interesariuszom - liderom zespołów, architektom, deweloperom - dostrzec wartość i znaczenie projektu, promując lepsze zrozumienie i współpracę w ramach całego projektu.
Nasze zwycięskie podejście
Na każdym etapie musieliśmy opisać, dlaczego działanie miało miejsce, a nie tylko jak. Aby oddzielić nasze podejście, podzieliliśmy je na 6 części. W ten sposób stworzyliśmy coś, co nazwaliśmy Architektoniczną Kostką Rubika.
Nie będę tutaj wdawał się w zbyt wiele szczegółów, a jedynie przedstawię ogólny podział sześciu boków naszej Kostki Rubika.
Perspektywa wymagań funkcjonalnych
Na pierwszej stronie architektonicznej kostki Rubika skupiliśmy się na perspektywie wymagań funkcjonalnych. Tutaj zbieramy i dokumentujemy podstawowe funkcje, które musi wykonywać aplikacja. Pozwala to dostosować produkt do potrzeb użytkowników i celów biznesowych. Techniki takie jak burza zdarzeń i mapowanie aktor-akcja są wykorzystywane do wizualizacji procesów systemowych i zapewnienia, że interakcje użytkownika są skutecznie zaprojektowane.
Perspektywa wymagań niefunkcjonalnych
Z drugiej strony zagłębiamy się w perspektywę wymagań niefunkcjonalnych. Obejmuje to identyfikację zarówno ukrytych, jak i jawnych wymagań, które dotyczą kwestii wydajności systemu, takich jak elastyczność i ewolucyjność, zapewniając, że architektura może wspierać długoterminową solidność i zdolność adaptacji.
Ograniczenia
Obracając kostkę, napotykamy ograniczenia. Ten aspekt obejmuje zrozumienie i udokumentowanie ograniczeń technologicznych, prawnych i budżetowych, które definiują granice projektu. Wpływa to na podejście architektoniczne i rozwojowe.
Perspektywa architektury technicznej
Z perspektywy architektury technicznej wybraliśmy styl architektoniczny, który wykorzystuje przetwarzanie danych w czasie rzeczywistym i diagramy, aby wyjaśnić, w jaki sposób aplikacja współdziała z innymi systemami. Jest to uzupełnione przez zaprojektowanie automatycznie skalowalnej infrastruktury i wdrożenie funkcji fitness w celu utrzymania integralności systemu w różnych warunkach.
Funkcje fitness
Kolejny obrót prowadzi nas do funkcji fitness , w których testowanie systemu i walidacja wydajności zapewniają, że architektura spełnia wszystkie wymagania funkcjonalne i niefunkcjonalne w zamierzonym środowisku.
Perspektywa budowania zespołu i podziału ról
Wreszcie, perspektywa budowania zespołu i podziału ról kładzie nacisk nawykorzystanie mapowania kontekstu do zdefiniowania topologii i granic zespołu. Pomogło to w komunikacji i współpracy w zespole projektowym. Ułatwiło to wszystkim produktywną pracę
To nie wszystko, a nasz pełny model architektoniczny można poznać tutaj, w dedykowanym studium przypadku.
Jakich lekcji udzielił nam Katas?
Oto, czego nauczyliśmy się pracując jako zespół:
- Budowanie dynamiki zespołu
Wcześnie zdaliśmy sobie sprawę, że wzajemna znajomość to nie to samo, co wspólna praca. Wrzuceni do miksu, doświadczyliśmy wszystkich klasycznych etapów normowania i burzy. Nie było gładko, zwłaszcza gdy musieliśmy szybko dostosować nasze podejścia i wydestylować najlepsze rozwiązania w krótkich seriach dyskusji. Ta faza nauczyła nas nieocenionej lekcji dostosowywania i łączenia różnych pomysłów w spójny plan pod presją. - Uwzględnianie szerokich perspektyw w rozmowach grupowych
Każde spotkanie grupowe było okazją do zaprezentowania i dopracowania naszego rozwiązania. W tym przypadku kluczowym wnioskiem było myślenie w szerokim kontekście, a nie dogłębnie. Spojrzenie na nasze plany z wielu perspektyw pozwoliło nam na kompleksowe i inkluzywne podejście, zapewniając, że żaden kamień nie pozostanie nieodwrócony. - Docenianie opinii jury
Opinie jury podkreśliły mocne strony naszej propozycji - w szczególności nasze elastyczne podejście, które pozostawiło deweloperom miejsce na wybór odpowiednich technologii. Ta równowaga była kluczowa; zbyt restrykcyjna i przepalilibyśmy budżet, zbyt luźna i architektura mogłaby zawieść. Narracja naszej prezentacji została również dobrze przyjęta, podkreślając wpływ dostosowania wyborów architektonicznych bezpośrednio do naszych celów. - Opowiadanie historii ponad specyfikacje
Podczas gdy szczegóły techniczne są kluczowe, nasz zespół postanowił skupić się bardziej na narracji. Napisaliśmy historię, która bezpośrednio łączyła się z potrzebami wydajnościowymi projektu. Takie podejście nie tylko sprawiło, że nasza prezentacja była bardziej zrozumiała, ale także podkreśliło praktyczne implikacje naszych decyzji architektonicznych. - Harmonizacja komunikacji wizualnej
Nasz zespół początkowo zmagał się z niespójnością naszych pomocy wizualnych, ponieważ każdy używał różnych narzędzi, kolorów i stylów. Lekcja była jasna: ujednolicić, aby wyjaśnić. Standaryzując nasze ilustracje, poprawiliśmy naszą zdolność do jasnego i skutecznego przekazywania pomysłów. - Sztuka współpracy
Prawdziwa współpraca wymaga równowagi między słuchaniem, obserwowaniem i komunikowaniem się. Nauczyliśmy się najpierw słuchać, używać oczu do potwierdzania szczegółów, a następnie skutecznie się komunikować. Ta metoda okazała się niezbędna do dostosowania naszych różnorodnych myśli i podejść. - Planowanie i synchronizacja
Jednym z największych wyzwań była koordynacja naszych harmonogramów. Pierwsze dni po inauguracji były ciche, co doprowadziło do kryzysu, w którym czas był napięty i nie wszyscy mogli się zsynchronizować. Zdaliśmy sobie sprawę, jak ważne jest planowanie pracy asynchronicznej i dostosowanie się do różnych rytmów pracy. - Niezależne, ale wzajemnie powiązane
Pomimo naszych wysiłków, aby pracować razem, były fazy niezależnej pracy - lub szturmu. Było to zarówno wyzwanie, jak i zaleta, ponieważ pozwoliło na indywidualne refleksje i wkład, które następnie włączyliśmy do rozwiązania.
Chcesz rozwinąć swoje własne doświadczenie Kata?
Od czasu do czasu prowadzimy własne katas otwarte dla programistów, którzy chcą poprawić swoje umiejętności i nauczyć się czegoś nowego. Aby być na bieżąco z informacjami o kolejnych wydarzeniach, kliknij tutaj.
Rada dla każdego, kto myśli o wzięciu udziału w Katas
Myślisz o tym, by zmierzyć się z Kata? Oto kilka przyjaznych wskazówek, które pomogą Ci zacząć:
- Współpracuj z jury
Nie wahaj się zadawać pytań jury. Współpraca z nimi może zapewnić jasność i upewnić się, że Twoje rozwiązanie jest zgodne z celami i oczekiwaniami Kata. Ich spostrzeżenia mogą nakierować Cię na to, co jest najbardziej cenione w Twoich zgłoszeniach. - Zidentyfikuj główny problem
Skoncentruj się na odkryciu głównego problemu przed zagłębieniem się w szczegółowe rozwiązania. Często konieczne jest zajęcie się szerszą kwestią, zanim w grę wejdą drobniejsze elementy architektury. Rozpoznaj globalne znaczenie i mechanizmy wsparcia, które są niezbędne do skutecznego sprostania tym podstawowym wyzwaniom. Nadaj priorytet tym podstawowym elementom w swoim podejściu. - Przyjęcie szerokiej perspektywy
Na początku należy patrzeć szeroko, a nie dogłębnie. Szeroka perspektywa pozwala spojrzeć na problem z różnych punktów widzenia, zapewniając, że rozwiązanie jest kompleksowe i uwzględnia wszystkie niezbędne aspekty. Takie podejście pomaga w stworzeniu bardziej skutecznej i kompleksowej odpowiedzi na problem. - Opanuj sztukę opowiadania historii
Bez względu na to, jak solidna technicznie może być Twoja architektura, jeśli nie potrafisz skutecznie przekazać jej wartości, nie będzie ona rezonować. Naucz się opowiadać fascynujące historie o swoim projekcie. To nie tylko przyciąga uwagę odbiorców, ale także podkreśla praktyczny wpływ i znaczenie wyborów architektonicznych. Dobrze opowiedziana historia może być pomostem między dobrą architekturą a zwycięską propozycją.
Wnioski
Jeśli zastanawiasz się, czy wziąć udział w kata, nasze doświadczenie sugeruje, że warto podjąć ten wysiłek. Uzyskane spostrzeżenia i ulepszenia mogą znacząco wpłynąć na Twoje podejście do projektowania architektonicznego. Spróbuj i przekonaj się sam, jaką różnicę może to zrobić.
A dla naszego zespołu? Patrząc w przyszłość, jesteśmy podekscytowani możliwością zastosowania tego, czego się nauczyliśmy w naszych wewnętrznych działaniach.
