When you think about your system, don’t think about your technology choice. Make sure you think about it in the desirable properties you want your system to have. And then the technology choice is just the incarnation of that.
Disclaimer: jeśli uważasz się tylko za “klepacza kodu”, możesz już zamknąć tę stronę 😉
Mamy problem w frontendowej społeczności 😉
Skupiamy się na bibliotekach, frameworkach, bundlerach, liczbie gwiazdek na GitHubie… i wielu innych rzeczach, które mają znikome znaczenie.
Mamy też tendencję do zakochiwania się w narzędziach (Redux, patrzę na ciebie, gdzieś tak w latach 2015–2016) i do ich mocnego nadużywania.
Potem odwracamy się i… zaczynamy nienawidzić tego samego narzędzia dokładnie z tych samych powodów (Redux, znowu o Tobie mowa). Zarówno miłość, jak i nienawiść były nieuzasadnione.
Więc… co poszło nie tak? 🤨
Problem polega na tym, że wielu z nas frontend devów nie ma odpowiednich kompetencji ani wiedzy z zakresu architektury oprogramowania. Nasza uwaga jest często skierowana gdzie indziej. Te umiejętności są absolutnie niezbędne (choć same w sobie niewystarczające), żeby projekt miał szansę na długofalowy sukces.
Bo architektura to niewidzialny most pomiędzy tym, co istotne z punktu widzenia biznesu, a tym, co ważne technicznie.
Podczas szkoleń dla programistów, konsultacji czy rekrutacji liderów technicznych często zadaję jedno, bardzo konkretne pytanie: jak rozumiesz pojęcie architektury oprogramowania?
Jakie aspekty są najważniejsze? Na co trzeba szczególnie uważać? Co to znaczy zdrowa, przemyślana architektura systemu? I jaka powinna być rola architekta?
Zatrzymaj się na chwilę i spróbuj odpowiedzieć samodzielnie 😉
Tik-tak ⏰…
To pytanie celowo jest bardzo szerokie, żeby rozmówca sam określił, co według niego naprawdę się liczy. Nie podsuwam żadnych sugestii.
Ale jeśli odpowiedź zaczyna się od: „architektura (frontendowa) to sposób organizacji plików i folderów…” – to dla mnie natychmiastowa czerwona flaga 🟥.
Tak, do napisania tego posta zmotywowała mnie kolejna osoba, która dokładnie to powiedziała 😉.
Chcę, Drogi Czytelniku, przesunąć Twoją uwagę. Zainspirować Cię, byś spojrzał na architekturę z innej perspektywy. Oderwać się od struktury katalogów, którą widzisz w repozytorium, albo od konkretnych rozwiązań w kodzie.
Skup się na tym, jakie cechy powinien mieć Twój system. Jakie możliwości będą potrzebne w szerszym kontekście. Oderwij się od narzędzi i przypomnij sobie o tradeoffach , które za sobą niosą.
I wreszcie zastanów się, jakie wymagania funkcjonalne i niefunkcjonalne są pochodną potrzeb Twojego biznesu.
Czym jest architektura (frontendowa)?
Tak, ten tweet naprawdę się pojawił 😅:
Gdzieś w komentarzach pod spodem ktoś zapytał mnie, jak ja rozumiem architekturę.
Starałem się odpowiedzieć zwięźle:
To decyzje, które podejmujesz zgodnie z wymaganiami biznesowymi, kształtujące system dzisiaj, ale trudne do zmiany w przyszłości.
Prawda jest taka, że nie istnieje jedna, uniwersalna definicja architektury oprogramowania.
Gorąco polecam przewodnik Martina Fowlera: Software Architecture Guide.
Są też inne definicje, które lubię:
To decyzje, które chciałbyś podjąć dobrze już na początku projektu.
albo
Architektura to po prostu ważne rzeczy. Jakiekolwiek by one nie były.
Zwróć uwagę na to słowo: ważne.
I jeszcze jedno: decyzje.
Zanim przejdziemy do przykładów (w drugiej części artykułu), zacznijmy od podstaw.
Decyzje
W trakcie życia projektu trzeba podjąć mnóstwo decyzji: od wyboru języka/platformy, przez biblioteki, paradygmat programowania, styl kodowania… tabs vs spaces… 🤔, ale też: jak zapewnić zgodność z priorytetami biznesowymi i wymaganiami, które napotykamy, jak umożliwić pracę dziesiątkom programistów nad tym samym systemem, jak wspierać częste wdrożenia (codziennie, co godzinę, nawet w piątki), i tak dalej.
Tak, jak widzisz tematy, które poruszamy, obejmują zarówno te mało istotne, jak i absolutnie kluczowe.
Aspekty, które analizujemy, i decyzje, które podejmujemy, różnią się wagą.
Im bardziej doświadczeni są programiści, tym częściej starają się unikać inwestowania energii w rzeczy, które nie mają większego znaczenia.
Zwłaszcza wtedy, gdy daną decyzję można łatwo odwrócić.
Więc jak ocenić, czy dana decyzja jest właściwa?
Drivery
Kiedy masz wątpliwości, zawsze warto zrobić krok wstecz i spojrzeć szerzej- a to obejmuje:
-
jakie są najważniejsze priorytety naszego biznesu?
-
jakie ograniczenia musimy wziąć pod uwagę?
-
z czego możemy zrezygnować (cele opcjonalne), a czego nie wolno nam poświęcić (cele obowiązkowe)?
Drivery architektoniczne to aspekty, które zmuszają nas do bardzo głębokiego wejścia w konkretny kontekst bardzo konkretnego projektu.
Można o nich myśleć jak o kontekście projektu, który pozwala ocenić, czy dana teoretyczna zaleta lub wada ma w danej sytuacji jakiekolwiek znaczenie.
Architecture drivers mogą być bardzo różne:
-
czas odpowiedzi: system musi reagować bardzo szybko
-
ruch: system musi być przygotowany na duże obciążenie i wysoką liczbę zapytań
-
SLA / HA: czas dostępności musi wynosić ~99,99%
-
skala organizacyjna: system rozwijany przez dziesiątki, a nawet setki programistów
-
poziom wejścia: powinien być stosunkowo łatwy do opanowania dla mniej doświadczonych devów
-
TTM: funkcje muszą być dostarczane bardzo szybko, ze względu na sytuację biznesową (jakakolwiek by nie była)
W środowiskach biznesowych drivery praktycznie zawsze istnieją.
Najprawdopodobniej przedstawiciele Twojej firmy komunikują je wprost, ale nie używają słowa „drivery” dosłownie.
Brak ich identyfikacji znacząco zmniejsza szanse powodzenia projektu, bo możesz skupić się na zupełnie nieistotnych rzeczach.
Jak więc kształtujemy architekturę systemu, by realizować te nadrzędne cele?
Tradeoffy
Musimy zdać sobie sprawę, że nic nie przychodzi za darmo.
Jeśli chcemy zapewnić systemowi jakąś pożądaną cechę, zawsze będzie się to wiązało z kosztem. I musimy mieć świadomość tego kosztu.
Przyjrzyjmy się ponownie liście driverów poniżej i rozszerzmy ją o potencjalne skutki uboczne:
-
system musi odpowiadać bardzo szybko, kosztem zwiększonej złożoności i pogorszonej elastyczności
-
musi obsługiwać ogromny ruch (np. przez skalowanie horyzontalne/automatyczne), kosztem przejścia z architektury monolitycznej na rozproszoną
-
musi mieć dostępność na poziomie ~99,99%, kosztem utrzymywania kosztownych technik, takich jak canary releases, blue/green deployment i inne.
-
musi być rozwijany przez dziesiątki lub setki developerów poprzez tworzenie mniejszych, niezależnych zespołów, kosztem duplikacji kodu/pracy oraz znacznie bardziej złożonej infrastruktury
-
powinien być łatwy do ogarnięcia dla mniej doświadczonych devów → kosztem rezygnacji z narzędzi i technologii, które nasi developerzy, kochają najbardziej.
-
funkcje muszą być dostarczane bardzo szybko, zgodnie z potrzebami biznesu → kosztem narastającego długu technologicznego i tak dalej.
Kompromisy są „proste” o tyle, że możemy świadomie zdecydować, z czego jesteśmy w stanie zrezygnować.
Przykład: Czy naprawdę potrzebujemy dostępności na poziomie 99,99%? – Tak, bo umowa nas do tego zobowiązuje. A czy naprawdę potrzebujemy 80% pokrycia testami? – Fajnie by było, ale nie, nie jest to konieczne. Możemy działać dalej bez tego.
Podejmując decyzje architektoniczne, trzeba skupić się na driverach, ale zawsze mieć w głowie tradeoffy.
Dążymy do realizacji celów, ale wiemy też, co możemy być zmuszeni poświęcić po drodze.
Ograniczenia
Jeszcze jedna oczywistość: nie wszystko da się zrobić.
😉
Czasem nie możemy wdrożyć decyzji, nawet jeśli wszystko wskazuje na to, że byłaby słuszna.
Zewnętrzne ograniczenia mogą stanąć nam na drodze:
-
system musi odpowiadać bardzo szybko, kosztem większej złożoności i mniejszej elastyczności, ale nie możemy przebudować bazy danych… z różnych powodów
-
musi obsługiwać ogromny ruch poprzez skalowanie horyzontalne lub automatyczne, kosztem przejścia z monolitu na system rozproszony, ale nie możemy zmienić dostawcy chmury… z różnych powodów
-
funkcje muszą być dostarczane bardzo szybko, zgodnie z wymaganiami biznesu, kosztem rosnącego długu technologicznego, ale nie możemy zatrudnić więcej developerów, żeby przyspieszyć… z różnych powodów
I to jest ta mniej przyjemna część. Żeby nie było zbyt łatwo – musimy pogodzić się z tym, że nasze możliwości są ograniczone… z różnych powodów 😉.
Ale mimo wszystko nadal chcemy osiągnąć nasze cele!
Podsumowanie
Podsumujmy to szybko: podejmujemy decyzje architektoniczne, mając na uwadze drivery architektoniczne, świadomi tradeoffów tych decyzji i jednocześnie musimy radzić sobie z ograniczeniami.
SPÓJRZ SZERZEJ niż tylko na kod.
