Zasady SOLID na Backendzie: Każdy słyszał, nie każdy zna, jeszcze mniej stosuje

0:02O disco polo mówi się, że każdy słyszał, ale nie każdy się przyznaje, że zna.

0:06O zasadach Solid mogę powiedzieć, że każdy słyszał.

0:10Nie każdy zna, a jeszcze mniej osób stosuje tę zasadę w praktyce.

0:15No i dlaczego tak się dzieje?

0:17Powiedzieliśmy o pierwszej przyczynie tego zjawiska, o ignorancji, na którą składa

0:21się wiele różnych czynników w podejściu programistów do zasad SOLID.

0:25No ale z drugiej strony jeśli czegoś nie stosujemy, to po prostu

0:29może to wynikać z tego, że po prostu tych zasad nie znamy.

0:32A jak poznać zasady SOLID?

0:34Wystarczy przerobić ten kurs do końca i wszystko będzie jasne, więc brak

0:38znajomości łatwo wyeliminujemy.

0:40No ale tak niestety często bywa, że jesteśmy przytłoczeni właśnie tą masą

0:46różnych rzeczy, których musimy się nauczyć jako programiści, żeby poznać choćby

0:49framework czy bazę danych, czy strukturę zapytań cokolwiek innego.

0:53A zapominamy o dobrych praktykach, bo na to nie ma czasu, bo trzeba gonić z

0:56projektem, trzeba gonić z innymi rzeczami.

0:58Nie mamy praktyki.

1:00Zasady SOLID na początek są bardzo teoretyczne, bo trzeba poznać teorię,

1:04która z nich wynika i problemy, które one rozwiązują, których czasami możemy nie

1:08spotkać w aplikacji w takiej formie, jak o tym mówią podręczniki,

1:13a co za tym idzie unikamy praktykowania tych zasad, praktykowania stosowania ich w

1:17kodzie, więc naturalnie nie będziemy wiedzieć, jak je dobrze zastosować.

1:23Inną rzeczą, która sprawia, że nie są zasady SOLID zbyt

1:27często stosowane, to szybkie interakcje w projektach, zwłaszcza start upów, gdzie

1:31ten kod pisany jest często na kolanie, bo musimy gonić, bo konkurencja depcze po

1:35piętach i musimy dowodzić szybko feature, szybko funkcje.

1:39Mieliśmy ostatnio bardzo duży wysyp

1:43wszelkiego rodzaju aplikacji opartych o sztuczną inteligencję.

1:47Po tym jak został opublikowany czat pt.

1:49I to był najlepszy dowód na to, że te szybkie iteracje często mogą wpływać na

1:56pewne kompromisy w tworzeniu oprogramowania polegające na tym, że

2:01zostawiamy niektóre zasady i dobre praktyki gdzieś z boku.

2:05Wreszcie wielkie firmy, wielkie aplikacje robią wielkie pivot, by

2:09Netflix nie był od razu platformą treningową, tylko musiał wykonać pivot i

2:13często z aplikacjami typu SaaS, z aplikacjami web owymi mobilnymi.

2:17Mamy takie pivot, gdzie pewne funkcjonalności, które na początku

2:21były uznawane za korkowe, za kluczowe, po pewnym czasie już nie są takie.

2:26I musimy zrobić wielki pivot, a jeśli zrobić wielki pivot, to nie ma czasu na

2:29zmuszanie się nad dobrymi praktykami, zasadami, bo trzeba się szybko

2:32skonwertować, bo klienci uciekają, bo pieniądze biznesowi uciekają.

2:37No i wreszcie jeśli robimy wielkie piwo, ktoś ucieka, ktoś nas goni,

2:40no to mamy taką presję czasu. Coś się dzieje.

2:43Czujemy pośpiech, czujemy presję.

2:45Sami sobie czasami narzucamy presję czasu.

2:47Deadline nie do wykonania.

2:49Mamy aplikacje klienckie, nad którymi pracujemy w firmach typu software house.

2:53Ta presja czasu jest kluczowa, bo od tego zależy też cashflow firmy i to, czy firma

2:59będzie dobrze prosperować, czy będzie miała dobrą opinię na rynku.

3:02Więc często te deadline po prostu blokują nas przed zatrzymaniem

3:07się na chwilę, żeby zastosować jakąś dobrą zasadę, jakąś dobrą praktykę, pomyśleć nad

3:12tym, jak rozwiązać lepiej problem w kodzie i jeśli mamy deadline, to

3:18mamy też ograniczenia budżetu.

3:20Budżet jest wąski i często Szybciej po prostu napiszemy kod, który

3:26nie jest oparty o dobre praktyki, a dobre zasady, żeby tylko

3:29zmieścić się w budżecie.

3:30Nie mając na uwadze tego, jakie konsekwencje to będzie

3:34miało w przyszłości.

3:35Bo w programowaniu jest często tak, że dzisiaj pisany kod

3:39zawsze wydaje nam się dobry, ale za miesiąc będziemy przeklinać tę

3:43osobę, która go napisała i nierzadko okazuje się, że tą osobą jesteśmy my sami.