Zasady SOLID na Backendzie: Błędy w kontekście SOLID

0:02Solid to nie tylko łąka usłana kwiatami i tęcza nad łąką.

0:07To też masa błędów, które możemy popełnić w trakcie implementacji

0:11naszych zasad, w trakcie usilnego starania się, żeby te zasady spełniać.

0:15I ja 10 takich błędów wybrałem i teraz każde z nich pokrótce omówię.

0:20Błąd numer jeden to jest over engineering over engineering, czyli przesadna

0:25implementacja, dodawanie zbyt wielu warstw abstrakcji, wydzielanie zbyt wielu małych

0:31metod, sprawianie, aby nasz kod był tak bardzo solid, że zapominamy o tym,

0:37żeby on tak naprawdę dawał wartość.

0:39Kod przede wszystkim jest dobry i czysty, kiedy daje wartość biznesowi, kiedy

0:44funkcjonalności i funkcje, które implementujemy w kodzie

0:47działają i dają wartość końcowemu użytkownikowi i po prostu

0:50przynoszą kasę biznesowi.

0:53A jeśli mamy over engineering, tracimy czas na dodatkowe testy.

0:57Tracimy czas na sprawdzanie, czy nasz kod jest stabilny.

1:00Mamy zbyt dużo metod, które później trudno utrzymywać, więc łatwo przesadzić w drugą

1:06stronę, gdzie zgadza obiektów dużych klas.

1:10Z wieloma metodami, które robią wszystko.

1:12Będziemy tak bardzo chcieli się zrobić SOLID tak bardzo chcieli wyszukać

1:16te pojedyncze odpowiedzialności, że skończymy na milionach klas z małymi

1:22metodami, jedną linijkę nowymi, które z kolei będą trudne do utrzymania, bo będzie

1:27ich tak dużo i cognitive load, który będzie potrzebny do tego, żeby te klasy

1:31refaktoryzacji, żeby je utrzymywać, żeby wyeliminować bugi, będzie

1:34po prostu zbyt duży.

1:36Więc błąd numer jeden over engineering.

1:38Trzeba naprawdę dużo wyczucia, żeby nie przesadzić, ale to wyczucie

1:41zdobywa się przez doświadczenie.

1:43Ty to doświadczenie będziesz teraz zdobywać, bo masz te narzędzia, masz

1:47wiedzę i ćwiczenia praktyczne, które już przerobiła eś.

1:50Przerobiła się w tym kursie, które pozwolą Ci umiejętnie dostosowywać swój kod

1:54do tego, żeby spełniał zasady SOLID.

1:58Błąd numer dwa to zbyt dużo małych interfejsów.

2:01Jeśli na siłę będziemy się starać, aby spełniać zasady SOLID i wydzielać małe

2:07kontrakty, małe interfejsy, bo skończymy z tym, że będziemy mieć przesyt małych form

2:11w kodzie, które będą dla nas nie do ogarnięcia umysłem.

2:16Błąd nr 3 Dodawanie nowych metod.

2:19W momencie kiedy chcemy spełnić zasadę OCP i sprawiać, żeby nasz kod był rozszerzany,

2:26możemy ją trochę mniej zinterpretować, interpretować w zły sposób.

2:30Poprzez rozszerzanie będziemy rozumieć dodawanie nowych metod, a nie o to chodzi.

2:36W zasadzie Open Krauss Principle.

2:38Chodzi o to, żeby nasz kod przybrał formę trochę takich

2:42wtyczek, które wtykami do gniazda trochę jak klocki Lego.

2:46Nie tworzymy nowych klocków, nie do budowy nowych metod, ale dołączamy

2:51je do istniejącej budowli.

2:53Wobec czego dopisywanie nowych metod jest niejako modyfikacją istniejącego kodu.

2:57Nie jest rozszerzaniem, chyba że ta nowa metoda niesie nam totalnie inne zachowanie

3:03niż to, które już mamy, bo nie będziemy wtedy wstrzykiwać jakichś

3:06karkołomnych konfiguracji do konstruktora klasy, żeby zmienić jej zachowanie

3:12zgodnie z nowymi wymaganiami.

3:14Więc tutaj też trzeba dużo rozwagi i dużo analizy, zanim usiądziemy do pisania kodu.

3:21Błąd numer 4 to nadpisywanie metod i zmiana ich zachowań.

3:24O tym mówiłem już wcześniej.

3:25Jeśli chodzi o kilka poprzednich zasad.

3:27Kiedy chcemy tworzyć łańcuch dziedziczenia i nadpisuje

3:32metody, musimy się starać, żeby nie zmieniać radykalnie ich zachowania.

3:36Nadpisywanie metody to jest narzędzie udostępniane przez niektóre języki, które

3:41pozwala nam zmodyfikować istniejące zachowanie obiektu w danej metodzie,

3:47ale nie możemy radykalnie zmienić.

3:49Jeśli mamy klasę, która wysyłam maile, nie możemy nagle wysyłać SMS ów.

3:54Trzeba o tym pamiętać, żeby nie zmieniać radykalnie zachowania metody.

3:59Błąd nr 5 Bezpośrednie tworzenie instancji w klasach.

4:03Jeśli wstrzykuje się zależności, to pilnujmy tego, żeby je

4:06wstrzykiwać z zewnątrz klasy.

4:08Tworzenie instancji w danej klasie nie jest wstrzykiwania zależności.

4:12Dlaczego jest to błąd, skoro przecież ten kod działa i zachowuje się poprawnie?

4:18Ano dlatego, że te zależności nam umkną i możemy skończyć na tym, że będziemy je za

4:23każdym razem instancje chować w każdej innej klasie, zamiast tworzyć jedną

4:28instancję, która będzie wstrzykiwania.

4:31Są języki, które umożliwiają nam tworzenie tak zwanych kontenerów do wstrzykiwania

4:36zależności, ale są też rozwiązania, które tych kontenerów nie dostarczają.

4:40I wtedy tego typu zachowanie, tego typu kod może nas po prostu

4:44uderzyć w twarz błędami.

4:47Błąd nr 6 to abstrakcja na wszystko.

4:49Jak już będziemy tworzyć abstrakcję, możemy skończyć na tym, że będziemy mieć

4:52abstrakcję na każdą drobną, dziwną rzecz.

4:55I to też nie jest dobre.

4:56Trzeba wyważyć złoty środek.

4:58Nie będę się tutaj zbytnio rozwodził, po prostu zostawiam to Twojej

5:02ocenie, Twojemu doświadczeniu.

5:03To nabywa się w praktyce, nabywa się w boju.

5:06Więc będzie taki moment, w którym w Twoim kodzie będzie naprawdę dużo abstrakcji, a

5:10skończysz na momencie, w którym tych abstrakcji będzie dokładnie tyle, ile

5:14trzeba i każdy interfejs będzie miał duże znaczenie dla logiki aplikacji.

5:19Błąd numer 7 to zbyt dużo odpowiedzialności w klasach,

5:22czyli złamanie zasady SRP.

5:24Tutaj wszystko jest chyba jasne.

5:26Budujemy klasy, które mają zbyt dużo odpowiedzialności, bo

5:29chcemy, żeby były elastyczne.

5:30Chcemy wstrzykiwać te zależności i możemy skończyć na tym, że nasza klasa

5:35robi zwyczajnie zbyt wiele.

5:38Kolejny błąd to zbyt duże interfejsy, czyli to, co prowadzi nas do

5:42implementacji zasad LSB i ESP, gdzie pilnujemy tego, aby nasze interfejsy

5:48były konkretne, małe i bardzo dobrze i ciasno zdefiniowane, Żeby nasze

5:53klasy korzystały tylko z tych metod, implementować tylko te metody, które są

5:56faktycznie potrzebne, więc potrzebujemy małych, konkretnych interfejsów.

6:01No i błąd numer 9 to częsta modyfikacja istniejącego kodu.

6:05Jeżeli nasz kod istniejący już napisany kod musi być często modyfikowany z innego

6:10powodu niż zmieniające się wymagania biznesowe, bo to jest

6:13czynnik, który uzasadnia modyfikację kodu.

6:16Wiadomo, zmienia się logika aplikacji, musimy coś zmienić, ale jeśli dodajemy

6:20nową funkcjonalność, która bezpośrednio nie jest związana z tym kodem, a ona i tak

6:24go dotyka, to znaczy, że popełniliśmy błąd na etapie designu i trzeba przeanalizować,

6:30czy wszystkie zasady są prawidłowo zachowane.

6:33Ostatni, dziesiąty błąd to ślepe ufanie postanowieniom,

6:37które mamy gdzieś na początku.

6:39Ślepe ufanie temu, że dana klasa powinna mieć jedną odpowiedzialność i trzymamy się

6:44tego tak bardzo kurczowo, że rodzą nam się później potworki.

6:48Dużo małych klas z małymi interfejsami, które sprawiają problem w utrzymaniu.

6:52Pamiętaj, że programowanie to jest dynamiczna dyscyplina.

6:55Tworzenie aplikacji to dynamiczna dyscyplina.

6:57Wiadomo, software musi być stabilne, oprogramowanie musi być stabilne i odporne

7:01na błędy, ale ślepe ufanie postanowieniom, decyzjom, które gdzieś na początku

7:05podjęliśmy, może prowadzić do błędów.

7:07Bo biznes się zmienia, rynek się zmienia, technologia się zmienia, a

7:11tylko krowa nie zmienia zdania.

7:13Nie ufaj ślepo postanowieniom, analizuj cały czas swoje decyzje, analizuj kod i

7:17wprowadzać zmiany tam, gdzie to jest konieczne.