Spójność koncepcyjna oznacza, że centralne dla systemu elementy współpracują jako jednolita, spójna całość. Komponenty pasują do siebie i sprawnie współpracują; architektura osiąga równowagę między elastycznością, utrzymywalnością, efektywnością i responsywnością. Mary & Tom Poppendieck Każda architektura to projekt, ale nie każdy projekt to architektura. Architektura reprezentuje znaczące decyzje mające wpływ na kształt systemu, gdzie to znaczenie jest mierzone kosztem zmiany. "Architektura" to termin, który wiele osób stara się zdefiniować, ale trudno wypracować jedną definicję. Są dwa wspólne elementy: pierwszym jest w y s o k o p o z i o m o w y podział systemu na części; drugi - decyzje, które ciężko zmienić. Martin Fowler, PoEAA Grady Booch Z perspektywy zmiany, rola architektury w zwinnym rozwoju oprogramowania staje się zupełnie jasna: dobra architektura jest responsywna i wspiera zwinność; kiepska będzie się opierać i ją ograniczać. Kevlin Henney Ewolucja Architektury Paweł Lipiński pawel.lipinski@pragmatists.pl
pawel@nyac:/etc$whoami >13 lat jako programista >10 lat w Javie SCJP, SCWCD, SCBCD, SCEA zajmowałem się : developmentem, consultingiem, szkoleniami, audytami, architekturą, prowadzeniem zespołów metodyki: cowboy coding, FDD, Scrum (CSP), XP aktualnie: developer, coach & właściciel @ Pragmatists zainteresowania: (A)OO, agile, zapewnianie jakości oprogramowania, języki http://blog.pragmatists.pl http://blog.pawellipinski.com
Akceptuj zmieniające się wymagania nawet na zaawansowanych etapach projektu. Zwinne procesy wykorzystują zmiany dla uzyskania przewagi konkurencyjnej klienta. Najlepsze architektury, wymagania i projekty powstają w samoorganizujących się zespołach. agile manifesto, zasady #2 & #11
zwinna architektura
projektowanie systemu należy do zespołu, który go tworzy świadome decyzje wymagają danych - te pojawiają się w czasie tworzenia systemu decyzje podejmowane są przez zespół - wzmaga to odpowiedzialność i zaangażowanie oraz zwiększa szanse na to, że decyzje te będą lepsze by architektura mogła ewoluować, architekt (rola) musi być świadomy następstw i kosztów zmian - te zna tylko zespół
wybierz najprostszą architekturę, jaka może zadziałać gdy założymy, że architektura ewoluuje wraz z rozwojem systemu, możemy też założyć, że ma ona wspierać wyłącznie te własności które są niezbędne TERAZ i których wymagalności jesteśmy absolutnie pewni (YAGNI) czym prostsza architektura, tym łatwiej zapanować nad nią zespołowi czym większy zespół tym bardziej jest to prawdą
kod prawdę Ci powie ewolucja architektury, projektu, kodu to ciągła refaktoryzacja, nieprzerwane próby i testy prowadzące do właściwego rozwiązania czasem trzeba spróbować paru różnych podejść by empirycznie sprawdzić które jest lepsze to najlepszy sposób pozyskiwania wiedzy i doświadczenia architektonicznego
Test-Driven Architecture testy wydajności i stabilności weryfikują poprawność architektury (odpowiedniość względem wymagań niefunkcjonalnych) by można było wykryć niedociągnięcia, muszą być one wykonywane ciągle i często (CI) testy mogą więc prowadzić architekturę podobnie jak prowadzą projekt
czym wyżej chcesz skoczyć, tym większy weź rozbieg pewne rzeczy da się założyć już na początku, by uniknąć później niepotrzebnych przeróbek pewne rzeczy wynikają z doświadczenia i nie ma sensu weryfikować rzeczy które z niego w jasny sposób wynikają czasem last responsible moment to sam początek projektu jeśli trzeba podjąć jakąś decyzję, a mamy komplet danych, nie ma sensu udawać, że nie wiemy co zrobić
architektura powstaje przez współpracę czasem to jest wspólna praca na poziomie zespołu developerskiego przy dużych systemach jest to praca architekta z team lead ami, biznesem, change managementem, itp. itd. by zweryfikować poprawność architektury - to TDA, gdzie testami są stanowiska, wymagania i oczekiwania wszystkich zaangażowanych stron dalej jest to praca zespołowa - tym razem jednak decyzje podejmowane są w zespole architektonicznym
jak to wygląda w praktyce? wstępna wizja ewaluacja i zmiany rozwój oprogramowania architekt systemowy zespół architektury: architekt + programiści zespoły programistyczne
jaka powinna więc być zwinna architektura? powinna zachęcać do zmian - musi modyfikowalna więc być rozszerzalna i powinna promować jakość - dbać o testowalność, czytelność, pewność promować tworzenie wartości - ułatwiać dodawanie funkcjonalności, umożliwić regularne prezentacje nowych funkcji umożliwiać badania - programiści powinni zawsze mieć możliwość sprawdzania różnych podejść, weryfikacji swoich idei być samodokumentująca się - architektura jest w kodzie, im czytelniejszy jest on na wysokim poziomie, tym mniej trzeba opisywać (czasem nawet same nazwy pakietów wystarczają do opisania architektury...)
5 głównych zasad Ekonomia - KISS Wyrażanie intencji Separation of concerns Symetria - schematy, łatwość zrozumienia Wyłanianie się - zespołowość
architektura to taki sam aspekt projektu jak każdy inny podlega tym samym siłom i zasadom iteracyjność, komunikacja (zwrotna), równomierne rozłożenie decyzji/ryzyka w projekcie sprzyja reagowaniu na zmiany
architektura to nie dokument czy zalecenia, lecz efekt długotrwałego procesu, który zaczyna się od wstępnych założeń, a potem w czasie rozwoju systemu reaguje na nowo nadchodzące dane i dostosowuje się do nich to komunikat o aktualnym stanie systemu, wspólna wiedza zespołu podlegająca ciągłej ewolucji architektura jako taka nie ma wartości dla klienta, jest jednak ona elementem obniżania kosztów utworzenia tej wartości
One of the more insidious and persistent myths of agile development is that upfront architecture and design are bad; that you should never spend time up front making architectural decisions. That instead you should evolve your architecture and design from nothing, one test-case at a time. Pardon me, but thatʼs Horse Shit. (...) Donʼt feel that TDD is the only way to design. On the other hand, donʼt let yourself get too vested in your designs. Allow TDD to change your plans if it leads you in a different direction. Robert C. Martin, ObjectMentor blog, The Scatalogy of Agile Architecture, 25.04.2009
Dziękuję (Q&A) pawel.lipinski@pragmatists.pl http://www.pragmatists.pl