Znasz SOLID, GRASP i kilka innych clean code rules, ale czy słyszałeś o zasadach CUPID? Zasady CUPID, to niewątpliwie nowy buzz-word i must known principle dla każdego programisty!

Zasady lepsze niż SOLID

Opowiem Ci dzisiaj o kolejnym zbiorze zasad czystego kodu, które warto, a moim zdaniem nawet trzeba znać: CUPID. Pryncypia ukryte pod tym akronimem nie będą żadną nowością dla doświadczonych programistów, jednak ostatnio ubrano je w ten fancy skrót, który jest chwytliwy i łatwy w zapamiętaniu, dlatego coraz więcej o nim słyszymy. CUPID, to akronim agregujący w sobie następujące zasady clean code: Composable, Unix Philosophy, Predictable, Idiomatic, Domain-based. Każdą z nich rozbijemy sobie zaraz na czynniki pierwsze.

Osobiście CUPID-a określiłbym, jako SOLID 2.0, czyli zbiór zasad czystego kodu na dzisiejsze czasy. Nie zrozum mnie źle, nie próbuję tutaj insynuować, że SOLID-a znać nie trzeba, bardziej mam na myśli to, że clean code trochę ewoluuje, a przesłanki zasad CUPID wydają się wprowadzać to, co aktualnie w programowaniu jest najbardziej potrzebne, aby mówić o czystym kodzie.

C, jak Composable

Kod „composable” (czyli „komponowalny”) odnosi się do stylu programowania, które tworzone jest w taki sposób, aby mogło łatwo współpracować z innymi komponentami i elementami systemu oraz wymieniać je w razie potrzeby, bez większych problemów. Taki kod ma jasno określony zakres działania. Nie stara się robić wszystkiego, lecz koncentruje się na realizacji konkretnej funkcji lub zadania. Pisząc zgodnie z paradygmatem komponowalności, minimalizujemy swoje zależności od innych modułów czy bibliotek, co ułatwia ponowne wykorzystanie i testowanie kodu.

aby spełniać Composable:

1. preferuj kompozycję zamiast dziedziczenia
2. Stosuj Single responsibility znane z SOLID-a
3. STOSUJ DEPENDENCY INVERSION PRINCIPLE ZNANE Z SOLID-A
4. STOSUJ HIGH COHESION znane z GRASP

U z CUPID, to Unix philosophy

Filozofia Unix opiera się na kilku fundamentalnych zasadach, które pozwalają na tworzenie prostych w utrzymaniu, re-używalnych i elastycznych elementów naszego systemu. Zgodnie z filozofią Unix-a, oprogramowanie powinno być projektowane tak, aby poszczególne jego elementy wykonywały jedno zadanie i były w nim wyspecjalizowane. Komponenty nie powinny mutować otrzymanych danych wejściowych oraz dać się łatwo skalować, tak, aby możliwe było łączenie ich w większe procesy.

aby spełniać Unix philosophy:

1. utrzymuj swój kod w najprostszej możliwej postaci
2. twórz elementy systemu, które będą wyspecjalizowane w konkretnej logice – CREATOR, CONTROLLER, INFORMATION EXPERT Z GRASP
3. zapoznaj się z wzorcem pipes & filters

P z CUPID, to Predictable

Przewidywalny kod to taki, który zachowuje się zgodnie z założonymi oczekiwaniami, deterministycznymi wynikami i możliwością łatwego monitorowania. Komponenty i moduły przewidywalne działają zawsze w ten sam sposób w tych samych warunkach. Dzięki temu są bardziej niezawodne i łatwiejsze do debugowania. Przewidywalność wymaga również wbudowanej obserwowalności, co pozwala na śledzenie i analizę działania kodu w czasie rzeczywistym. To kluczowy aspekt przy projektowaniu kodu infrastruktury, gdyż umożliwia szybkie wykrywanie i rozwiązywanie problemów.

aby spełniać Predictable:

1. PISZ ŁATWO i dobrze TESTOWALNY KOD
2. Stosuj podejście: tell, do not ask
3. implementuj abstrakcje zgodnie ze stanem faktycznym – LSP z SOLID

I z CUPID, to Idiomatic

Idiomatyczny kod to taki, który jest naturalny i intuicyjny w aktualnym środowisku programistycznym (TypeScript, PHP, JAVA, C itp.). Idiomatyczność redukuje obciążenie poznawcze, bo taki kod jest zgodny z głównymi przesłankami technologii w której powstał, co oznacza, że jest łatwy w zrozumieniu i używaniu przez innych programistów. Inaczej mówiąc, jeśli jesteś programistą Go, to pisz w stylu, który ten język proponuje. Jeśli piszesz w języku funkcyjnym, to nie próbuj implementować wzorców OOP.

aby spełniać Idiomatic:

1. nie pisz kodu, który nie jest Ci naprawdę potrzebny
2. podążaj za głównymi pRZesłankami technologii, w której tworzysz

D z CUPID, to Domain-based

Kod oparty na domenie to taki, który ściśle odpowiada specyficznym potrzebom i terminologii danej dziedziny. Rozwiązania są zgodne z językiem i strukturą problemu organizacji, co ułatwia ich zrozumienie i utrzymanie. Komponenty i moduły są tworzone tak, aby odzwierciedlały rzeczywiste granice domeny biznesowej. To podejście obejmuje używanie języka zorientowanego na domenę oraz strukturalne dopasowanie do problemu. Próbuj odzwierciedlać biznes w swoim kodzie stosując podejście Domain Driven Design.

aby spełniać Domain-based:

1. wdrażaj w swoim kodzie bogate modele, które odzwierciedlają biznes
2. stosuj wzorce strategiczne i taktyczne znane z DOMAIn driven design

Podsumowanie

• CUPID to zbiór zasad clean code na miarę 21. wieku.
• CUPID rozwija się do: Composable, Unix Philosophy, Predictable, Idiomatic, Domain-based.
• Jest to niewątpliwie nowy buzz-word i must known principle dla każdego programisty.