Wojtek: Kod powinien być stworzony do wymagań, które są teraz, a nie do wymagań, które będą jutro.

Mateusz: Witam Was serdecznie w naszym następnym, czwartym już odcinku pierwszego sezonu podcastu Piwnica IT. Jest ze mną Wojtek jak zawsze. Witaj Wojtku. Czy wiesz jaki dzisiaj będziemy mieć temat?

Wojtek: Wiem, przygotowywałem się do tego odcinka.

Mateusz: Dokładnie tak. Wydaje mi się, że to będzie dość ciekawy temat, dość inspirujący dla wielu tak naprawdę, bo dzisiaj będziemy rozmawiać o tematach dobrych praktyk w budowaniu kodu, w szczególności w jego ustrukturyzowaniu odpowiednim. Porozmawiamy o dość mało albo i wiele mówiących akronimach zasad, które są wykorzystywane w programowaniu takie jak KISS, YAGNI, WET, AHA i wiele, wiele innych, które znamy i u których chcielibyśmy porozmawiać. Temat wydaje się dość interesujący, w związku z powyższym - chyba możemy zacząć. Chciałbym, żebyśmy zaczęli ten temat od dobrych praktyk, tego w jaki sposób budujemy nasz kod, w jaki sposób jego strukturętworzymy. Żeby zacząć w zasadzie jakoś to, chciałbym zapytać Ciebie Wojtku, jak wyglądał kod tworzony przez Ciebie, przez zespoły, w których pracowałeś w projektach w Twojej przeszłości? Czy uważasz, że ten kod, który stworzyliście razem był fajny, wartościowy, był dobrej jakości? Czy stosując pewne zmiany, zasady moglibyście zrobić coś lepiej? Jak to wyglądało w przeszłości?

Wojtek: Myślę, że wyglądało to bardzo różnie. Myślę też, że na strukturę tego projektu wpływa jego wielkość. Ciekawe jest też to, w jakiej technologii on jest napisany. Myślę, że różnica jest pomiędzy projektem w React'cie , a projekt w Angularze, który już niejako sam narzuca pewną strukturę. Jeśli chodzi o React, to jest to bardzo dowolne, tak samo jak te rzeczy, o których rozmawialiśmy w ostatnim odcinku odnośnie praktyk CSS i modeli, które tam są, które też narzucają jakieś praktyki. Jeśli chodzi o projekt, w których ja pracowałem, to niestety w większości były to dość dynamicznie rozwijające się projekty i prototypy, które przerodziły się w duże projekty, więc nigdy nie było to idealnie zrobione w moim odczuciu i myślę, że niestety sporym nakładem pracy, ale można było znacznie poprawić to, jak jest ułożony projekt czy też te projekty.

Mateusz: Fajna analogia do tego, że zespół, że projekt tak naprawdę może być kiepsko napisany, jest pisany dynamicznie. Bardzo mi się to podoba. Czy uważasz, że ogólnie projekty były mogły być napisane lepiej?

Wojtek: Tak, myślę, że tak, chociaż myślę, że tutaj ciężko jest ogólniać. Jest bardzo wiele różnych podejść, szczególnie w tym środowisku, w którym my się obracamy. W związku z tym, że nie ma jasno narzuconych standardów w kontekście struktury katalogów i nazewnictwa plików. Rozmawialiśmy też o problemach, które wynikają z tego, z jakich technologii korzystamy. Zupełnie inaczej będzie wyglądał ten projekt w momencie kiedy korzystamy z CSS Modules a inaczej kiedy korzystamy z Styled components. Więc myślę, że zawsze jest miejsce na poprawę. A jak to u Ciebie wyglądało Mateuszu?

Mateusz: Apropo tych narzuconych nazw katalogów czy struktur samej aplikacji to też nie do końca bym się zgodził, bo frameworki takie jak Next czy chociażby już w zasadzie już powoli umierające Create React App, w zasadzie narzucają nam pewną propozycję. Jakbyś spojrzał na aplikacje, nawet Reactowe, to wydaje mi się, że w większości przypadków znajdziemy bardzo podobne struktury, które są ogólnie przyjęte w społeczności programistycznej jako dobrą praktykę budowania struktury aplikacji Reactowej. W Angularze zupełnie inaczej to wygląda. Ten narzut jest większy. W React może nie jest to narzucone bezpośrednio przez samo narzędzie, chociaż to też zależy jakie narzędzie, to tak naprawdę wydaje mi się, że jednak społeczność ustaliła jakiś standard i ten standard gdzieś tam występuje. I założę się, że niezależnie od tego, czy to jest Twój projekt, z którym ja nie mam nic wspólnego, czy mój projekt z którym Ty nie masz nic wspólnego, to pewne analogie byłyby takie same po prostu - pewne aspekty.

Wojtek: Zdecydowanie, ale to pewnie dlatego, że obracamy się w tej samej technologii.

Mateusz: No tak, trudno by było, żeby w React'a wrzucić np. strukturę katalogów Java. Tutaj ciężko by było zachować te same zasady, gdzie aplikacje Javowe zupełnie inaczej architektonicznie są budowane, bo mają inny cel istnienia, inne zadania mają do wykonania. Przy aplikacjach frontendowych to jest też zupełnie coś innego. Ale jakbyśmy spojrzeli np. na strukturę Angulara czy React'a - to pewne aspekty są przenoszone pomiędzy oboma oboma tymi podejściami. I pomimo tego, że to są dwa całkowicie odmienne frameworki, które nie mają ze sobą za wiele wspólnego, to te praktyki pomimo wszystko się przenikają. Zadając Ci pytanie o widoczne problemy w projektach czy też o jakość Twojej pracy w zasadzie oczekiwałem, że Twoja odpowiedź będzie podobna do mojej, czyli że spotkamy się w tym samym miejscu. Projekty są dynamiczne, w zasadzie wszystkie, mamy jakąś tam uzupełnioną strukturę i z doświadczenia widzę, że ta struktura też nie zawsze jest w stanie nam dać taką gwarancję tego, że to jest dobrze napisane, czy że wszyscy wiedzą gdzie co powinno się znaleźć, bo każdy ma troszeczkę inne podejście, każdy ma inny pomysł jak daną funkcjonalność napisać i sprowadza się to następnie do tego, że może trochę bardziej nowe osoby w projekcie albo osoby, które są mają trochę inne doświadczenia, próbują pewne rzeczy wrzucać w trochę nowe miejsca i czasami powstaje nam multiplikacja tych samych miejsc, warstw, które gdzieś tam po całej strukturze są rozrzucone. Z mojego doświadczenia wynika, że bardzo trudno zastosować dobre praktyki pisania ustrukturyzowania tego kodu, w szczególności jeśli mamy zespół, który dynamicznie się zmienia. To tyle, jeśli chodzi o moje praktyki. Wydaje mi się, że w zasadzie to widoczne problemy w tych projektach, które tworzymy u mnie najczęściej opierały się na tym, że zespół nie do końca był świadom tego, co gdzie powinno się znaleźć, czy też co jak napisać. Trochę bardziej doświadczone osoby więcej i częściej wykorzystywały abstrakcję do tego, żeby coś tworzyć. Mniej doświadczone, nie bardzo to rozumiały, więc pisały, często powielały ten sam kod, bardzo mało stosowały abstrakcyjnych rozwiązań i też często ich nie rozumiały po prostu. Znowuż najlepiej mi się pracuje w zespole, gdzie mamy największe seniority, bo wydaje mi się, że im wyższy poziom programistów, tym lepsza proporcja pomiędzy stosowaniem abstrakcji a jej niestosowaniem. I tu ja w zasadzie mam pytanie do Ciebie, bo mówimy o tej abstrakcji. A chciałem się dowiedzieć czym jest dla Ciebie abstrakcja i czy rzeczywiście warto ją stosować? Czy abstrakcja ma sens w naszych projektach?

Wojtek: Zdecydowanie. Myślę, że uogólniając abstrakcja jak najbardziej ma sens i pozwala na poradzenie sobie z wieloma problemami, z którymi się spotykamy programując tak ogólnie, ale też pozwalają zazwyczaj uniknąć problemów, które mogłyby nam się przytrafić w związku z tym, że nie mamy tych abstrakcji, pozwalają zamknąć jakąś wspólną funkcjonalność, obudować ją, zapakować do jednego miejsca i upewnić się, że ta funkcjonalność działa tam i będzie działała dla wszystkich podobnych przypadków, które korzystają z tej abstrakcji. Dodatkowo jeszcze, w momencie, kiedy trzeba coś zmienić, możemy to zmienić tylko w jednym miejscu, nie martwiąc się o to, żeby modyfikować to we wszystkich pozostałych miejscach.

Mateusz: Ja rozumiem abstrakcję jako coś, co ma nam ukrywać implementację, szczegóły implementacyjne danego rozwiązania po to, żeby łatwiej można było to powielić w innych miejscach i wykorzystać nie zastanawiając się nad tym, czy też nie tworząc ponownie tej samej logiki. Takie podejście, gdzie rzeczywiście staramy się zaimplementować, tworzyć tę abstrakcję, żeby ukrywać tą implementację daje nam sporo fajnych, wartościowych rzeczy, tak jak wspomniałeś. Daje nam to poczucie, że możemy rzeczywiście, że możemy w jakiś tam sposób łatwiej tworzyć reużywalne komponenty, czy też możemy tak naprawdę nie wchodzić w szczegóły implemenetacyjne po to, żeby zrozumieć ogólny koncept tego, co chcemy stworzyć. Ale tak naprawdę jest taki moment, wydaje mi się, kiedy abstrakcja przestaje mieć sens.

Wojtek: Zdecydowanie. Myślę, że. Abstrakcja w momencie kiedy jest zrobiona w nieodpowiednim miejscu, zrobiona za szybko może być bardzo szkodliwa dla poziomu kodu i jakości naszego projektu. Ponieważ abstrakcje też mają to do siebie, że tak jak powiedzieliśmy ukrywają szczegóły implementacji i tworzą ciekawą psychologiczną, taką jakby to nazwać, taki rachunek, który za każdym razem właśnie, którym się pożytkujemy, korzystając z tych abstrakcji. W momencie, kiedy coś chcemy dodać do tej abstrakcji albo w momencie kiedy coś chcemy z niej usunąć i czasami łatwiej jest znacznie skorzystać z abstrakcji. Mimo tego, że moglibyśmy zrobić jakiś kawałek kodu łatwiej i rozszerzyć ją. Okazuje się, że ta abstrakcja, usunięcie jej części byłoby w tym wypadku lepszym rozwiązaniem.

Mateusz: Wydaje mi się, że chyba ten temat abstrakcji dość mocno wykorzystaliśmy i w zasadzie powiedzieliśmy chyba to, co najważniejsze. No i teraz na rynku, w branży naszej IT bardzo często mówimy o różnego rodzaju zasadach, które mają nam pomagać w tworzeniu tej abstrakcji, w tworzeniu i zarządzaniu tą abstrakcją w taki sposób, żeby z jednej strony może nie przesadzić, ale z drugiej strony może, żeby odpowiednio nasycić nasz projekt właśnie tymi konceptami abstrakcyjnymi, tym kodem, który w jakiś tam sposób tą implementację ukrywa i daje nam poczucie ważności, tej lepszości naszego kodu. Tak naprawdę chciałbym, żebyśmy, taki był plan przynajmniej, żebyśmy sobie o kilku porozmawiali. Pierwsza. Pierwsza jest dość ciekawa. Na pewno kojarzysz tą zasadę. I tutaj warto wspomnieć o tym jak ona powstała? To jest reguła, która powstała w latach sześćdziesiątych dwudziestego wieku i nie powstała w branży naszej, tylko powstała w branży amerykańskich inżynierów wojskowych, którzy tworzyli tak naprawdę, którzy byli odpowiedzialni za budowę samolotów. I zasada polegała na tym, że samoloty powinny być tworzone w taki sposób, maksymalnie prosty sposób po to, żeby średnio zdolny mechanik w naszym przypadku programista, był w stanie skutecznie naprawić ten samolot w warunkach, które nie były warunkami warsztatowymi. Zasada nazywa się KISS, reguła KISS, czyli Keep It Simple Stupid. Tłumaczyć Wojtku? Tłumaczenie jest dość dość ciekawe. Natomiast jeśli chodzi o tą zasadę, to ona została później przełożona na architektury oprogramowania i chyba jest jedną z najpopularniejszych w tym momencie zasad, które występują. Ma też ma też polski odpowiednik. Polski odpowiednik to jest BUZI. Nie wiem czy wiedziałeś. BUZI czyli Bez Udziwnień zapisu Idioto.

Wojtek: To naciągane trochę, moim zdaniem.

Mateusz: Trochę naciągane, ale jednak jest jakiś polski polski odpowiednik tego akronimu. Powiedz mi Wojtku. Z perspektywy mojej jest to zasada, o której ja np. na wielu szkoleniach wspominam, którą często się stosuje i w review bardzo często staramy się upraszczać pewne rzeczy i dążymy do tej prostoty. Jak to wygląda z Twojej perspektywy? Czy ta zasada zawsze ma sens? Czy są momenty, kiedy zbytnie uproszczenia będą większym problemem?

Wojtek: Muszę przyznać, jest to ciekawe pytanie, Mateuszu. Myślę, że nie ma jednej generalnej odpowiedzi. Myślę, że w 99% przypadków, jeśli chodzi o moje doświadczenie, zdecydowanie tak. I im prostsze rozwiązanie porównując nas do tych mechaników, którzy muszą naprawiać samoloty gdzieś tam w polu. Czyli mając bardzo ograniczone zasoby zgadzam się w 100%, że zapewnić rozwiązanie, które jest po prostu im prostsze tym lepsze i im więcej osób może je zrozumieć i szybko naprawić, tym bardziej oceniłbym jakość tego kodu na wyższą.

Mateusz: Czyli w zasadzie jeżeli dobrze rozumiem uważasz, że kod, który jest prosty jest bardziej wartościowy niż ten, który jest kodem bardziej złożonym i trudniejszym w zrozumieniu?

Wojtek: Tak, uogólniając tak.

Mateusz: I o tym mówi ta zasada.

Wojtek: A masz jakieś dobre przykłady Mateuszu. Przepraszam, że Ci przerwę.

Mateusz: Anty przykłady?

Wojtek: Anty przykłady. Bo jeden bardzo dobry przychodzi mi do głowy. Nie wiem czy się spotkałeś kiedyś z takim podejściem, że w projektach frontendowych, Javasciptowych korzysta się bardzo mocno z bibliotek takich jak Lodash albo Ramda i używa się zamienników tych funkcjonalności, które zapewnia biblioteka, to znaczy zapewnia JavaScript, zamiennikami z biblioteki, tak żeby mieć spójność w projekcie. Ale nawet te najprostsze elementy typu powiedzmy map czy reduce sąwymieniane na te rzeczy z Lodasha.

Mateusz: Jakiś czas temu mogło mieć to sens. Kiedy JavaScript nie posiadał tych funkcjonalności i pewne funkcje, metody trzeba było napisać samodzielnie, na przykład mapy czy reduce. Więc zakładam, że Lodash wprowadzał dodatkową warstwę, właśnie funkcjonalną, która dawała nam tak jakby coś, czego nie dawał nam JavaScript w tamtym momencie. I przypuszczam, że tych kilka lat wstecz, kilka lat temu mogło mieć to większe zastosowanie i większy sens niż w obecnych czasach.

Wojtek: Zgadzam się. Tylko wiesz, w tamtych czasach to też CoffeeScript miał sens.

Mateusz: Tak, tak, tak oczywiście. Tylko problem polega na tym, że te nawyki stosowania tych bibliotek pozostały z nami do dnia dzisiejszego.

Wojtek: Czy powiedziałbym, że to nawyki?

Mateusz: Pamiętasz nasz wspólny projekt z zeszłego roku? Przepraszam, sprzed dwóch lat już prawie, jak pokazywaliśmy sobie z developerami z Indii.Wojtek Pamiętam.Mateusz Zasada była bardzo prosta - wszystko robimy Lodash'em. Tam nie było w ogóle JSa, tam CSSy były na pozycjach absolutnych. Cała logika była zrobiona z Lodashem. JSa czystego nikt nie dodawał, bo był Lodash, więc czemu nie?

Wojtek: Tak, ale ten projekt był bardzo specyficzny, pod wieloma względami.

Mateusz: Dynamiczny Wojtku.

Wojtek: Tak, powiedziałbym, abstrakcyjny, specyficzny.

Mateusz: On to nawet się wpisuje w nasz dzisiejszy temat, wpisuje się w nasz dzisiejszy temat o abstrakcjach. Więc projekt rzeczywiście był abstrakcyjny, ale chodzi o to, że ja mam takie wrażenie, że Lodash jako biblioteka, która zapewnia pewne funkcjonalności dodatkowe, jest świetną biblioteką, był świetnym biblioteką, jeśli mówimy o czasach, kiedy JavaScript miał, brakowało mu dużo z tego, co mamy dostępne dzisiaj chociażby do kopiowania obiektów. Kopiowanie obiektów dzisiaj wykorzystując chociażby spread operator a kopiowanie obiektów kiedyś to w zasadzie dwa różne światy. Tak naprawdę nie.

Wojtek: Zgadzam się tylko tutaj też trochę innej kwestii, bo nawet w tamtych czasach. Myślę, że próbowanie, przystosowanie języka do czegoś czym nie jest i nakładaniem właśnie takich abstrakcji na ten język w postaci jakichś dodatkowych narzędzi, bibliotek, daje ogromną barierę wejścia. Tak jak wspominałeś dla nowych developerów chociażby. I wydaje mi się, że taki kod nawet dla Ciebie po pewnym czasie, w momencie kiedy nie masz dużo doświadczenia z tym Lodashem jest bardzo skomplikowany.

Mateusz: Tak, zgadza się, jeśli mówimy o upraszczaniu, czyli zasada KISS, to wydaje mi się, że powinniśmy pomijać tego typu rozwiązania. Się zgadzam w stu procentach, ale z drugiej strony te rozwiązania dają nam, może nie Lodash, bo Lodash powiedzmy, że to jest po prostu zbiór jakiś dodatkowych funkcjonalności, z których większość już mamy w JSie. Natomiast są tego rodzaju biblioteki jak Ramda, która nie daje nam nic, czego nie ma w JSie.Ona tak naprawdę robi to troszeczkę inaczej i ukrywa przed nami całą tę funkcjonalność związaną z wprowadzaniem, z pisaniem w sposób funkcyjny. Zapewnia tak naprawdę to wsparcie dla programowania funkcyjnego. Ułatwia powiedzmy. Chociaż ja mam trochę odmienne zdanie na temat tego czy ułatwia czy nie ułatwia, bo w moim odczuciu nie ułatwia. Ale tak jak mówię nie mam pewnie za dużo doświadczenia z tą biblioteką, tylko w kilku projektach się z tym spotkałem i to raczej mam negatywne odczucia odnośnie tej biblioteki. Ale fakt faktem zgadzam się, że dla osób, które nie miały nigdy wspólnego nic to wejście w projekt gdzie Ramda jest główną biblioteką do budowania funkcjonalności jest praktycznie bardzo trudne. Jest praktycznie niemożliwe, żeby taka osoba dynamicznie szybko weszła w projekt.

Wojtek: Ja mając swoje doświadczenia w branży myślę, że to było jedno z takich największych doświadczeń moich właśnie w kontekście tego tematu, o którym dzisiaj rozmawiamy i tworzenia abstrakcji i dodawania sobie dodatkowych narzędzi, jeśli chodzi o kod. Uwielbiałem Ramdę swego czasu i pisałem projekty tylko z wykorzystaniem Ramdy właśnie starając się, żeby mój JS był funkcyjny w stu procentach, na dobrą sprawę korzystałem z Monad, ze wszystkich dobrodziejstw programowania funkcyjnego, kompozycji, po currying, itd. I pamiętam, że na samym początku byłem zafascynowany tym kodem i widziałem o ile fajniej krócej to wygląda. Ale z czasem zrozumiałem, że ten kod, jeśli komuś to pokaże, ktoś kto nie zna Ramdy zupełnie, nic tego nie zrozumie. Ja po dwóch tygodniach nie pamiętam co połowę z tej funkcjonalności, które napisałem robiła, bo jest to tak skomplikowane, przedebuggowanie tego jest też okropnie trudne, więc ten kod, który na początku wydawał mi się mega fajny, abstrakcyjny i idealnie zawierający funkcjonalność w kilku prostych, znaczy prostych, w kilku funkcjach nagle okazał się mega skomplikowany.

Mateusz: Ja mam już jeden przykład, który trochę to potwierdza. Powiedziałem kilka chwil wcześniej, że dla osób, które wchodzą w projekt i nie mają doświadczenia, ale mam w zasadzie przykład, którym pokazuję to trochę też z drugiej strony w projekcie, w którym jestem mamy lidera technicznego, który jest osobą backendową skupioną przede wszystkim na technologiach backendowych. Coś tam pisał kiedyś w JavaScripcie jakieś prostsze rzeczy, więc język jako tako ogarnia, kojarzy, umie czytać. No i pewnego dnia pięknego w projekcie była Ramda, więc ja tą funkcjonalność utrzymałem w Ramdzie, tak jak tak jak została napisana oryginalnie ją po prostu rozwinąłem w tej Ramdzie. Poszło to do review i lider wchodzi sobie do tego Pull requesta, patrzy i komentuje, że on nic z tego nie rozumie, że tak naprawdę ten kod nie nadaje się do tego, żeby znalazł się w projekcie tak naprawdę, ponieważ nikt kto nie zna tego rozwiązania nie będzie w stanie go przeczytać. Chłopak ma przynajmniej te 8 lat doświadczenia na stanowiskach takich seniorskich - liderskich. Zna JavaScript. Z Ramdą się nie spotkał i ma sporo doświadczenia, najwięcej doświadczenia ma właśnie z C# i .NETem i nie był w stanie przez Ramdę przejść, więc wydaje mi się, że właśnie stosowanie takich bibliotek jak Ramda powoduje, że łamiemy tą jedną z podstawowych zasad, czyli nie utrzymamy tego w sposób prosty i na pewno nie będzie to zrozumiałe dla osób, które do tego projektu wchodzą. Jest taka książka Zrozumieć programowanie. W tej książce jest taka hipoteza postawiona na początku, że osoby, które znają przynajmniej jeden język programowania w podstawach i język angielski są w stanie łatwo przeczytać, powinny być w stanie łatwo przeczytać każdy język wysoko poziomowy i zrozumieć ogólną zasadę jak działa program. Wydaje mi się, że stosowanie Ramdy na przykład spowoduje, że nie jest to możliwe po prostu.

Wojtek: Zgadzam się z Tobą w 100% i myślę, że te nasze dyskusje na temat Ramdy i Lodasha świetnie pokazują zasadę, o której mówiliśmy, czyli KISS.

Mateusz: Tak jest. Ale oprócz KISS możemy też wspomnieć jeszcze o jednym bardziej może filozoficznym aspekcie, czyli mam na myśli taką zasadę, ale tym razem nie wziętą z inżynierii wojskowej, a w zasadzie z ekonomii. Czyli Brzytwę Ockhama. Pan Ockham stworzył sobie taką zasadę, pojęcie, która w metodologii naukowej sprowadza się do tego, że powinniśmy upraszczać pewne rzeczy. Im prostsze rozwiązania, tym lepsze rozwiązania. Dążyć powinniśmy do prostoty. To też jest jedna z zasad, którą powinniśmy stosować w ramach naszych projektów i ona jest bezpośrednio powiązana powiązana z zasadą KISS. Spotkałeś się z tym, żeby wspominać o Ockhamie w kontekście programowania?

Wojtek: Przyznam Ci się szczerze Mateuszu, że nie. Myślę, że tutaj ciekawa jest różnica pomiędzy tą zasadą KISS, o której przed chwilą rozmawialiśmy i Brzytwie Ockhama o której mówimy teraz, ponieważ dla mnie one wydają się bardzo podobne. Czy ty masz jakieś inne doświadczenia w tym kontekście?

Mateusz: Są podobne. Tu się muszę zgodzić. Tylko jedna mówi o dążeniu do prostoty. Czyli tak naprawdę powinniśmy upraszczać za każdym razem, kiedy o tym mówimy i w zasadzie pochodzi z trochę innego obszaru, bo mówimy o heurystykach, o ekonomii myślenia. Więc tak naprawdę to jest troszeczkę inny aspekt. A tutaj mówiliśmy o inżynierii, a programowanie jest bezpośrednio związane z inżynierią. Można powiedzieć, że jest to inżynieria, tylko że w tym wypadku oprogramowania. Tutaj mówiliśmy wcześniej o inżynierii samolotowej. Natomiast fajnie też to pokazuje, jak bardzo programowanie jako dziedzina czerpie z różnych innych dziedzin tak naprawdę i wykorzystuje pewne metody, zasady, które powstały zupełnie w innym celu. OK. Jeśli mówimy o KISS, to warto też wspomnieć o kolejnej zasadzie, czyli mówimy o DRY. Jeśli DRY to?

Wojtek: Don't Repeat Yourself?

Mateusz: Boże Wojtek, co za wiedza. Co powiemy o Don't Repeat Yourself - warto jest się powtarzać czy się nie powtarzamy?

Wojtek: Tak, jeśli chodzi o Don't Repeat Yourself, znowu myślę, że jest to fajna zasada po prostu. Ale jak to zwykle bywa w życiu są jakieś "ale" do tej zasady i jest to powiązane z początkiem naszej rozmowy, czyli rozmową taką wstępną o abstrakcji i tego, gdzie tworzyć. Bo myślę, że w momencie kiedy podchodzimy czy też podążamy za zasadami tak religijnie i dążymy do tego, żeby żaden kawałek był nie powtórzony, możemy dojść do takiego momentu, czy też myślę, że bardzo szybko dojdziemy do takiego momentu, kiedy właśnie tworzymy bardzo dużo abstrakcji, które są nieprzydatne i zaciemniają nam ten obraz kodu. Co o tym sądzisz Mateuszu? Myślisz, że to działa jakoś inaczej.

Mateusz: Inaczej nie. Zgadzam się z Tobą. Bardziej myślę o tym, że Don't Repeat Yourself jest taką jedną z podstawowych zasad, którą się też mówi ludziom, którzy wchodzą do branży i którzy zaczynają się tego uczyć. Nie powtarzaj siebie. Spróbuj stworzyć większą abstrakcję. Spróbuj tak to zbudować, żeby móc ten kawałek kodu wykorzystać ponownie. Nie mówi się w zasadzie o odwrotnej zasadzie. Nie mówi się o zasadzie, która jest odwrotnością DRY, czyli o WET, czyli Write Everything Twice. Zastanawiam się nad konceptem dlaczego tak się dzieje? To też poruszyliśmy na samym początku, że osoby, które są początkujące, są juniorami, bardzo często nie znają w ogóle pojęcia abstrakcji i tej abstrakcji prawie w ogóle nie używają, więc dla nich naturalnym jest stosowanie zasady WET.

Wojtek: To prawda.

Mateusz: I mówi się im, żeby stosowali zasadę DRY, czyli stosowali zasadę Don't Repeat Yourself, żeby używali tej abstrakcji. Tylko że dochodzimy do momentu, w którym tej abstrakcji używają, tak dobrze ją poznali i tak dobrze się w niej odnaleźli, że zaczynają zapominać o tej drugiej zasadzie WET. Czyli, że powinni zapisywać wszystko podwójnie. I tutaj ja mam taki trochę dylemat może, co robić? Bo rozumiem, jako doświadczony już można powiedzieć programista, rozumiem różnicę i jestem w stanie wychwycić, co powinno być bardziej DRY, a co powinno być bardziej WET. Natomiast osoby, które są początkujące tego nie załapią. Jako, że uczę początkujących również, to tak, mam tutaj właśnie taki mały dyskomfort mentalny. Która zasada dla nich jest bardziej odpowiednia?

Wojtek: Myślę, że z mojego doświadczenia przynajmniej ta zasada DRY na samym początku jest uczona w kontekście trochę czego innego niż abstrakcji. Inaczej, jest dalej abstrakcja, ale w trochę innym stylu bym powiedział. Bo ja zawsze, szczególnie na początku mojej drogi, jeśli chodzi o programowanie i drobnych nauk, które prowadziłem, że tak powiem, czy też z drobnych lekcji z programowania, które prowadziłem, bardziej mówiłem o niej w kontekście funkcji, tak na dobrą sprawę - takich najprostszych. I właśnie takiego programowania imperatywnego w stu procentach, kiedy piszemy pętlę for np, to znaczy może inaczej nie piszemy pętli for, tylko zamiast napisać kawałek kodu, który robi coś trzy razy, powtarza jakąś funkcjonalność trzy razy, wtedy używamy pętli for, zamiast wykonywać jakąś serię kroków czy też działań jakiegoś algorytmu, tworzymy funkcję, żeby można było ją wykorzystać kilka razy.

Mateusz: Tak, ale funkcja w tym wypadku jest narzędziem, które użyjesz właśnie do tworzenia abstrakcji chociażby. Bo czym będzie abstrakcja w naszym przypadku? Abstrakcja będzie jakimś kawałkiem kodu, który będzie mógł wykonywać jakąś operację, niezależnie od tego, jakie dane wejściowe otrzyma. Oczywiście musi być to odpowiednio zaimplementowane itd. Ale my nie będziemy się skupiać nad samą implementacją i to jest powtarzanie tego samego kodu. W przypadku właśnie funkcji też będzie dla nas jakimś wprowadzeniem nieświadomym na samym początku abstrakcji. Bo my tworzymy te funkcje, one wykonują jakąś operację. Ktoś kto czyta ten kod, szczególnie osoba początkująca, już widzi po nazwie ta funkcja robi to, więc w zasadzie możemy na tym przerwać. Pamiętam, jest taka gra dla dzieci stworzona, można powiedzieć, że dla dzieci. Wykorzystuje się ją w szkołach na lekcjach programowania, w niektórych szkołach, bo jak wiemy lekcje programowania nie są czymś super popularnym w szkołach. Niestety. W Polsce. Natomiast jest taka gra - "Code Combat" ona się nazywa i tam dzieciaki uczą się wykonywać funkcje różnego rodzaju np. funkcja "go" sprawia,że Twój bohater przemieszcza się z pola na pole. Żeby nauczyć się poruszać postacią musisz wykonać odpowiednią ilość razy funkcję "go". Natomiast optymalizacja na którymś tam module polega na tym, że wprowadzamy pętlę, która będzie to "go" wykonywała. Ale tam nie ma nic o tym czym jest "go", co jest pod spodem. "Go" jest jakąś abstrakcją. I teraz Don't Repeat Yourself będzie mówiło nam o tym, że my mamy tak jak powiedziałeś, stworzyć pętlę, która spowoduje, że nie będziemy tego powtarzać. To też wydaje mi się, że jest mocno powiązane z samą abstrakcją naszego kodu, że to co możemy skopiować, wykonać kilka razy, tak naprawdę możemy zapisać raz, zamknąć w jakąś abstrakcję i potem tego używać.

Wojtek: A takie pytanie z innej beczki troszeczkę przy okazji gier, bo mi przypomniałeś. Logomocje miałeś w szkole?

Mateusz: Co miałem?

Wojtek: Logomocję.

Mateusz: Logomocja?

Wojtek: To jest pierwsza moja styczność z programowaniem. Brzmi to dość podobnie do tego, o czym Ty mówisz. Mam nadzieję też, że dobrze pamiętam nazwę tego software'u. Nie kojarzysz czegoś takiego, że masz żółwika, który jeździ sobie po ekranie i musisz narysować wzorki?

Mateusz: Nie, nie kojarzę. Jak ja byłem w szkole na lekcjach informatyki, graliśmy w Delux Ski Jumping, ewentualnie w Duke Nukem 3D.

Wojtek: Kurczę, klasa.

Mateusz: To było dość dawno temu. Ewentualnie co my jeszcze robiliśmy? Nasza nauczycielka od informatyki była raczej matematyczką, więc to co nam dawała, to Painta ogarnialiśmy, ewentualnie jakieś podstawowe rzeczy w notatniku. Najbardziej skomplikowana rzecz jaką na informatyce w szkole robiliśmy to była strona w html'u, chyba o sobie.

Wojtek: No dobra, ale wracając do tematu i odpowiadając na Twoje pytanie myślę, że to abstrakcje są potrzebne i uważam, że to jest naturalna droga rozwijania się jako programista. Żeby na początku tą zasadę DRY zrozumieć do bólu i dopiero wtedy przechodzić na ten WET. I myślę, że te abstrakcje są nam bardzo potrzebne jeśli chodzi o programowanie, bo samo to środowisko w którym istniejemy, że jest to po prostu, ciężko nawet policzyć, ile poziomów abstrakcji i na ilu poziomach abstrakcji pracujemy. Od przeglądarki po komputery, bo wszystkie procesy, które się tam dzieją itd. Itd. Więc zdecydowanie jest nam potrzebne w którymś momencie to odcięcie i stwierdzenie ok, dzieje się pod spodem magia.

Mateusz: Tak samo programowanie jest abstrakcją.

Wojtek: Dokładnie.

Mateusz: Programujemy w bardzo wysoko poziomowych językach. Gdzie my się nie zastanawiamy nad tym jak te bity są przesuwane w pamięci.

Wojtek: Dokładnie tak.

Mateusz: To w takim razie skoro wiemy, że abstrakcja jest nam potrzebna, to dlaczego wprowadzamy WET? Przecież WET zabija tą abstrakcję. Dokładnie robi to, czego mówiliśmy, że nie powinniśmy robić. Dochodzimy do momentu, w którym zapisujemy wszystko podwójnie, czyli tak naprawdę każdą funkcję, każdą funkcjonalność, którą chcemy wprowadzić musimy zapisać drugi raz, jeśli chcemy ją użyć zgodnie z tą zasadą. Na pierwszy rzut oka wydaje się, że to jest bez sensu całkowicie.

Wojtek: Tutaj, myślę, że jeszcze pogadamy o tym AHA Programmingu. Znaczy o tej zasadzie AHA, bo ona się z tym wiąże. Tutaj też ciekawostka właśnie o której mówił Kent C.Dodds - w ogóle jak dotarł do tej nazwy AHA, i która jest odpowiedzią też na Twoje pytanie. Czyli początkowa nazwa tej zasady to było MOIST coś pomiędzy DRY i WET, prawda? I znowu wracamy do tego, jak wydaje nam się, i to, o czym pierwotnie rozmawialiśmy, tak jak wspomniałeś, Mateuszu, o tej drodze programisty, czyli działamy według tej zasady DRY do bólu i dochodzimy do takiego momentu, kiedy te nasze stworzone abstrakcje zaczynają bardziej przeszkadzać niż pomagać. I wtedy dochodzimy do tego momentu, kiedy staramy się być bardziej WET, jeśli można tak powiedzieć. Czyli kopiujemy ten kod i czekamy chwilę, czy też w moim przypadku tak jest. Czekam chwilę. Tak patrzę sobie, czy na pewno ten kod, upewniam się, czy stworzenie abstrakcji jest rzeczywiście odpowiednią decyzją. Czy ten kod rzeczywiście jest tak podobny, jak mi się wydaje? Czy ta funkcjonalność jest dokładnie taka sama? Czy rzeczywiście ta abstrakcja jest tutaj potrzebna? Stan to WET, czyli naturalna droga przejścia od bycia suchym do bólu, do bycia troszkę bardziej WET, jeśli można tak powiedzieć.

Mateusz: Mokrym do bólu.

Wojtek: Tak, tak.

Mateusz: Ci, że chyba nigdy nie pisałem tak typowo WET. Żeby wszystko pisać podwójnie. Spotkałem się z tym, że abstrakcja była dla mnie problemem. Niejednokrotnie, bo kiedy chcemy wprowadzić do funkcjonalności jakieś nowe warunki brzegowe, to ta nasza abstrakcja przyjmuje już tyle warunków, tyle ma możliwości i ifów w środku, że ta logika, która jest zamknięta w tej naszej abstrakcji jest już tak złożona, że aż trudno powiedzieć, co ta funkcja w zasadzie robi. I tu się zgodzę, że wtedy WET się przydaje fajnie, bo możemy kopiując tą funkcjonalność, upraszczamy ją niejako, upraszczamy ją i wywalamy z niej te rzeczy, które tak naprawdę powodowały, że ten kod pomimo tego, że powinien być łatwiejszy w odczycie stał się po chwili trudniejszy, trudniejszy w odbiorze. Kent C. Dodds miał ten sam problem. Kim jest Kent C. Dodds? Tu warto też wspomnieć, to jest dość znana postać. Każdy kto zajmuje się Javascriptem powinien kojarzyć to nazwisko. Jest nauczycielem, tak naprawdę uczy też ludzi JavaScriptu. Pracuje przede wszystkim w Javascript'cie jako Software Engineer i tak naprawdę można powiedzieć, że on dużo tych kursów swoich udostępnia. Jest dość rozpoznawalny i znany w środowisku i warto go obserwować.

Wojtek: I myślę, że warto wspomnieć Mateuszu, że stworzył wiele bibliotek, z których wszyscy korzystamy m.in. Testing Library do Reacta!

Mateusz: Dokładnie tak. Więc jeśli dość znany i warto go śledzić, jeśli tego nie robicie, to polecamy, żebyście się zastanowili nad tym, bo warto też obserwować. Oboje chyba mamy takie zdanie. Warto obserwować wartościowych ludzi, którzy rozwijają tę społeczność, a Kent C. Dodds niewątpliwie do takich należy. No i Kent C. Dodds miał taki problem, właśnie podobny, o którym my wspominaliśmy, czyli że wszyscy mówili mu pisz DRY. Potem mówili pisz WET. Spotykał te same problemy, czyli w momencie, kiedy pisał w tym DRY dochodził do momentu, kiedy ta abstrakcja była już tak złożona, że już była niezrozumiała, więc zaczął pisać WET. W pewnym momencie stało się tego kodu tak dużo, powielonego, że stało się to aż zbyt rozwodnione, zbyt mocne. I doszedł do swojej własnej koncepcji, którą opracował. I ta koncepcja ma być takim balansem pomiędzy DRY i pomiędzy WET. On to nazwał AHA, wymawiane tak jak aha, czyli tak, jakbyśmy jakieś odkrycie zrobili. AHA jest akronimem oczywiście. Jest akronimem od słów Avoid Hasty Abstractions, czyli tak naprawdę unikaj pochopnych abstrakcji. Czyli takich, które są bezcelowe. Co myślisz o jego pomyśle, o jego koncepcji, jego zasadzie AHA?

Wojtek: Myślę, że jestem ogromnym fanem Kent C. Dodds'a. I myślę, że tą zasadę świetnie podsumował cały nasz podcast czy też dzisiejszy odcinek naszego podcastu. Pomyśl, że jest to idealne połączenie tych dwóch zasad. I bardzo dobra zasada, chociaż nie jest taka jasna i nie wyznacza takich jasnych granic, ale myślę, że to właśnie dlatego jest taka dobra. Jest odpowiednim podejściem do pisania kodu, czyli tworzenie tych abstrakcji dokładnie w tym momencie, kiedy są potrzebne. Nie za wcześnie, nie za późno.

Mateusz: Nie sądzisz, że poprzez to, że ta zasada nie ma takich granic, jest trudna w stosowaniu?

Wojtek: Myślę, że trochę tak. Ale tutaj też pytanie w którym momencie naszej drogi jako programiści jesteśmy? Zdecydowanie domyślam się, że część tej zasady jest podyktowana tym, jak się czujemy i co wiemy z naszego doświadczenia. Chociaż myślę, że to też daje dużo dobrych wskazówek, które pomogą nam dojść do takiego momentu, kiedy będziemy lepiej zauważać te miejsca, gdzie tę abstrakcję stosować, i gdzie tych abstrakcji nie stosować. Sam Kent C. Dodds mówił, że czasami musi sobie przypominać i walczyć ze sobą, żeby tych abstrakcji nie tworzyć. I też wspominał w swoim kursie, w którym mówi o tej zasadzie, że czasami łapie się, że dzięki temu, że zatrzymał się i nie zrobił tej abstrakcji, właśnie zwrócił uwagę, zauważył, że ta abstrakcja nie była poprawna, a musiał ze sobą walczyć na samym początku, żeby jej nie robić.

Mateusz: Tak, to jest dla nas typowe chyba, ale wydaje mi się, że czasami tworzymy coś, wydaje nam się, że jest ok. A potem dochodzimy do wniosku po czasie, gdy ten projekt istnieje, że wprowadzenie abstrakcji w tamtym konkretnym miejscu było w zasadzie wrzodem na czterech literach, w zasadzie utrudniło nam późniejszą pracę, a nie ułatwiło ją. Pewnie niejeden z nas, nie jedna osoba z nas tak naprawdę miała dokładnie ten sam problem. Ale wydaje mi się, że AHA nie jest dedykowana dla osób, które nie mają jeszcze tego doświadczenia. Trudno wymagać od juniora od osoby, która dopiero zaczyna, żeby stosował, stosowała tę zasadę świadomie. Kiedy tak naprawdę my uczymy ją jeszcze, tą osobę, uczymy ją jeszcze stosowania chociażby DRY.

Wojtek: Zgadzam się z Tobą w stu procentach, Mateuszu. Jest to ewolucja i myślę, że ta kolejność, w której dziś rozmawiamy o tych zasadach jest bardzo dobrą wytyczną moim zdaniem, jeśli chodzi o drogę taką, którą powinniśmy moim zdaniem przechodzić jako programista, czyli jeszcze raz DRY do bólu, potem WET i na końcu AHA.

Mateusz: KISS na początku, czyli zaczynamy od KISSa. Dajemy buziaka suchego ważne. Potem mokry i mamy AHA, ale mam jeszcze jedną zasadę, Wojtek. Mamy jeszcze jedną zasadę, o której chcielibyśmy porozmawiać. Jest zasada, która nazywa się YAGNI, czyli You Aren't Gonna Need It. I to jest chyba problem, z którym ja się spotykam non stop podczas projektów, które tworzone są w ramach w ramach naszej pracy, gdzie dostajemy jakieś wytyczne do stworzenia i sobie myślimy o tutaj, to w przyszłości można by było zrobić coś takiego, więc ja tutaj napiszę jakieś TODO albo zacznę napiszę jakąś podstawową funkcję, a ona jeszcze nic nie będzie robić, tylko w środku komentarz, że tu jest miejsce na zrobienie tego. Ewentualnie, dla bardziej zaawansowanych, napisze taką funkcjonalność i jej nigdy nie użyję. To właśnie jest problem, z którym chcę walczyć zasada YAGNI. A jakie masz Ty doświadczenia? Sam piszesz kod, którego potem nigdy nie użyjesz?

Wojtek: Muszę przyznać, że pewnie mi się zdarza, ale zgadzam się w stu procentach i myślę też, że to pewna część naturalnej drogi w momencie, kiedy stajesz się coraz lepszym developerem, kiedy dochodzisz do tego, że np. zaczynasz nowy projekt i chcesz się popisać, i użyć tej całej wiedzy, którą masz, więc przygotowujesz się na każdą ewentualność, tworzysz ten kod mega abstrakcyjny, w trochę backendowych terminach tworzysz od samego początku mikro serwisy, mikro frontendy, kod jest tak abstrakcyjny, że zanim dochodzi do tworzenia podstawowych funkcjonalności to już masz stworzoną ogromną ilość kodu i nie wiadomo jaki proces do jego tworzenia. Myślę, że zaciemnia to obraz naszego kodu. Też sam Kent C. Dodds mówił o tym, że kod powinien być stworzony do wymagań, które są teraz, a nie do wymagań, które będą jutro, ponieważ przewidywanie jutra jest nie możliwe i powinniśmy być dopasowani do zmian i mieć możliwość wprowadzenia tych zmian jak najszybciej, a nie starać się przewidzieć teraz przyszłość i tworzyć ten kod jak najbardziej abstrakcyjny, pokrywający jak największą część przypadków.

Mateusz: Teraz pomyślałem, że może AI, jakiś czat GPT mógłby pokrywać takie rzeczy np. może wróżyć z fusów na przykład, albo przewidywać co nasza aplikacja powinna, albo będzie potrafiła jutro.

Wojtek: Jest to jakiś pomysł. Tylko dalej czy będziesz miał rację?

Mateusz: Ludzie chodzą do wróżki, wróżki mają rację. Wojtku, byłeś kiedyś u wróżki

Wojtek: Nie byłem kiedyś u wróżki, ale domyślam się, że teraz jest znacznie łatwiej, bo mogą napisać sobie taki prompt w czacie GPT i mają odpowiedź. Już nawet nie muszą o tym myśleć i wymyślać.

Mateusz: Tak apropo AI ostatnio pojawiają się coraz to nowe zastosowania. Widziałem video, które było wygenerowane, widziałem aplikację co dzisiaj wysłałem do poprawienia dźwięku z AI. Kto wie - może aplikacja do wróżenia z wykorzystaniem AI to by było coś ciekawego.

Wojtek: Startup idea!

Mateusz: Może powinniśmy iść do Marcina i powiedzieć, że chcemy mamy taki pomysł na startup.

Wojtek: I jest to jak najbardziej opcja.

Mateusz: Pozdrawiamy Marcina. Mamy nadzieję, że słuchasz. YAGNI mówi nam o tym, że powinniśmy taki kod eliminować, bo tak jak powiedziałeś nie jesteśmy wróżkami, i każdemu z nas się zdarza, że wprowadza takie rzeczy. W zasadzie jesteśmy zgodni z tym, że niepotrzebnie dodajemy to, ale to kusi, bardzo mocno to kusi. No bo przecież chcesz, jeżeli pracujesz w jakimś projekcie, chcesz go zrobić jak najlepiej się tylko da i tak naprawdę dajesz od siebie więcej. Tylko warto wspomnieć o tym, jakie to później rodzi problemy. Chociażby przyjemne refaktoringu tego kodu, czy też przy wielkości bundle'a, który ostatecznie zostanie opublikowany, czy też ostatecznie przy developmencie. Kiedy osoby powtarzają się, ktoś dostaje jakąś funkcjonalność, która już wcześniej była napisana, nie wie, że została napisana, bo nie ma jej w dokumentacji i tworzy dokładnie to samo. Jeszcze raz tak naprawdę niepotrzebnie przepalany jest ten czas, więc wydaje mi się, że to jest bardzo ważna zasada, o której nie mówi się w kontekście, kiedy mówimy o DRY czy o KISS. Najczęściej pomijamy te WET, YAGNI i ostatnio królujące nam AHA, a myślę, że każda z nich ma jakąś wartość. Chciałbyś się coś dodać o YAGNI (o naszym jagnięciu)?

Wojtek: Jeśli chodzi o YAGNI to zgadzam się z Tobą w 100 procentach. Też tak powiedziałem. Rzeczywiście kusi i to naturalne, nawet chęć popisania się swoją wiedzą i udowodnienia sobie, że mogę to zrobić, mogę to zrobić, żeby to przewidywało tysiąc ewentualności. Ale tak jak powiedziałeś, niestety zaciemnia to w większości przypadków kod i tworzenie kodu tylko po to, żeby pokazać co umiemy i tylko po to, żeby stworzyć dla niego testy i on nie był wykorzystywany przez nikogo innego, tylko służył§ po to, żeby testy przechodziły. Zdecydowanie nie ma dużego sensu.

Mateusz: Znamy jeszcze jakieś zasady, bo ja na ten moment sobie żadnej nowej przypomnieć nie mogę.

Wojtek: Myślę, że mi też już żadne nie przychodzą do głowy, że te są najważniejsze, te, o których się słyszy przez całą swoją drogę, przez całą swoją o karierę, jeśli chodzi o programowanie.

Mateusz: Wojtku, to według Ciebie które z tych zasad mają najwięcej wartości? Dla nas jako programistów, co moglibyśmy poradzić naszym kolegom mniej doświadczonym może, albo nawet tym bardziej doświadczonym, powiedzmy na stanowiskach regularów, mid developerów? Jakie zasady stosować? W jaki sposób je stosować? Czy jakaś jest ważniejsza niż pozostałe? Na co warto zwrócić uwagę najczęściej?

Wojtek: Myślę, że zasada KISS jest uniwersalna niezależnie od poziomu. Mam nadzieję, że się ze mną zgodzisz, Mateuszu, że chcemy, żeby ten kod był jak najprostszy i że im prostsze rozwiązanie problemu tym lepsze. I myślę, że jeśli chodzi o taką drogę, którą widzę dla tych naszych mniej doświadczonych kolegów, powiedziałbym, że jest.

Mateusz: I koleżanek.

Wojtek: I koleżanek, oczywiście, mniej doświadczonych kolegów i koleżanek, jest to właśnie przejście przez zasady DRY, zrozumienie jej do bólu, potem przejście do zasady WET i skończenie na zasadzie AHA. Myślę, że to też bardzo naturalny proces. Właśnie tworzenie tych abstrakcji, utworzenie ich masy i zrozumienie, że tworzenie abstrakcji dla zrobienia samej abstrakcji nie jest super i powtórzenie czasami kodu tego samego i skopiowanie go czasami może naprawdę ma duży sens wbrew temu czego uczymy się na początku. Masz inne zdanie Mateuszu?

Mateusz: Zdania innego nie mam. Aż głupio się tak ciągle z Tobą zgadzać, ale przez to, że jesteś doświadczoną osobą to ciężko się z Tobą nie zgadzać.

Wojtek: Dziękuję Ci bardzo Mateuszu, ale to też mówisz komplement sobie. Ty też jesteś jak najbardziej doświadczoną osobą.

Mateusz: Ach, dziękuję Wojtku, Kompetencje aż biją. Zgadzam się w stu procentach. Podoba mi się pomysł przejścia z DRY do WET i później do AHA. Zdaje się, że Kent C. Dodds wymyślił coś, czego brakowało i powiedział w zasadzie coś, co każdy senior chyba wiedział.

Wojtek: Tak, zgadzam się.

Mateusz: Czyli, że ten poziom abstrakcji, który wprowadzamy często może być problematyczny. I to też jest chyba taka naturalna ścieżka w stosowaniu tego poziomu abstrakcji. Junior bardzo często abstrakcji nie używa, bo po prostu jej nie bardzo rozumie i nie bardzo wie jak ją tworzyć. Więc sens tej abstrakcji w kodzie tworzonym przez takich początkujących programistów bardzo często jest bardzo mało. Natomiast z czasem ten rozwój postępuje. Stosowanie tej zasady DRY wprowadza coraz więcej tej abstrakcji i myślę, że możemy to też często zaobserwować u programistów ze średnim poziomem doświadczenia, gdzie w zasadzie cały kod jest abstrakcją, jedną wielką abstrakcją. Jest on bardzo złożony, bardzo trudny w odbiorze i później te same osoby przechodząc na level wyżej, gdzie już wchodzą na stanowiska seniorskie, zauważają problem, do którego doprowadziły i starają się świadomie rozdzielać to, co powinno być abstrakcyjne od tego, co abstrakcją być nie powinno. I to jest taka naturalna ścieżka wydaje mi się. Tak jak wspomniałeś u programistów i programistek widać analogie pomiędzy poziomem programisty a poziom abstrakcji w projektach. Podsumowując zgadzam się, że ta ścieżka poprzez DRY i przez WET do AHA z ciągłym towarzystwem YAGNI i KISS jest chyba najlepszą drogą jaką można sobie wybrać. Tak, to na pewno spowoduje, że te nasze projekty będą ciekawe, fajne, dobrze zbudowane. I może nie będą takie dynamiczne.

Wojtek: Tak, zgadzam się z Tobą. Myślę, że jest to świetne podsumowanie. Dziękuję Ci za dzisiejszą rozmowę. Dziękuję naszym słuchaczom za słuchanie i chyba możemy powiedzieć do usłyszenia w następnym odcinku.

Mateusz: Do usłyszenia i możemy też zaprosić do subskrybowania, komentowania, odpowiadania na pytania. Jeżeli macie jakieś ciekawe pomysły na nowe odcinki. My co prawda mamy już sezon pierwszy zaplanowany, ale niedługo będziemy planować sezon drugi. Idzie nam to całkiem nieźle.

Wojtek: Zgadzam się. Poza tym mimo naszych planów nie oznacza, że nie może być jakichś zmian.

Mateusz: Tak jest. Zmiany jak najbardziej w zwinnym podejściu do programowania są mile widziane.

Wojtek: I nagrywaniu podcastu oczywiście.

Mateusz: Oczywiście, że tak. Dzięki Wojtku za dzisiaj. Dziękujemy Wam wszystkim za wysłuchanie i do usłyszenia.

Wojtek: Do usłyszenia.