Czysta architektura i SOLID okiem ekipy migawka.it

Transkrypcja rozmowy, którą za chwilę przeczytasz, zapoczątkowuje naszą online’ową przygodę z przekazywaniem wiedzy dotyczącej zasad SOLID, ogólnie zasad dobrego programowania i koncepcji czystej architektury. To punkt wyjścia do dalszych, głębszych rozważań. Manifest i deklaracja kierunku naszych dalszych działań.

— Ekipa migawka.it

 

Czym dla ciebie jest czysta architektura i zasady pisania SOLID-nego kodu?

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).

Jakie problemy miałeś na początku?

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.

W czym pomogły ci zasady SOLID i czystej architektury?

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 nie korzystać z czystej architektury

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.

Jak ty postrzegasz czystą architekturę i SOLID?

Są to dla ciebie buzzwordy i chwilowa moda, czy pomysł wart rozważenia?

Próbowałeś wprowadzić czystą architekturę i nie udało się?

Może znasz jakieś inne patterny i dobre zasady, które zapewniają sukces projektów?

(Po)wakacyjnie o domenie i plecakach

Wakacje się skończyły. W plecakach miejsce konserw, survivalowych gadżetów i karimat, zajęły laptopy i niezbędniki do bytowania w biurowej dżungli. A gdybyś do plecaka miał spakować kod. Według jakich kryteriów wybierzesz to, co jest ci niezbędne do przeżycia? Jak skutecznie nadać priorytety poszczególnym modułom? Które elementy architektury pozytywnie przejdą selekcję, a które nie? Już za kilka akapitów znajdziesz praktyczną instrukcję.

Domena aplikacji w Pythonie – Encje

Budowanie domeny aplikacji to najważniejsza i najtrudniejsza część każdego projektu. Ten złożony proces posiada trzy najważniejsze składniki. Zaczniemy od SOLID-nych encji, czyli zaprojektowania i zaimplementowania wyglądu naszych danych.

Podstawy czystej architektury

Gdyby zasady czystej architektury wymagały specjalistycznej wiedzy na poziomie Architekta IT, byłyby bezużytecznym, czysto teoretycznym tworem. Gdyby wymagały
przeczytania ton makulatury książek, utworzyłyby próg wejściowy nie do przekroczenia. Na szczęście jest zupełnie inaczej. Prościutko i przyjemnie. Zaprojektowanie aplikacji w duchu czystości architektonicznej wymaga poznania trzech prostych konceptów.

Czysta architektura w Pythonie

Od wielu lat szukam lepszych rozwiązań i praktyk programistycznych. Robię co w mojej mocy, żeby mój kod był czytelny, prosty oraz, co najważniejsze, żeby inni mogli go rozwijać bez wyrzucania z siebie tony przekleństw. Celem serii “CA w Pythonie” będzie stworzenie krok po kroku mini projektu – zestawu połączonych narzędzi, które tworzą spójną całość.

Jak zarobić na czystej architekturze?

Zanim zagłębimy się w techniczne aspekty czystej architektury, spójrzmy na nią ze strony ekonomiczno-finansowej. Nie będzie to rozkmina o tym, jak napisać książkę, wydać kurs czy zorganizować szkolenie. Będzie o codziennych mikro decyzjach programisty, które w skali makro doprowadzą do wielkiej straty, albo… zapewnią niewymierne oszczędności i zysk.

Czym dla ekipy migawka.it jest czysta architektura?

Czysta architektura 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

Prześlij komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

Pozostań w kontakcie