Czysta architektura. Czy jest to tylko modne hasło ostatnich lat? Nadużywany wypełniacz po poprzednim buzzwordzie „mikroserwisy”? Dlaczego w ogóle miałbyś uczyć się zasad, a później stosować czystą architekturę?
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 🤑
Panie, czemu tak drogo?
Dlaczego dodanie takiego prostego ficzera zajmie nam tyle czasu? Skąd taka wycena? – pyta Product Owner.
Programista, senior swojego fachu, wie, że można (by było 😈) szybciej. Ale kiedyś tam, naprędce podjął z zespołem decyzję, że użyją architektury warstwowej. Repozytorium urosło i powstała konstrukcja naczyń połączonych. Tu dolejesz tam wycieknie. Dodanie prostego modułu to wyprawa do Mordoru.
Strasznie być w takim projekcie. Megadżule energii potrzebne na dodanie kolejnego wiersza kodu. Niepewność, jak w rosyjskiej ruletce, kiedy odpalisz debug i zastanawiasz się – zadziała czy nie zadziała?
Koszt magazynowania słabego kodu
Joost Visser w książce Oprogramowanie łatwe w utrzymaniu podnosi interesujący temat – w jaki sposób wielkości bazy kodu wpływa na zwiększenie ryzyka, że projekt się nie powiedzie.
Wykorzystał wyniki badań dla języka Java i zaprezentował w jednostkach osobolat. Przykładowo 5 osobolat to 1 rok pracy 5 osobowego zespołu programistów, albo 2,5 roku pracy 2 developerów, albo 5 lat pracy jednego developera.
Spójrz na wykres. Skoro z ilością kodu wzrasta ryzyko niepowodzenia projektu to naturalnym jest, że wzrasta koszt pracy potrzebnej na dostarczenie jednej linijki kodu. To wszystko uderza w produktywność, a ta odbija się później na twoim zaangażowaniu i motywacji.
Oszczędzaj i wydawaj z głową
Widziałeś na wykresie, że im więcej linii kodu, tym większe
- fiasko projektu
- opóźnienie projektu
- niska jakość projektu
Co te pojęcia oznaczają dla ciebie?
Fiasko projektu
Kodowałeś w nowiutkich technologiach i w super zgranym zespole. Do czasu, aż coś się popsuło i nie wiadomo dlaczego projekt został wstrzymany. Nie wiesz czy zrobiłeś dobrą robotę, bo nie dotarłeś do etapu feedbacku od użytkownika.
Nieważne czy pracujesz w dojrzałej organizacji czy w startupie. Efekt jest ten sam – z czasem szukasz sobie nowego projektu, nowego pracodawcy.
Opóźnienie
Czyli nadzwyczajne parcie na termin, który zbliża się nieubłaganie. Nie możesz przyciąć zakresu prac. Ciśniesz na maxa. A to oznacza nadgodziny. Dodatkowy stres. W efekcie – zmęczenie materiału i wypalenie.
Niska jakość projektu
Challengowanie terminu releasu doprowadziło do stanu, w którym koszt wytworzenia softu dobrej jakości został przeniesiony w późniejsze utrzymanie. Taka kreatywna księgowość.
Projekt udało się zrealizować w terminie. Jednak wszystkie przypadki brzegowe i tematy niefunkcjonalne, zostały w backlogu na później – kiedyś. To oznacza niespójności ficzerów i wysyp błędów. Siedzisz i łatasz zgłoszenie po zgłoszeniu. Jesteś już znudzony brakiem nowych tematów rozwojowych i brakiem perspektyw na zmianę tego stanu.
Mam gest i jestem rozrzutny
Za każdy z powyższych przypadków, zapłacisz sporą dawką własnego czasu, czyli najcenniejszą walutą jaką posiadasz.
Jakie zyski?
- szukasz sobie nowego projektu, nowego pracodawcy
- nadgodziny, dodatkowy stres
- zmęczenie i wypalenie
- brak perspektyw
Porażająco słaba specyfikacja produktu Moja Kariera. Zamiast palić czas, na wymienione przypadki, zacznij oszczędzać i składać kapitał czasu na dobrze rokujące inwestycje.
Inwestuj i zarabiaj
Architekturę definiujemy jako szereg decyzji, podjętych podczas tworzenia oprogramowania. Suma tych małych decyzji składa się na prawdopodobieństwo sukcesu lub porażki całego projektu. Nie możemy dopuścić do tego, aby była to architektura przypadkowa.
Dlatego:
- Od samego początku pisz tylko niezbędny do działania kod. Olej pomysł napisania generycznej klasy, która rozwiąże problemy trzeciego programistycznego świata. Zaniechaj przyokazyjnej przebudowy modulika.
- Jak skaut, zostaw kod SOLID-niejszy niż go zastałeś. Jeśli widzisz kawałki martwe czy niejasne, o które często się potykasz, nie wahaj się ich usunąć. Bądź liderem w grze Eksterminator kodu.
Po zrobieniu porządków sięgnij po czystą architekturę. To najprostsza ścieżka na wygenerowanie zysku. Jeśli dopiero startujesz z projektem, miej w tyle głowy, że tylko idąc tą drogą wyeliminujesz opóźnienia i niską jakość.
Przejrzystość
Czysta architektura, zapewnia przejrzystość kodu. Będziesz widział i rozumiał warstwy, komponenty i relacje między nimi. Samodokumentujący się kod zapewni ci szybki dostęp do elementów składowych. Bez przekopywania się przez katalogi i regexpowania szukajki.
Testowalność by design
Koniec żmudnego mockowania i rozplątywania wieloletniego legacy. Napisanie testu będzie banalnie łatwe, bo nie tworzysz zewnętrznych zależności. Zacznij od implementacji storage’u in memory w trybie frameworkless, a zobaczysz nieprawdopodobnie pozytywny wpływ na pokrycie testami.
Prototypowanie i podejmowanie decyzji
Jakiej bazy użyć? Jaki framework będzie najlepszy? Te pytania padają z ust developerów przed wystartowaniem projektu. Skąd masz znać odpowiedzi przed zbudowaniem prototypu? Nie masz danych. Decydowanie na podstawie wróżb ze szklanej kuli prowadzi do długiego związku z technologią, która nie jest optymalna. A z czasem zacznie cię ograniczać.
Dlatego tak ważne jest kreatywne odsunięcie takich decyzji w czasie. Do momentu, aż zbudowany przez ciebie prototyp udzieli odpowiedzi. Jest jeszcze kolejny zysk. Nie będziesz przesiadywał w salce konferencyjnej i brnął w dyskusje o wyższości pomidorowej nad ogórkową (zastąp dowolnymi nazwami frameworków).
Zysk gwarantowany
Brzmi niewiarygodnie? Też tak myślałem. Dopóki nie zobaczyłem na własne oczy kodu, który został przygotowany w oparciu o zasady czystej architektury.
Po uruchomieniu IDE, wita mnie samodokumentująca się, a wręcz krzycząca architektura – Hej, to ja! Apka odtwarzającą muzykę. O popatrz! Tu jest domena, a tu moduł subskrypcji. Zobacz moje encje, działam na pakietach, w takich przypadkach użycia.
Marzenia? Nie! Realny cel, który już niedługo osiągniesz.
