Czysta architektura i SOLID okiem ekipy migawka.it

To najpotężniejsze narzędzie jakim dysponują obecnie deweloperzy. SOLID jest niezbędnym budulcem umożliwiającym organizację kodu w jednostki i definiowanie zależności między nimi.

Zasady SOLIDa wspierają budowanie czystej architektury na poziomie samego kodu. Są dla mnie czymś, do czego cały czas dążymy w naszym programistycznym życiu. Ideału pewnie nigdy nie osiągniemy 😉

Koncepcja czystej architektury połączona z metodologiami zwinnymi pomaga zdefiniować w projekcie miejsca, na które powinieneś przeznaczyć więcej czasu, przemyśleć, ubrać we wzorce, zwyczajowo – „pocisnąć”, a gdzie możesz odpuścić.

To sposób zyskiwania czasu na ważne decyzje. W praktyce sprowadza się do tego, że jesteśmy wstanie napisać większość kluczowych części naszego systemu zanim dodamy do aplikacji jakikolwiek framework, czy bazę danych.

Jest to swoista dychotomia. Z jednej strony narzuca sztywne granice podziału komponentów i modułów, wymaga planowania. Z drugiej daje wolność działania wewnątrz „kręgów”. Dzięki temu zespół może opracować własne zasady pracy z kodem, uwzględniając rozwijalność, dostarczalność i utrzymywalność

Kiedyś nie wyobrażałem sobie jak takie coś osiągnąć, ale tak, możemy, a nawet powinniśmy pisać aplikację bez bazy danych czy frameworków. Czysta architektura pokazuje nam jak to zrobić. Dzięki temu, gdy już będziemy wybierać bazę lub framework, będziemy mieli dużą wiedzę na temat naszego kodu. Co więcej będziemy mogli przetestować wydajność różnych rozwiązań bazując na naszym, napisanym już kodzie. Wybór narzędzi przestaje być przypadkiem, jest świadomą decyzją opartą na wiedzy.

Świadomy i dobry rzemieślnik wie, że nie napisze i nie przetestuje idealnie wszystkich przypadków użycia. Ale jest sprytny. Potrafi wykorzystać narzędzie SOLID w połączeniu z czystą architekturą i określić, które fragmenty aplikacji potraktować priorytetowo. Wie jak przygotować kod do zmienności, która jest jedyną niezmienną zmienną wyrażenia CZAS*LOC*CCN (lines of codes * cyclomatic complexity number).

Pierwszym problemem było zapamiętanie i zrozumienie co kryje się pod literkami SOLID 🙂
Z separacją warstw czystej architektury poszło łatwiej… przynajmniej na schemacie.

Największym wyzwaniem były pierwsze linijki kodu. Temat mnie tak zaciekawił, że nawet będąc z dala od komputer, główkowałem jak ten pierwszy fragment powinien wyglądać. Szukałem różnych inspiracji i nic.

Dokładnie! Schody pojawiły się podczas implementacji, kiedy chciałem osiągnąć skuteczną bezkompromisową separację. Jak przebudować legacy code? Jak dopasować się do używanego frameworka? Jak ugryźć monolit wieloletniego czynu programistycznego?

Głównym problemem było odwrócenie zależności, którego w Pythonie się raczej nie spotyka. Zaiskrzyło dopiero, gdy trafiłem na artykuł na temat flask-injector’a. To dało mi podstawę, a dalej wszystko poszło już z górki. Wszystkie puzzle zaczęły do siebie pasować i powstał pierwszy prototyp.

Ciężko mówić o początku. To nie jest tak, że wstałem pewnego ranka i powiedziałem sobie: od dziś robię SOLIDa. W gruncie rzeczy są to spisane dobre praktyki programowania. Tego uczymy się cały czas. Jeśli chodzi o trudności to na pewno na początku było przekonanie siebie, że pisanie wielu interfejsów i klas to nic złego. No i to wyznaczanie granic odpowiedzialności…

Jeśli pełnisz funkcję lidera technicznego, dochodzi jeszcze wątek jak przekonać zespół. Po co te wszystkie klasy? Nie ma czasu, bo deadline ciśnie. Ty będziesz musiał pokazać w praktyce, że zamiast szybkości warto zainwestować w zwinność, którą długofalowo daje czysta architektura.

Przede wszystkim w pisaniu kodu, który jest testowalny. Bez odwracania zależności, pojedynczej odpowiedzialności czy zasady segregacji interfejsów dużo trudniej to osiągnąć. Opieranie się na SOLID pozwala pisać kod, który stosunkowo łatwo się rozszerza.

To właśnie efektywne wprowadzanie zmian w aplikacji, tworzy przewagę nad innymi na dynamicznym i konkurencyjnym rynku. Nie raz doświadczyłem, jak w cyklu życia oprogramowania pojawiały się nowe wyzwania: systemy kolejek zamiast komunikacji HTTP, wywołanie z linii poleceń, przetwarzanie wsadowe i asynchroniczność operacji. Sztuką było, aby te niskopoziomowe szczegóły nie wpływały na warstwę domeny.

Dzięki zastosowaniu pewnych mechanizmów czystej architektury udało się mi uratować w kilkadziesiąt minut produkcję. Podczas dużego skoku ruchu na stronie, jedno repozytorium, wykorzystywane w kilku miejscach, przestało wyrabiać. Cache’owanie całych odpowiedzi API odpadło, bo zasób był wykorzystywany częściowo w kilku końcówkach. To co się udało zrobić i to w ekspresowym czasie, to przenieść odczyt kluczowego fragmentu danych do read modelu. Zobaczyłem na własne oczy i byłem w szoku, jak szybko udało się przygotować tak dużą zmianę.

W koncepcji czystej architektury znalazłem całkiem sensowną ofertę odpowiedniego poziomu ochrony najbardziej krytycznej z warstwy – warstwy domeny. Tam właśnie znajdziemy zbiór myśli, wiedzę i doświadczenie, które wyróżniają produkt. Mając separację architektoniczną warstwy logiki biznesowej, mogłem z łatwością wprowadzić znany z DDD język wszechobecny i używać go w rozmowie z product ownerem.

Ale nie ma róży bez kolców – pisanie według tych zasad początkowo wydłuża czas developmentu. Po nabraniu odrobiny wprawy, te różnice się niwelują.

Kiedy chcemy zrobić komuś, lub sobie na złość 😉 Tak bardziej na poważnie, to oczywiście zależy.

Zawsze korzystać! Oczywiście można sobie pozwolić na zluzowanie lejców w niektórych miejscach.

W prostych skryptach np. ETL. W prototypowaniu, które ma udzielić odpowiedzi na temat technicznych możliwości realizacji.

Dobrym przykładem jest pisanie proof concept’ów czy kodu, który wiemy, że nie będzie rozwijany. Np. jakiś mały wewnętrzny projekt, który raz napisany będzie działać bez modyfikacji przez długi czas.

Pisanie zgodnie z zasadami czystej architektury wprowadza dodatkowy narzut czasowy, który zwraca się w postaci stabilności, testowalności i elastyczności. Jednak te cechy projektu nie zawsze są nam potrzebne. Wtedy narzut czasowy jest nieopłacalny.

Ale skąd możesz wiedzieć, że projekt na pewno nie będzie rozwijany i stosowanie dobrych wzorców nie ma sensu? Nawet proste PoC to coś więcej niż technikalia.

Jeśli nie musimy utrzymywać kodu, to nie mamy długu technicznego, a nie mając długu nie ma co się spinać na super czystą architekturę. Aczkolwiek według mnie każda architektura jest czysta, jeśli spełnia zakładane przez nią cele.

To co uchroni cię od długu technologicznego już na starcie, to umiejętność pisania jedynie niezbędnych interfejsów i klas. Zatem jeśli podczas projektowania masz tendencję do używania rzeczowników, a nie czasowników – wstrzymaj się. Naucz się jak wydobywać czynności, grupować je i nazywać jednostki wykonawcze. Zrób to zanim utworzysz kolekcję klas, które będą kulą u nogi twojego projektu.