Zostań architektem oprogramowania - ebook

Podziękowania

Najbardziej pamiętnym momentem w trakcie pisania książki był ten, kiedy moja żona i pięcioletni syn pomagali mi znaleźć sposób na uporządkowanie rozdziałów 1 i 2. Pewnego sobotniego ranka Marie zadawała pytania i słuchała moich wyjaśnień, podczas gdy Owen, z długopisem w ręce, przez ponad godzinę pomagał mi zapisywać pomysły na karteczkach samoprzylepnych i przyklejać wokół kuchennego okna. Oboje jesteście niesamowici. Dziękuję za Waszą miłość i cierpliwość.

Nieprzekraczalne terminy rzeczywiście mijają jak z bicza strzelił. Najlepszym nieprzekraczalnym terminem i jedynym, którego nie przegapiłem podczas pisania tej książki, był Finn. Witaj na świecie!

Mamo, tato, Ryan – ta książka była możliwa tylko dzięki Waszemu wsparciu i zachętom przez całe moje życie. Chris i Russ, dziękuję za pomoc w znalezieniu czasu na pisanie (i za lasagne). Lela, dzięki za słuchanie.

Miałem szczęście czerpać wiedzę od wielu inteligentnych architektów i projektantów oprogramowania, którzy bardzo mnie zainspirowali, współpracować i spotykać się z nimi. Należą do nich m.in.: David Garlan, Mary Shaw, George Fairbanks, Len Bass, Rebecca Wirfs-Brock, Simona Brown, Ariadna Fonta, Matt Bass, Toni Lattanze, Dave Root i Ipek Ozkaya.

Miałem armię technicznych recenzentów, którzy dzięki swoim precyzyjnym uwagom poprawili tę książkę. Byli nimi: David Bock, Will Chaparro, Javier Collado, Fabrizio Cucci, George Fairbanks, Kevin Gisi, Thijmen de Gooljer, Rod Hilton, Michael Hunter, Maurice Kelly, Joe Kramer, Nick McGinness, Ryan Moore, David Morgan, Emanuele Origgi, Ipek Ozkaya, Will Price, Antonio Gomes Rodrigues, Jesse Rosalia, Tibor Simic, Stephen Wolff, Eoin Woods, Peter WA Wood i Colin Yates. Dziękuję wszystkim w IBM Pittsburgh za to, że chcieli być królikami doświadczalnymi wielu metod projektowania.

Susannah Pfalzer, najbardziej niesamowitej redaktorce dla początkującego autora, dziękuję za poprowadzenie mnie przez proces pisania i publikowania. Andy i Dave, dziękuję za danie mi szansy na udoskonalenie sposobu, w jaki budujemy oprogramowanie.Przedmowa

Kiedy przygotowywałem ostateczny szkic tej książki, początkowo byłem zaskoczony tym, że nie było w nim żadnej wzmianki o programowaniu zwinnym (ang. agile software development). Michael i ja od lat rozmawialiśmy o tej książce i myślałem, że wiem, o czym ona ma być i dlaczego należało ją napisać: idee architektury oprogramowania, zgodnie z tradycją, były trudne do wykorzystania w procesach Agile, ale Michael znalazł sposób, jak je zastosować. Dlaczego zatem Agile nie miałoby być na każdej stronie książki?

Michael jest współczesnym Prometeuszem, zafascynowanym technologią i zdeterminowanym, by ją oswoić dla całej ludzkości. Głęboko wierzy w korzyści płynące z Agile i jest ekspertem w architekturze oprogramowania. Nie znam nikogo, kto w ciągu dnia wcielałby się w rolę przywódcy zespołu Agile, a w nocy był mentorem dla studentów architektury oprogramowania Carnegie Mellon. Znam go najlepiej dzięki naszemu zaangażowaniu w konferencję SATURN poświęconą architekturze oprogramowania, na którą wniósł idee i przyprowadził przywódców społeczności Agile, z którymi się koleguje w społeczności architektów. Szukał najlepszego z obu światów, mieszanki Agile i architektury niebędącej olejem i wodą.

Były inne próby pogodzenia różnic, ale wszystkie były ograniczone. Na początku próbowano na siłę zastosować Agile w fazie implementacji modelu kaskadowego. Inni bez zastrzeżeń zakładali, że nadal istnieje „najważniejszy architekt” podejmujący najistotniejsze decyzje. Prawie wszystkie opierały się na teorii, a nie na raportach z tego, co zostało z powodzeniem zastosowane, i były pisane przez autora jednego z obozów próbującego wyciągnąć pomysły od tych z drugiego.

Ta książka jest inną, lepszą syntezą Agile i architektury, dlatego słowo „Agile” nie występuje na każdej stronie. Zaczyna się od dogłębnego przedstawienia i docenienia wartości Agile, a następnie opisu kompatybilnych technik projektowania. Michael samodzielnie wymyślił lub zaadaptował wiele technik, ale ekscytuje mnie też to, że wybrał najlepsze pomysły z konferencji z ostatnich kilku lat, nieopisywanych jeszcze w żadnej innej książce. Jeśli rzucimy okiem na część III: Narzędzia architekta, to nie zobaczymy „Wyrytych przez architekta kamiennych tablic z przykazaniami dla zespołu”. Zobaczymy działania, które będą pasować nawet dla tygodniowych iteracji, zachęcających do współtworzenia projektu przez zespół i promujących projektowanie jako priorytetowe zadanie zespołu. Ta część zawiera również przedstawienie zespołów faktycznie stosujących te techniki.

Ci sami liderzy merytoryczni, którzy obalali biurokratyczne procesy tworzenia oprogramowania, ostrzegali nas również, że Agile nie jest kamuflażem dla niezdyscyplinowanego kodowania na zasadzie wolnej amerykanki. Te biurokratyczne procesy sprzed epoki Agile w większości przypadków opierały się na zasadach i wiadomo było, jakie działania projektowe należy wykonywać i kiedy. Mimo że zespoły raportują, iż postępują zgodnie z Agile, z mojego doświadczenia wynika, że niezdyscyplinowane kodowanie zdarza się często.

Skoro ta książka już istnieje, pytanie brzmi: co dalej? Trudno jest to określić, szczególnie odnośnie do tego, co będzie w przyszłości, ale moje przewidywania są następujące. Jesteśmy na progu przejścia do stanu stabilnego rozwoju oprogramowania, w którym nauczyliśmy się mieszać zwinność i dyscyplinę. Nasze procesy będą wykorzystywać pętle szybkiego sprzężenia zwrotnego spopularyzowane przez Agile i poprowadzą nas do projektowania technologii napędzających jakość. Niewątpliwie chodzi tu o procesy, w których będzie się wdrażać działania oraz techniki szczególnie odpowiednie do tworzenia oprogramowania.

Jeszcze nie doszliśmy do tego etapu, ale ta książka wskazuje nam odpowiedni kierunek. Zbudujmy przyszłość, w której chcemy żyć.

George Fairbanks
Autor Just Enough Software ArchitectureWitamy

Architektura oprogramowania to fundament, na którym jest budowane doskonałe oprogramowanie. Sama świetna architektura nie wystarczy, aby zagwarantować, że oprogramowanie będzie sukcesem, ale zła architektura niemal gwarantuje porażkę. Architektura oprogramowania jest tak ważna, że każdy programista powinien wiedzieć, jak ją zaprojektować.

Z tej książki dowiemy się, jak projektować znakomite architektury oprogramowania. Żeby było jasne, to nie jest lekcja abstrakcyjnego projektowania oprogramowania w wieży z kości słoniowej. Nie znajdują się tu też żadne magiczne rozwiązania – frameworki i technologie, które w cudowny sposób rozwiązują każdy problem. Dowiemy się, jak zastosować podstawowe zasady oraz praktyki projektowania, które uczynią nas lepszymi programistami, architektami i liderami technologicznymi.

Projektowanie dobrego oprogramowania wymaga czegoś więcej niż opanowania zasad i praktyk. Sposób projektowania systemu oprogramowania jest tak samo ważny jak końcowy rezultat. Z tej książki dowiemy się, jak używać myślenia projektowego i metod skoncentrowanych na człowieku, aby projektować architekturę oprogramowania we współpracy ze swoim zespołem. Takie podejście pomaga budować silniejszy związek między podejmowanymi decyzjami projektowymi a ludźmi, których dotyczą te decyzje. Umieszczanie ludzi na pierwszym miejscu pozwoli podejmować lepsze decyzje, a w rezultacie tworzyć lepsze oprogramowanie.

Kto powinien przeczytać tę książkę?

Ta książka jest dla każdego, kto kiedykolwiek stanął przy białej tablicy i szkicował pudełka oraz linie, starając się odpowiedzieć na trudne pytania.

Jeśli projektowanie architektury oprogramowania to dla was całkowita nowość, ta książka jest doskonałym wprowadzeniem. Zaczniemy od podstaw i przejdziemy przez elementarne zasady, które należy znać, aby móc stać się niesamowitymi architektami oprogramowania.

Jeśli jesteście programistami, którzy już coś wiedzą na temat architektury, ta książka pomoże wam uporządkować myśli. Podczas lektury znajdziecie koncepcje, które intuicyjnie wyczuwaliście, ale nie mieliście dla nich nazwy, a także znajdziecie luki, o których nawet nie wiedzieliście, że zostały ominięte. Po przeczytaniu tej książki będziecie w stanie wyjaśnić, dlaczego robicie to, co robicie, co pozwoli wam lepiej przewodzić innym.

Jeśli jesteście już architektami oprogramowania i nie jest to wasze pierwsze rodeo, ta książka da wam świeże spojrzenie na to, jak poprowadzić swój zespół. Młodsi programiści w dzisiejszych czasach oczekują, że będą mogli mieć większy wpływ na rozwiązanie programistyczne systemu, które tworzą. Nacisk na podstawy w tej książce przygotuje was do nauczania dzisiejszych programistów – architektów jutra i bycia ich mentorami, aby mogli w pełni uczestniczyć w procesie projektowania. Wspólne metody projektowania opisane w tej książce dadzą nowe techniki bezpiecznej i produktywnej współpracy z mniej doświadczonymi członkami zespołu podczas wspólnego projektowania systemu oprogramowania.

Jak czytać tę książkę

Książka jest podzielona na trzy części. Części I i II są przeznaczone do przeczytania od początku do końca. Część III została zaprojektowana tak, aby łatwo znajdować odwołania.

W części I poznamy podstawy architektury oprogramowania i myślenia projektowego potrzebne, aby stać się architektami.

W części II nabędziemy podstawowe umiejętności i wiedzę, którą powinni posiadać wszyscy architekci oprogramowania.

Część III zawiera zestaw praktycznych metod projektowania architektury. Nie ma cudownych rozwiązań, ale każdy inżynier oprogramowania ma swoją skrzynkę narzędziową wypełnioną praktykami, metodami i technikami, które razem umożliwiają tworzenie zadziwiającego oprogramowania. Metody w części III pochodzą z mojego zestawu narzędziowego i będę miał zaszczyt podzielić się nimi z wami.

Każdy rozdział w częściach II i III koncentruje się na innym sposobie myślenia o projekcie, o czym dowiemy się więcej w rozdziale 2: Podstawy myślenia projektowego na stronie 17. Podstawy w projektowaniu to sposoby myślenia o świecie, które pomagają nam skupić naszą uwagę na właściwych szczegółach we właściwym czasie. Istnieją cztery nastawienia projektowe (ang. design mindsets): rozumienie, badanie, tworzenie i ocenianie. Poszukajcie ikony na początku każdego rozdziału, aby dowiedzieć się, o którym nastawieniu będziemy się uczyć.

Porady i wskazówki od społeczności

Otwierając tę książkę, przystąpiliście do społeczności architektów oprogramowania, którzy pomagają sobie wzajemnie, dzieląc się radami, wskazówkami i dobrymi praktykami. Aby oficjalnie powitać nas w społeczności, poprosiłem innych architektów oprogramowania, żeby przekazali wskazówki i porady, które ich zdaniem należy znać. Znajdują się one w wyróżnionych ramkach w całej książce.

Naszymi wyjątkowymi przedstawicielami tej społeczności są Len Bass, Bett Bollhoefer, Simon Brown, George Fairbanks, Thijmen de Gooljer, Patrick Kua i Ipek Ozkaya. Więcej informacji na ich temat znajduje się w części Dodatek 1, Biografie przedstawicieli społeczności na stronie 331.

Studium przypadku

Mówiąc o abstrakcyjnych rzeczach, bardzo łatwo pozostać abstrakcyjnym. Aby temu zapobiec, dodałem studium przypadku – Projekt Lionheart – oparty na rzeczywistych systemach, nad którymi pracowałem w przeszłości. Studium przypadku zostało przedstawione w rozdziale 1. Przykłady z tego studium będą znajdowały się w kolejnych rozdziałach książki.

A teraz do dzieła – ćwiczenia

Świetni architekci oprogramowania wykonują ciężką pracę. Aby zostać świetnymi architektami oprogramowania, musimy ćwiczyć projektowanie, a nie tylko o nim mówić. Za każdym razem, gdy zostanie umieszczona ta ikona, to będzie czas, aby pomyśleć krytycznie i wprowadzić teorię do praktyki. Jak projektowanie architektury w prawdziwym świecie, tak ćwiczenia A teraz do dzieła mają wiele właściwych odpowiedzi. Sposób dotarcia do odpowiedzi – podróż do niej – jest tak samo ważna jak samo rozwiązanie.

Zasoby online

Ta książka ma własną stronę internetową¹, można tam znaleźć szczegółowe informacje na jej temat, zamieszczać posty na forach dyskusyjnych i zgłaszać błędy, takie jak literówki, i sugestie dotyczące treści. Fora dyskusyjne to idealne miejsce, aby porozmawiać z innymi czytelnikami i podzielić się rozwiązaniami do ćwiczeń.

Witam, dziękuję za przyłączenie się do mnie, zaczynamy!ROZDZIAŁ 1

Zostać architektem oprogramowania

Nie jestem do końca pewien, kiedy zostałem architektem oprogramowania. Pamiętam, kiedy pierwszy raz ktoś mnie tak nazwał. Byliśmy na ważnym spotkaniu z klientem i padło trudne pytanie techniczne. Kierownik projektu wtrącił: Michael jest architektem w tym projekcie. Do końca tygodnia to sprawdzi i wyśle ci aktualizację.

I właśnie tak zostałem architektem oprogramowania. Przypływ mocy. Przewidywanie rozwoju kariery. Jestem architektem! Wkrótce ogarnęło mnie uczucie lekkiego strachu. Jestem architektem. Co mam teraz zrobić? Czym różni się architekt oprogramowania od inżyniera oprogramowania?

Architekci oprogramowania poza samym programowaniem mają wiele innych obowiązków. Definiują problem z perspektywy inżynierskiej. Dzielą oni system na części, które można zaimplementować, ale także, mając obraz ogółu, pilnują, aby system nadal działał jako spójna całość. Architekci decydują o kompromisach między atrybutami jakości i zarządzaniem nieuniknionym wzrostem długu technologicznego. Być może przede wszystkim architekci rozwijają umiejętności architektoniczne zespołu, ponieważ wiedzą, że najlepsze zespoły są pełne architektów.

W tym rozdziale przedstawimy, czym zajmują się architekci. Dowiemy się również, dlaczego znajomość architektury oprogramowania sprawi, że będziemy lepszymi programistami i liderami technologicznymi, oraz jak rozpocząć drogę, aby zostać architektem oprogramowania w swojej karierze zawodowej.

Czym zajmują się architekci oprogramowania?

Architekci oprogramowania są na wyjątkowej pozycji w zespole. Nie są kierownikami projektów, ale mają istotny wpływ na termin i sposób dostarczania oprogramowania. Nie są menedżerami produktu, ale odpowiadają za to, że oprogramowanie spełnia swoje cele biznesowe. Programują, ale zarazem projektują coś więcej niż tylko algorytmy i kod. Architekci oprogramowania mają wyjątkowy zestaw obowiązków i faktycznie znajdują się w centrum wszystkiego.

Większość z nas rozpoczyna karierę programistyczną, koncentrując się wyłącznie na technologii. Umiejętność programowania, projektowania skutecznych algorytmów, sprawdzania, czy wszystko działa, a także wdrażania oprogramowania – to podstawowe umiejętności dla architektów oprogramowania. Przejście od programisty do architekta oprogramowania wymaga zaakceptowania nowych obowiązków.

Definiowanie problemu z perspektywy inżynierskiej

Projektowanie architektury oprogramowania jest dyscypliną skoncentrowaną na człowieku. Każdy, kto ma udział w oprogramowaniu, może pomóc w zrozumieniu, czego się od tego oczekuje. Architekci oprogramowania współpracują z menedżerami produktu, kierownikami projektów i innymi interesariuszami, aby określić cele biznesowe i wymagania dotyczące oprogramowania, które ma zostać zbudowane.

W wielu zespołach menedżerowie produktu definiują funkcjonalności. Są one istotne, ale istnieje inny rodzaj wymagań zwany atrybutami jakościowymi, o które architekci dbają najbardziej (patrz Po co stosować atrybuty jakościowe (i inne właściwości systemu), na stronie 10). Oprócz definiowania atrybutów jakościowych systemu architekci zwracają uwagę na ograniczenia projektowe i funkcjonalności, które mogą wymusić na nas określoną ścieżkę architektoniczną.

Definiowanie problemu z myślą o architekturze pozwala zbudować taki system, na jaki każdy czeka. W rozdziale 5: W poszukiwaniu wymagań istotnych dla architektury na stronie 55 dowiemy się, jak architekci podchodzą do wymagań.

Podział systemu i przypisanie odpowiedzialności

Czy kiedykolwiek widzieliście, jak małe dzieci grają w piłkę nożną? Jedyny brzdąc, który pozostaje na pozycji, to bramkarz, przyklejony do bramki swojej drużyny, podczas gdy inne dzieci całą gromadą gonią za piłką z jednego końca pola na drugi. To urocze. Kiedy dzieci trochę dorosną, uczą się rozgrywać na ustawionych pozycjach. Granie na pozycjach jest ważne, ponieważ pozwala trenerowi stworzyć strategię gry, która zwiększa prawdopodobieństwo zdobycia gola przez drużynę.

Niektóre systemy software’owe są zaprojektowane jak dziecięca drużyna piłkarska: jedna wielka grupa oprogramowania goniąca za wydaniem. Tworzenie oprogramowania, podobnie jak w rozgrywkach piłkarskich, przebiega płynniej, gdy oprogramowanie jest podzielone na części, a każdy element ma przypisaną odpowiedzialność, pozycję do grania.

Architekci partycjonują (fantazyjne słowo oznaczające dzielenie na części) system software’owy, dzięki czemu mogą opracować strategię osiągnięcia atrybutów jakościowych i innych wymagań systemowych. Na przykład można podzielić zakres funkcjonalności przez zaprojektowanie jednego komponentu w celu rejestrowania użytkowników, a innego do identyfikacji zdjęć kotów. Lub też można przypisać różne zespoły, aby opracowywały różne moduły, albo też oddzielić rzeczy, które odczytują dane, od rzeczy zapisujących dane, tak aby system oprogramowania był bardziej niezawodny, dostępny i skalowalny.

Partycjonowanie systemu jest ważne nie tylko dlatego, że pozwala opracować strategię osiągnięcia atrybutów jakościowych. Mniejsze fragmenty są łatwiejsze do przemyślenia, łatwiej je przetestować i zaprojektować. Oczywiście, ponieważ podzieliliśmy system na kawałki, musimy również upewnić się, że wszystko się ze sobą poskłada.

Posiadanie szerszego spojrzenia

Każdy system software’owy funkcjonuje w kontekście większego świata. Świat, w którym żyje oprogramowanie, to użytkownicy wchodzący z nim w interakcje, budujący je zespół, sprzęt, na którym działa, a nawet, na pierwszym miejscu, cel stworzenia oprogramowania. Idealnie, architektura powinna żyć w harmonii z tym szerszym kontekstem.

Myślenie o systemie jako całości oznacza, że architekci mają do czynienia z czymś więcej niż tylko technologią. Ludzie, procesy, potrzeby biznesowe i wiele innych czynników technicznych i nietechnicznych odgrywa rolę w ostatecznym systemie software’owym. Nawet proste decyzje projektowe mogą mieć daleko idące konsekwencje. Architekci muszą wychodzić poza bliskie sąsiedztwo decyzji projektowych i myśleć o systemie jako o całości.

Projektowanie oprogramowania to nieustanna walka o znalezienie właściwej równowagi między rzeczami, których chcemy, a rzeczywistością, którą musimy zaakceptować. Oznacza to, że trzeba o tym myśleć i iść na kompromisy.

Wybieranie kompromisów między atrybutami jakościowymi

Powiedzmy, że wysoka dostępność to ważny atrybut jakościowy dla naszych interesariuszy i potrzebujemy oprogramowania, które będzie odpowiadać na 99,9% żądań. Jednym ze sposobów na zapewnienie dostępności jest wprowadzenie redundantnych elementów. Projektowanie tego jest proste, ale istnieje pewien haczyk. Musimy teraz kupić dwa razy więcej sprzętu, co podwoi nasze koszty. W tym przypadku zwiększone zostały koszty, aby uzyskać wyższą dostępność.

Zrezygnowanie z czegoś, by dostać coś, czego potrzebujemy, jest powszechne w rozwoju oprogramowania. Architekci identyfikują kompromisy i pracują z interesariuszami, aby zdecydować, które kompromisy mają największy sens.

Systemy software’owe nigdy nie są idealnie partycjonowane. Idziemy na kompromisy. Popełniamy błędy. W miarę budowania systemu wprowadzamy do architektury dług technologiczny.

Zarządzanie długiem technologicznym

Architekci oprogramowania znają szczegóły dotyczące zależności w systemie. Dostrzegają większą całość i wiedzą, jak to wszystko połączyć. Wiążą także decyzje technologiczne z potrzebami biznesowymi. Wiedza o tym wszystkim stawia architektów w doskonałej pozycji do zarządzania długiem technologicznym.

Dług technologiczny to różnica pomiędzy aktualnym projektem systemu software’owego a projektem, którego potrzebujemy, abyśmy mogli nadal dostarczać określone wartości. Możemy zmierzyć wielkość długu technologicznego, szacując wysiłek wymagany do zniwelowania tej różnicy. Wszystkie programy mają dług technologiczny. Dług technologiczny jest nieuniknionym produktem ubocznym sukcesu. Najlepsze zespoły zajmujące się tworzeniem oprogramowania strategicznie wykorzystują dług technologiczny, by szybciej dążyć do celu i regularnie go zmniejszają, aby zapewnić ciągłe dostarczanie odpowiednich wartości.

Architekci uwidaczniają dług technologiczny i pomagają zainteresowanym stronom zdecydować o tym, jakie działania należy podjąć, aby nim zarządzać.

Rozwijanie umiejętności architektonicznych zespołu

Architekci oprogramowania są nauczycielami i mentorami dla swoich zespołów. Nie ma sensu projektować niesamowitej architektury, której nikt nie może zrozumieć. Obowiązkiem architektonicznego eksperta w swoim zespole jest dzielić się z nim swoją wiedzą, aby można było z powodzeniem tworzyć zadziwiające systemy software’owe.

Architekci uczą umiejętności projektowania i koncepcji architektonicznych dokładnie na czas. Aby przekazać swoją wiedzę, będziemy musieli łączyć projekt z członkami zespołu, tworzyć dokumenty, które będą kształcić i informować, oraz dzielić się konstruktywną krytyką. Być może najważniejszą rzeczą, jaką trzeba będzie zrobić, aby rozwinąć umiejętności architektoniczne zespołu, to włączenie go w proces projektowania. Architektura to działalność społeczna. Rozwój umiejętności jest kluczowy dla sukcesu naszego zespołu.

Teraz już wiemy, co robią architekci, ale jeszcze nie zdefiniowaliśmy, co rozumiemy przez architekturę oprogramowania. Zróbmy coś z tym teraz.

Czym jest architektura oprogramowania?

Architektura oprogramowania systemu jest zbiorem istotnych decyzji projektowych dotyczących organizacji oprogramowania w celu wspierania jego pożądanych atrybutów jakościowych i innych właściwości.

Decyzja projektowa może być ważna z wielu powodów. Może stać się punktem bez powrotu lub wpływać na atrybuty jakościowe, harmonogram lub koszty. Znacząca decyzja może dotyczyć wielu osób lub zmusić do zmiany inne systemy oprogramowania. W każdym przypadku znaczące decyzje projektowe są kosztowne, jeśli chcielibyśmy je później zmieniać, gdyby zostały błędnie podjęte.

Wspieranie atrybutu jakościowego oznacza zachęcanie, aby pojawił się on w systemie oprogramowania. W dobrze zorganizowanej architekturze będzie to wspierać atrybuty jakościowe, które są pożądane przez zainteresowane strony, oraz zminimalizuje lub wyeliminuje te, których nie chcą zainteresowane strony. Architektura może również wspierać inne właściwości. Na przykład odpowiednia organizacja pracy pozwoli na dostarczenie oprogramowania na czas, w ramach budżetu i bez nadmiernych nadgodzin.

Definiowanie podstawowych struktur

Wieżowiec ma fundament i konstrukcję. Ciało ma kości. Oprogramowanie ma struktury. Struktura określa sposób, w jaki system software’owy jest zorganizowany. Struktury są w kodzie, który piszemy, oprogramowaniu, które uruchamiamy, a nawet we współpracy z innymi ludźmi.

Aby utworzyć strukturę, weź dowolny element i połącz go z innym elementem za pomocą związków. Pomyśl o elementach i związkach jak o cegłach i zaprawie oprogramowania. Chleb i masło orzechowe. Taśma klejąca i … cóż, pewnie będziesz mieć jakiś pomysł. Elementy są fundamentalnymi cegiełkami oprogramowania. Związki opisują, w jaki sposób elementy współpracują ze sobą, aby wykonać pewne zadanie.

Łatwo zaprojektować architekturę na papierze bez związku z rzeczywistością. Aby uniknąć tej pułapki, będziemy budować architektury, używając trzech rodzajów elementów i związków. Software Architecture in Practice definiuje te trzy rodzaje jako moduł, komponent i łącznik (ang. component and connector, C&C>) oraz alokację. Aby utworzyć strukturę, należy połączyć elementy i związek tego samego typu.

Oto kilka przykładowych elementów i relacji każdego typu.

--------------------- ---------------------------------------------------------------------------------------------- ----------------------------------------------------------------
Przykładowe elementy Przykładowe związki
Moduł klasa, pakiet, warstwa, procedura składowana, moduł, plik konfiguracyjny, tabela bazy danych używa, może używać, zależy od
Komponent i łącznik obiekt, połączenie, wątek, proces, warstwa, filtr wywołanie, subskrybcja, potok, publikowanie, zwrot
Alokacja serwer, czujnik, laptop, load balancer, zespół, Owen (osoba), kontener Dockera działa w lub na, odpowiedzialny za, tworzy, przechowuje, płaci
--------------------- ---------------------------------------------------------------------------------------------- ----------------------------------------------------------------

Pyta Joe:

Czy moduły i komponenty to różne byty?

W karierze programistycznej możemy usłyszeć słowa moduł i komponent używane zamiennie i w różnych kontekstach. Z technicznego punktu widzenia komponent to inne pojęcie niż moduł. Moduł odnosi się do elementu na etapie projektu, podczas gdy komponent jest ideą środowiska wykonawczego.

Czasami ta precyzja w języku jest ważna. Używanie terminu o określonym znaczeniu do opisania czegoś ogólnego może wywołać zamieszanie. Za każdym razem, gdy zechcesz generycznie opisać blok architektury, zamiast określać go jako komponent lub moduł, użyj słowa element.

Podsumowując, kłótnie na temat semantyki nie są najlepszym sposobem na przeforsowanie swoich pomysłów. Zachęcam cię do stosowania właściwej i precyzyjnej terminologii, gdyż z czasem twoje pomysły łatwiej będzie zrealizować, jeśli dostosujesz swój język tak, aby inni cię zrozumieli.

Struktury modułowe istnieją na etapie projektowania. Pozostajemy w interakcji ze strukturami modułowymi podczas pisania kodu. Istnieją one w systemie plików i przebywają tam, nawet jeśli oprogramowanie nie jest uruchomione.

Struktury komponentowe i łącznikowe (ang. component and connector structures, C&C) pojawiają się w środowisku wykonawczym. W czasie wykonywania komponenty mogą tworzyć połączenia z innymi komponentami, nowe procesy i instancje nowych obiektów. W przeciwieństwie do struktur modułowych struktury C&C przestają istnieć, gdy system nie jest uruchomiony. Istnienie struktur C&C możemy dostrzec tylko w pozostawianych artefaktach, takich jak plik z logami lub wpis w bazie danych.

Struktury alokacji (ang. allocation structures) są tworzone przez pokazanie, w jaki sposób moduł i elementy C&C korelują ze sobą oraz z fizycznymi elementami istniejącymi w rzeczywistości. Struktury alokacji są czasami nazywane strukturami mapowania, ponieważ pokazują, w jaki sposób poszczególne elementy odnoszą się do innych. Czy element działa na komputerze klienta lub serwerze? Które zespoły budują które części systemu? Struktury alokacji pomagają nam odpowiedzieć na takie pytania.

Różne rodzaje struktur przydają się do myślenia o różnych właściwościach, które chcemy mieć w swoim systemie. Na przykład możemy myśleć o testowalności i zarządzalności przy użyciu struktury modułowej. Struktura C&C pomaga nam zastanawiać się nad oczekiwaniami dotyczącymi środowiska wykonawczego, takimi jak dostępność lub wydajność. Być może zorientujemy się, że istnieje luka w naszym rozumieniu, jeśli zauważymy struktury mieszane, takie jak element statyczny, który używa związku dynamicznego.

Struktury określają kształt naszego systemu. Kształt jest ważny, ponieważ decyduje o atrybutach jakościowych i innych właściwościach, których będą doświadczać użytkownicy. W następnym podrozdziale zobaczymy, jak używać struktur do decydowania o atrybutach jakościowych, ale najpierw czas zabrać się do roboty za pomocą prostego ćwiczenia.

A teraz do dzieła: elementy, związki i struktury

Znajdź kilku członków zespołu z ostatniego projektu. Pracując samodzielnie, zróbcie listę lub naszkicujcie struktury modułów, komponentów i połączeń oraz ich alokacji z tego projektu. Pokażcie swoje listy między sobą. Jak wypada to porównanie? Czy są struktury, które nie zostały zidentyfikowane przez ciebie, a zostały przez członków zespołu? Omówcie podobieństwa i różnice w strukturach zidentyfikowanych przez różnych członków zespołu.

Oto kilka rzeczy do przemyślenia:

- Bądź konkretny podczas nazywania elementów. Nie zapomnij o związkach!
- Zastanów się nad strukturami modułów. Jakie metody lub klasy są używane? Czy klasy znajdują się w różnych pakietach lub przestrzeniach nazw? Jakie zależności są zawarte w menedżerach pakietów lub skryptach budowania?
- Pomyśl o strukturach C&C. Czy oprogramowanie wchodzi w interakcje z innymi procesami lub systemami w trakcie działania? Kto odwołuje się do systemu i jak zmieniają się jego odpowiedzi?
- Zastanów się nad alokacją struktur. Kto jest odpowiedzialny za budowanie różnych części oprogramowania? Jak wdrażane jest oprogramowanie?

Po co stosować atrybuty jakościowe (i inne właściwości systemu)

Załóżmy, że tworzymy aplikację kalkulatora i chcemy dodać dwie liczby. Wydaje się łatwe, prawda?

Chwila. Czy zależało nam na kalkulatorze, który dodaje dwie liczby i jest szybki, niezawodny, skalowalny i łatwy w utrzymaniu? Dlaczego nikt tego nie powiedział!? Gdybyśmy nie spytali o te cechy jakościowe, moglibyśmy zaprojektować zupełnie niewłaściwy system.

Atrybut jakościowy to jakakolwiek zewnętrznie widoczna cecha, dzięki której interesariusze oceniają wartość systemu oprogramowania. Przykłady obejmują skalowalność, dostępność, łatwość konserwacji i testowalność. Doświadczamy tych cech jakościowych podczas interakcji z oprogramowaniem.

Po wybraniu struktury architektonicznej określamy atrybuty jakościowe, na które ma być położony nacisk w systemie software’owym. Myśląc o architekturze oprogramowania, trzeba się upewnić, że projektujemy system oprogramowania, który będzie zapewniał pożądane atrybuty jakościowe, pośród wszystkich innych potrzeb wymagających uwagi.

Atrybuty jakościowe sprawiają, że oprogramowanie jest wyjątkowe. Okoliczności każdego systemu są różne – inny zespół, inny budżet, różne warunki rynkowe, nawet różne trendy technologiczne. W rezultacie nigdy nie będzie dwóch identycznych architektur, nawet jeśli zestawy funkcjonalności są identyczne.

Gotowi stawić czoła wyzwaniu? W następnej części poznamy kilka strategii, aby móc stać się architektem swojego zespołu.

Zostańmy architektami w naszym zespole

W niektórych zespołach architekt jest oficjalną funkcją w zespole. W innych nie ma takiej roli i członkowie zespołu dzielą jego obowiązki. Czasem zespoły mówią, że nie mają architekta, ale jeśli przyjrzymy się uważnie, ktoś wypełnia obowiązki architekta, nie zdając sobie z tego sprawy.

Architekci są liderami, ale bycie architektem oprogramowania również oznacza osobę, która myśli o projektowaniu oprogramowania w określony sposób. Niezależnie od tego, co zawiera tytuł wizytówki (mój nadal wskazuje inżyniera oprogramowania, to mój wybór), można być architektem oprogramowania. Każdy zespół ma co najmniej jednego architekta. Najlepsze zespoły mają ich kilku.

Jeśli nasz zespół nie ma architekta, masz pracę! Nie potrzebujesz pozwolenia na włączanie myślenia architektonicznego w dyskusje projektowe naszego zespołu. Zacznijmy zadawać pytania dotyczące atrybutów jakościowych. Wskażmy, kiedy zespół osiąga kompromisy. Zgłośmy się, aby opisywać decyzje projektowe i zacznijmy akceptować więcej obowiązków związanych z projektowaniem architektury.

Jeśli nasz zespół ma już architekta, spytajmy tej osoby, w jaki sposób możemy jej pomóc. Jeśli to możliwe, ściśle współpracujmy z architektem i wykorzystajmy każdą możliwą okazję do nauki. Opracowanie systemu software’owego to wielka praca. Im więcej osób zwraca uwagę na szczegóły, tym większa szansa na sukces. Każdy zespół powinien być szczęśliwy, mając wielu doświadczonych architektów oprogramowania!

Zróbmy krok od programisty do architekta oprogramowania

Przeciętny architekt oprogramowania ma w dorobku od trzech do pięciu systemów z rosnącą odpowiedzialnością techniczną w każdym z nich. W zależności od budowanego oprogramowania i wraz ze zwiększaniem się liczby obowiązków architektonicznych ma mniej czasu na programowanie. Jest to normalne, chociaż architekci oprogramowania nigdy nie powinni całkowicie przestać programować.

Aby zmierzyć swój rozwój od programisty do architekta oprogramowania, utwórzmy portfolio projektów. Dla każdego stworzonego systemu oprogramowania, bez względu na swoją rolę, krótko opiszmy ten system i to, czego udało nam się nauczyć w tym czasie. Ten rodzaj refleksji jest niezbędny dla wszystkich liderów technologicznych, ale przede wszystkim dla architektów oprogramowania.

Oto kilka pytań, na które należy odpowiedzieć na temat każdego projektu ze swojego portfolio:

- Kim byli interesariusze i jakie były główne cele biznesowe?
- Jak wyglądało wysokopoziomowe rozwiązanie?
- Jakie technologie zostały użyte?
- Jakie były największe zagrożenia i jak udało nam się je pokonać?
- Gdyby można było to zrobić od początku, jak można by było to zrobić inaczej?

Niezależnie czy celem jest awans, czy też po prostu rozwój zawodowy, trzeba być cierpliwym. Szansa na zaprojektowanie systemu oprogramowania o znaczącej złożoności zazwyczaj pojawia się tylko raz na trzy do pięciu lat. Jeśli mamy szczęście, przez całą karierę zobaczymy od 8 do 15 systemów oprogramowania. Trzeba być przygotowanym, aby wykorzystać pojawiające się możliwości tworzenia architektury. Współpracujmy z członkami zespołu, aby dać każdemu szansę na rozwój swoich umiejętności. Obiecuję, że praca architekta jest dla wszystkich bardziej niż interesująca!

Pamiętajmy zawsze, że architekt oprogramowania to sposób myślenia, a nie tylko rola w zespole. Kiedy jesteśmy programistami, podejmujemy dziesiątki decyzji związanych z projektowaniem. Niektóre z tych decyzji mają znaczenie architektoniczne. Każdy, kto podejmuje decyzję, która wpływa na strukturę oprogramowania, staje się architektem pro tempore. Od nas zależy, czy podejmiemy dobre decyzje i zachowamy integralność architektoniczną, niezależnie od tego, co jest napisane na naszej wizytówce.

Budowanie niesamowitego oprogramowania

Jest wiele rzeczy, które muszą się udać podczas budowania systemu software’owego. Architektura łączy je wszystkie razem i stanowi podstawę sukcesu. Oto sześć sposobów ułatwiających zbudowanie przez architekturę oprogramowania spektakularnego oprogramowania, które interesariusze pokochają:

1. Architektura oprogramowania przekształca duży problem w mniejsze, łatwiejsze w zarządzaniu.

Nowoczesne systemy oprogramowania są duże, złożone i mają wiele współdziałających fragmentów. Architektura precyzyjnie wyjaśnia, w jaki sposób podzielić system na mniejsze fragmenty o niewielkich rozmiarach, jednocześnie zapewniając, że system jako całość stanowi większą wartość niż suma jego części.

2. Architektura oprogramowania pokazuje ludziom, jak współpracować.

Rozwój oprogramowania jest związany tak samo z komunikacją międzyludzką, jak i z technologią. Architektura oprogramowania opisuje, jak spaja się cały system, włączając w to też ludzi, którzy go tworzą. Gdy znamy architekturę, wtedy możemy zobaczyć, jak ludzie mogą współpracować przy tworzeniu oprogramowania. Im większy system oprogramowania, tym staje się to ważniejsze.

3. Architektura oprogramowania zapewnia terminologię do mówienia o złożoności pomysłów.

Jeśli nie rozumiemy, o czym mówimy, nie będziemy mogli współpracować. Zamiast spędzać cały czas na wymyślaniu słownictwa i pojęć, możemy wykorzystać podstawowe pojęcia i podstawową terminologię architektury jako fundament współpracy. Wtedy możemy spędzić czas, rozwiązując prawdziwe problemy naszych użytkowników.

4. Architektura oprogramowania wykracza poza cechy i funkcjonalność.

Cechy i funkcjonalności są ważne, ale to nie jedyna rzecz, która określa, czy oprogramowanie jest niesamowite. Projektując architekturę, bierzemy pod uwagę nie tylko cechy, lecz także koszty, ograniczenia, harmonogramy, ryzyko, zdolność zespołu do wykonania, a przede wszystkim atrybuty jakościowe – takie jak skalowalność, dostępność, wydajność i łatwość utrzymania.

5. Architektura oprogramowania pomaga uniknąć kosztownych błędów.

W Who Needs an Architect? , Martin Fowler definiuje architekturę oprogramowania: „to ważna rzecz. Cokolwiek nią jest”. Ważne rzeczy są prawie zawsze tym, co uważamy za trudne do zmiany bez znaczącego zwiększenia złożoności. Grady Booch nawiązuje do opinii Fowlera, definiując architekturę jako „istotne decyzje projektowe (gdzie istotność jest mierzona kosztem zmian)”². Architekci oprogramowania nie są wszechwiedzący, ale zaprojektowanie architektury pomoże odkryć trudne (i interesujące) części problemu, które mogą później sprawiać duże kłopoty.

6. Architektura oprogramowania umożliwia zmienność.

Oprogramowanie powinno reagować na zmiany jak woda, z łatwością pokonując przeszkody. Jeśli oprogramowanie jest jak woda, zdolne przybrać dowolny kształt, architektura oprogramowania to pojemnik, który je przechowuje. Ten pojemnik może być sztywny jak pudełko lub elastyczny jak plastikowa torba. Może być gruby i ciężki lub lekki. Bez architektury oprogramowanie, podobnie jak woda, podąża ścieżką najmniejszego oporu i niekontrolowanie się rozwija. Architektura systemu oprogramowania zapewnia strukturę, w ramach której zmiana jest możliwa.

Przez resztę książki będziemy rozwijać te stwierdzenia.

Studium przypadku: Projekt Lionheart

Po omówieniu nowych idei w poszczególnych rozdziałach zastosujemy je do studium przypadku – Projektu Lionheart. Opiera się ono na prawdziwym systemie, ale nazwy i sytuacje zostały zmienione w celach dydaktycznych i prawnych.

Projektowanie architektury w celu rozwiązania tego problemu

Miasto Springfield stoi w obliczu braków w budżecie i konieczności ograniczenia kosztów. Burmistrz Jean Claude van Damme (bez związku z bohaterem kina akcji) zatrudnił nasz zespół do usprawnienia Biura Zarządzania i Finansów (BZF).

Kiedy pracownik miejski musi kupić coś za więcej niż kilka tysięcy dolarów, BZF publikuje Zapytanie Ofertowe (ZO) w lokalnej gazecie. Przedsiębiorcy składają oferty w odpowiedzi na ZO, a BZF podpisuje umowę na podstawie konkurencyjności oferty i innych czynników. BZF monitoruje ponad 500 aktywnych umów i zapytań ofertowych dotyczących wszystkiego, od papieru toaletowego przez artykuły medyczne aż po piłki do koszykówki. BZF zarządza wszystkimi tymi danymi za pomocą arkuszy kalkulacyjnych.

Burmistrz van Damme ma nadzieję, że unowocześnienie BZF poprawi kilka strategicznych obszarów.

- Dla ponad połowy wszystkich ZO została złożona jedna oferta. Potencjalnie miasto przepłaca za usługi o niższej jakości.
- Finalizacja umowy trwa miesiącami. Wiele firm gubi się w tym wieloetapowym procesie.
- Publikacja nowego ZO zajmuje do 6 tygodni. Ten proces musi być krótszy.

W części II omówimy to studium przypadku i wspólnie opracujemy potencjalną architekturę, aby rozwiązać niektóre z tych problemów.

Co dalej

Architekci oprogramowania są odpowiedzialni za całkiem sporo rzeczy. Projektowanie ciekawych, złożonych systemów oprogramowania i praca z różnymi ludźmi dają dobre samopoczucie i są warte wysiłku. Architektem oprogramowania nie zostanie się w jedną noc. Staniemy się świetni, jeśli będziemy skupiać się na głównych zadaniach architekta i zrobimy to, co w naszej mocy, aby zastosować podstawy architektoniczne polegające głównie na wyborze struktur, które będą sprzyjać pożądanym atrybutom jakościowym.

W tym rozdziale zostało przedstawione, czym jest architektura i czym zajmują się architekci. W następnym rozdziale dowiemy się, jak używać myślenia projektowego, aby zorientować się, co powinno stać się składnikiem architektury.