To jest 202. odcinek podcastu Porozmawiajmy o IT, w którym w cyklu rozmów z Łukaszem Drynkowskim z portalu z ogłoszeniami o pracy w IT o nazwie Solid.Jobs, który to zresztą mam przyjemność współtworzyć, dyskutujemy o narzędziach programisty. Zapraszamy do słuchania i komentowania. 

A teraz życzę Ci już miłego słuchania.

Odpalamy!

Cześć!

Witam w nowej serii podcastów, które będą się ukazywały w ramach Porozmawiajmy o IT i w której to serii będziemy rozmawiać wraz z Łukaszem o narzędziach programistów, ale nie takich narzędziach jak klawiatura mechaniczna czy nowa skórka do VS Code’a, ale o podstawach. Skupimy się na tym, co ważne, co należałoby wykorzystywać wręcz w każdym zespole programistycznym.

Cześć, Łukasz! Bardzo miło mi Cię tutaj powitać.

Cześć, Krzysztof. Dzięki za zaproszenie.

W pierwszym odcinku rozpoczynającym serię podcastów skupimy się na Code Review, na narzędziu, które, mam wrażenie, że jest z nami już na tyle długo, że nam trochę spowszechniało, że podchodzimy do niego jako do pewnej oczywistości. Nie wiem, czy się ze mną zgodzisz, ale jak dla mnie przypomina to nieco historię z Gitem, gdzie jeszcze parę lat temu praktycznie w każdym ogłoszeniu o pracę dla programistów widniało takie wymaganie, że kandydat musi mieć opanowanego Gita, nawet było to gdzieś tam weryfikowane. 

I tak samo jest z Code Review. Jeszcze parę lat temu całkiem sporo się na blogach, wpisach, konferencjach wręcz mówiło o tym, jak podchodzić do Code Review, jakie są dobre praktyki, jak z tego jak najwięcej wynieść itd. Teraz mam wrażenie, że ten temat zupełnie ucichł albo po prostu przyzwyczailiśmy się do tego, że każdy zespół programistyczny już przyjął tę praktykę, stosuje ją i nie trzeba za dużo o niej mówić. Co Ty o tym myślisz?

Tak, myślę, że masz rację. Code Review jest dość powszechnie używane, ale też w dużej mierze jest wykorzystywane w ten sam sposób, zamknęliśmy się trochę w pudełku i skupiliśmy an narzędziach takich jak Azure DevOps, Bitbucket i myślę, że to jest z kolei zła rzecz, ponieważ Code Review jest czymś bardziej uniwersalnym. I mam nadzieję, że uda nam się to tutaj w rozmowie pokazać.

Code Review jest dość powszechnie używane, ale też w dużej mierze jest wykorzystywane w ten sam sposób, zamknęliśmy się trochę w pudełku i skupiliśmy an narzędziach takich jak Azure DevOps, Bitbucket i myślę, że to jest z kolei zła rzecz, ponieważ Code Review jest czymś bardziej uniwersalnym.

Tutaj znowu mogę odnieść się do analogii z Gitem, gdzie jest mnogo różnych funkcjonalności, tymczasem wykorzystuje się kilka podstawowych. I tak samo pewnie spłyciliśmy troszkę Code Review, zdefiniowaliśmy go, patrząc na to narzędzie z perspektywy narzędzi głównie internetowych, dostępnych do Code Review. Spróbujmy więc tę perspektywę nieco rozszerzyć. Czy Code Review to zawsze musi być tylko sprawdzenie kodu, parę komentarzy, ewentualnie approve? Co według Ciebie można by ewentualnie dołożyć albo jak inaczej jeszcze spojrzeć na Code Review, żeby taką szerszą perspektywę załapać?

Przede wszystkim Code Review może przybierać różne formy. Jedna forma to po prostu zapytanie się kolegi/koleżanki: Mam z czymś problem, zobacz tutaj, czy też rozwiązujemy jakąś architektoniczną zagwostkę, zróbmy to razem. Przedstawiam moje rozwiązanie i dostaję od razu feedback. Czyli możemy też powiedzieć, że pair programming jest pewną formą kompletnie synchronicznego Code Review, w przeciwieństwie do takiego asynchronicznego podejścia z narzędziami takimi jak Azure DevOps.

Właśnie, nie musi to zawsze polegać na tym, że wystawiamy jakiegoś pull request’a, ktoś sobie do tego siada, przegląda, uruchamia kod, klika, sprawdza i dopisuje swój komentarz. Możemy na różnym wręcz etapie rozwoju kodu, jego pisania o taki Code Review poprosić, czy to sąsiada z biurka obok, czy kogoś z drugiego końca świata. Różne poziomy, różne stopnie asynchroniczności możemy wprowadzić.

Ale jestem ciekawy tego, co powiedziałeś, że pair programming to też może być rodzaj Code Review. Czy według Ciebie działa to tylko wtedy, gdy mamy taki klasyczny podział, że jedna osoba pisze, druga patrzy na ten kod i sobie meta analizuje albo trochę próbuje wyciągać jakieś abstrakcje? Jak byś tak praktycznie zaimplementował Code Review w przypadku pair programmingu?

Myślę, że takie najczęściej stosowane pair programming, to jedna osoba jest przy klawiaturze, pisze, druga na bieżąco komentuje. I możemy robić oczywiście co jakiś czas zamianę.

Właśnie, o tej zamianie głównie myślałem, bo w takim klasycznym podejściu faktycznie jedna osoba analizuje, druga pisze, ale myślę, że co jakiś czas warto wyjść z tego pudełka, stanąć z boku, popatrzeć na to z szerszej perspektywy i wtedy możemy zauważyć coś, co nam gdzieś umyka, jak skupiamy się na pojedynczej linijce kodu. Więc myślę, że takie zmienianie się jest wartościowe.

Okej, mamy teraz mnogość różnych ofert z pracą zdalną i z racji tego korzystamy z narzędzi, które umożliwiają przeprowadzanie Code Review właśnie w ten sposób, ale gdybyśmy byli w takim klasycznym wydaniu pod tytułem biuro i mieli kogoś z boku do przeprowadzenia Code Review, to czy według Ciebie jest jakaś wartość w tym, żeby zaprosić autora, np. tego pull requesta, skoro już jesteśmy tutaj przy tym flow, i zadawać jakieś pytania, zupełnie synchronicznie, nie poprzez komentarze.

Tak. Myślę, że to ogólnie jest właśnie błąd, który popełniamy jako deweloperzy, że to Code Review odbywa się zupełnie asynchronicznie i osoba, która napisała kod, wystawiła pull request, nie bierze udziału w tym przeglądzie, a zaproszenie tej osoby niewiele kosztuje. Możemy od razu się dopytać o intencje, bo to jest nasz cel przejrzenia tego kodu tak naprawdę: zrozumienie, co tam się dzieje i stwierdzenie, czy to zostało wykonane zgodnie ze sztuką. I dzięki tej interakcji z autorem możemy też wspólnie kolejną iterację wymyślić, bo zapewne za pierwszym razem nigdy to nie jest idealne. I też to Code Review służy po to, żebyśmy mieli kolejne iteracje.

Tak. Myślę, że to ogólnie jest właśnie błąd, który popełniamy jako deweloperzy, że to Code Review odbywa się zupełnie asynchronicznie i osoba, która napisała kod, wystawiła pull request, nie bierze udziału w tym przeglądzie, a zaproszenie tej osoby niewiele kosztuje. Możemy od razu się dopytać o intencje, bo to jest nasz cel przejrzenia tego kodu tak naprawdę: zrozumienie, co tam się dzieje i stwierdzenie, czy to zostało wykonane zgodnie ze sztuką.

Tak. Do tego ja często zauważam coś takiego, że gdy próbujesz komuś wytłumaczyć jakąś rzecz, którą stworzyłeś, to zazwyczaj wtedy zaczynasz inaczej o tym myśleć, niż w momencie pisania, gdy było to jeszcze w Twojej głowie. Przynajmniej ja tak mam, że wtedy zauważam jakieś luki, staram się rozszerzyć nieco perspektywę i widzę, że może coś mi tam umknęło, może czegoś nie dopisałem, może o czymś nie pomyślałem. Dążę do tego, że próba objaśnienia komuś nawet w takiej luźnej rozmowie zmiany, którą zrobiłeś w kodzie, albo jakiejś zmiany architektury, cokolwiek, często zmienia Twój sposób myślenia o tym Twoim dziele, że się tak wyrażę.

Tak, może pociągnę to jeszcze trochę dalej, bo wydaje mi się też, że jeden z błędów, jakie popełniamy, to że wystawiamy pull request, dodajemy Reviewera i czekamy. A flow powinien być raczej taki, że wystawiamy pull request, sami go przeglądamy, wprowadzamy pierwszą partię poprawek i dopiero wtedy zapraszamy kolejne osoby do współpracy przy tym pull requeście.

Zaczęliśmy mówić o tym, na co zwrócić uwagę podczas Code Review. Myślę sobie, że to jest w sumie istotna rzecz, bo tak jak na początku wyszliśmy od tego, że spłycamy chyba znaczenie Code Review w tych naszych dzisiejszych zespołach, tak samo myślę sobie, że spłycamy cel albo przebieg Code Review, który w mojej obserwacji często sprowadza się do takiego literopodobnego zweryfikowania, czy ten kod w miarę się jakoś trzyma kupy, ewentualnie odpowiada jakimś naszym założeniom, jeżeli chodzi o zespół.

Tak, a to przecież jest bez sensu, bo mamy lintera  i on powinien się tym zająć. Tak że na pewno celem Code Review nie jest sprawdzenie, czy nawiasy są w dobrej linii.

Dokładnie. Wobec tego, o czym możemy powiedzieć, jako o najważniejszej funkcji albo celu Code Review? Co Ci od razu przychodzi na myśl, jak o tym myślisz?

Przede wszystkim myślę, że chcielibyśmy zrozumieć intencję autora i zrozumieć, dlaczego coś zrobił w ten sposób, a nie inaczej. Ważne jest też takie bardziej całościowe spojrzenie, z lotu ptaka, przydaje się wtedy oczywiście znajomość całej architektury danego programu czy modułu, i stwierdzenie, czy zostało to zrobione spójnie z tym, jak przyjęliśmy w całym projekcie, jakie przyjęliśmy wzorce, zasady. I też coś, czego linter nie zrobi, czyli sprawdzenie tych warstw abstrakcji, czy one nie są wymieszane, czy odpowiednie części kodu są w odpowiednich modułach, czy nie ma wycieków abstrakcji. Myślę, że to jest cel.

Jasne, czyli coś, co trudno jest zweryfikować za pomocą automatu, czyli architekturę. Myślę, że to jest ważna rzecz. Pewnie takich celów można wymienić całkiem sporo, na pewno powiedziałbym jeszcze o bardzo ważnym założeniu bezpieczeństwa, czyli że ten kod nie strzeli nam zaraz w stopę, jak pojawi się na produkcji. Na pewno warto się przyjrzeć temu, czy autor nie pominął jakichś istotnych case’ów, czy to rozwiązanie jest kompletne, czy nie ma niszczącego wpływu na inne rozwiązania. Myślę, że taka kompletność też jest istotna. I różnego typu błędy logiczne, które dosyć trudno jest wychwycić automatem.

Tak, wrócę jeszcze troszeczkę do tego, co mówiliśmy wcześniej, czyli do zasad przeprowadzania tego Code Review. Myślę, że kolejnym błędem, który zauważam, jest to, że Code Review sprowadza się do code review, myślę, że ta nazwa może być trochę myląca i że jednak warto sobie zrobić check out tego kodu, uruchomić, postawić gdzieś break pointy, zobaczyć ten przebieg sterowania, jak wygląda w praktyce, bo nie wszystko „na papierze” widać. I nie ma żadnej zasady, która mówiłaby, że nie możesz tego uruchomić, bo Code Review to tylko patrzenie w kod.

Niektórzy mogą się teraz kłócić, że to już podchodzi pod testowanie, ale myślę, że tutaj, w soft developmencie wszędzie granice są płynne i jednak to uruchomienie jest kluczowe.

Jasne, zwłaszcza że im wcześniej wyłapiemy różnego typu błędy, tym lepiej, tym mniej nas one kosztują. W momencie, kiedy to już pójdzie dalej, nie daj Boże, znajdzie się na produkcji i klient zgłasza nam problem, to wiadomo, że zawsze jest to dodatkowy koszt, przynajmniej emocjonalny, związany z tym błędem, więc lepiej jest to wyłapać na etapie Code Review.

Myślę sobie, że tu możemy też powoli przechodzić od takiego przebiegu Code Review do jego pozostałych znaczeń. Oczywistą funkcją Code Review jest sprawdzenie kodu, o czym tutaj powiedzieliśmy. Czyli też jakieś przełożenie na jakość całego produktu. Ale to niejedyne możliwe zastosowania.

To, co według mnie jest bardzo znaczące w przypadku Code Review, to wymiana wiedzy. Często obserwuję na swoim przykładzie, kiedy dołączam do jakiegoś projektu, zwłaszcza takiego rozwijanego ileś lat, że jakaś tam dokumentacja istnieje, ale w momencie, kiedy dostanę rzetelne review od osób, które znają już różnego typu case’y, przypadki, założenia, decyzje, które zostały wcześniej podjęte, to dużo szybciej wdrożę się, nauczę kodu związanego z tym projektem, niż gdybym próbował tego szukać w jakiejś dokumentacji itd.

Więc wymiana wiedzy według mnie jest niezwykle istotną funkcją Code Review. Również w przypadku osób początkujących, juniorów, którzy oprócz poznania domeny tego projektu muszą nadrobić jeszcze troszkę lekcji związanych ze sztuką wytwarzania oprogramowania; znajomością frameworka, języka, architektur, wzorców projektowych itd. Tutaj wszędzie Code Review ma istotną rolę polegającą na dzieleniu się wiedzą, uczeniu osób i przekazywaniu dalej tych różnych założeń, które sobie przedsięwzięliśmy jako team. Może nieraz da się to zweryfikować automatycznie, ale tych różnych architektonicznych założeń zazwyczaj musimy pilnować ręcznie i korygować ewentualnie osoby, które wychodzą poza te założenia.

Chciałbyś coś dodać jeszcze do tego?

Myślę, że fajną cechą jeszcze jest to, że to nie jest tak, że ten autor kodu uczy się od reviewera, tylko że to działa w obie strony. Ja, patrząc na ten kod i komentując, mogę się czegoś nowego dowiedzieć i ten autor też może wyciągnąć coś dla siebie z komentarzy. Dla juniora też fajnym ćwiczeniem jest przejrzenie kodu seniora i spróbowanie znalezienia jakichś niedociągnięć. Nikt nie jest też idealny.

W przypadku juniorów to wydaje się dosyć oczywiste, że ten przekaz wiedzy od osób bardziej doświadczonych może następować przez Code Review, ale tak jak powiedziałeś, nawet seniorzy mogą z tego wynieść coś rozwijającego. Bo rozwój IT jest na tyle szybki, że nikt nie jest w stanie wiedzieć wszystkiego i nawet osoba, która ma mniejsze doświadczenie, ale np. używała jakichś rozwiązań, bibliotek, skrótów itd. w poprzednim projekcie, może teraz spróbować podzielić się tymi swoimi umiejętnościami z osobami, które są teoretycznie dużo bardziej doświadczone, więc nawet seniorzy pewnie coś dla siebie znajdą w Code Review.

Przejdźmy teraz jeszcze do rozmowy o procesie. Jak myślisz, jak to jest z tym Code Review, czy ten czas jest np. wliczany w estymację zadań, czy PM wie, że taka praca musi być wykonana, czy jest to coś, co zaciągamy tutaj jako dług?

Jako programiści jesteśmy świetni w estymację i obawiam się, że niestety nie doliczamy tego czasu w żaden sposób. Zazwyczaj estymując jakieś zadania, zakładamy, że poświęcimy na nie tyle i tyle, może z jakimś małym zapasem itd. i cała ta estymacja skupia się na wytworzeniu kodu. Tymczasem są tego typu zmiany, w których Code Review i ewentualne jego konsekwencje, czyli np. naprawianie czegoś, dodawanie, rozszerzanie, może nawet zmiana koncepcji potrafią być ileś tam razy dłuższe niż samo to pierwotne wytworzenie tego pierwszego rozwiązania.

Więc uważam, że programiści zbyt rzadko uwzględniają ten czas na Code Review swoich pull requestów, swoich zmian, ale problem jest też szerszy i dotyczy pewnie organizacji PM-ów czy całego teamu w kontekście być może niezrozumienia, jak ważne jest Code Review. I rzadko kiedy PM-owie czy biznes widzą Code Review jako takie prawie że codzienne zadanie programisty; jako część dnia, która musi być wygospodarowana na to, żeby przejrzeć rozwiązania innych. Najczęściej jest to trochę mglista sprawa, trudno estymowalna, trudno przewidywalna. Bardzo ciężko jest założyć, ile czasu poświęcimy na przeglądanie np. pull requestów innych.

Myślę więc, że zbyt mało uwagi przykładamy do tego, ile czasu poświęcamy na Code Review.

Z racji tego, że jest to istotne zadanie, takie wręcz niemal codzienne, to myślę sobie, że warto byłoby powiedzieć, gdzie ma sens angażować czas człowieka w Code Review, rozumiane jako sprawdzenie jakości kodu, a gdzie już bardziej nam się opłaca zastosować jakieś mechanizmy, automaty, coś, co nas może tutaj wspomóc?

Myślę, że wszędzie tam, gdzie takie automaty są, to ich używajmy. Nie ma powodów, żeby tego nie robić. Czasami można też tę pracę wykonać dwa razy, nie zawsze ten interfejs jest też idealny, więc na to zwróćmy uwagę. Nie zawsze też jest poprawnie skonfigurowany, ale tak, starajmy się nie robić roboty, która jest bez sensu. Jeśli coś może zostać zautomatyzowane, to oczywiście automatyzujmy.

Niekiedy ta granica pomiędzy automatem a człowiekiem jest taka dosyć płynna, trzeba to w praktyce sobie wyczuć, co sprawdza się lepiej, natomiast oczywiście, co do zasady, wpasowujmy się w ten trend automatyzacji wszędzie tam, gdzie się da zaoszczędzić trochę czasu.

Jak już jesteśmy przy tej automatyzacji, to nie wiem, czy znasz takie rozwiązanie, które ma GitHub, nazywa się to GitHub Code Owner i polega na tym, że tworzymy sobie po prostu taki pliczek, jeśli oczywiście hostujemy tam, w ramach naszego repozytorium, gdzie definiujemy pewne szablony, linie czy też całe pliki i mówimy, kto jest właścicielem tej partii kodu. I w momencie, gdy pojawia się jakiś pull requestor i zmienia coś w tym zdefiniowanym przez nas szablonie kodu, to ta osoba jest automatycznie dodawana jako reviewer do tego pull requesta .

To jest taka trochę, według mnie, odpowiedź na problem, który często widzę, polegający na traktowaniu Code Review jako takiego trochę gorącego ziemniaka, że być może jest to do zrobienia, ale mam tutaj ważniejsze rzeczy. Wiesz, jak nie przypiszesz kogoś bezpośrednio do tego Code Review, to za bardzo nie ma chętnych, żeby je zrobić. Co myślisz o takiej automatyzacji reviewerów?

Azure Dev.Ops, czyli narzędzie, z którego osobiście przy projektach korzystam, też ma taką opcję. Ona oczywiście bywa przydatna, ale też zamyka nas w jakimś pudełku i powoduje zrzucenie tej odpowiedzialności na jedną osobę i ten wspólny agile’owy ownership na tym cierpi. Więc myślę, że tak, ale używane z rozsądkiem.

Myślę, że gdyby świadomość biznesu czy też produktu była trochę większa, że Code Review jest istotne, że musi być wliczane do czasu pracy programisty, to być może te moce przerobowe jakoś by się znalazły. Może się łudzę, ale chcę myśleć, że tak to mogłoby wyglądać. Bo w tym nawale pracy często ciężko znaleźć dodatkowy czas na przegląd czyjegoś kodu. Często jest to takie dodatkowe zadanie, które nie wiadomo, gdzie wcisnąć.

Dobrze, Łukasz, czy masz coś jeszcze do dodania, jeśli chodzi o Code Review? Jakieś praktyki albo może chciałbyś już to jakoś podsumować?

To może wspomnę jeszcze o jednej ciekawej praktyce, która jest takim trochę innym podejściem do Code Review, mianowicie Mob Review. Czyli takie review robione zbiorczo z całym zespołem bądź jego częścią. Spotykamy się w jakiejś salce, rzucamy na rzutniku kod czy pull request i w kilka osób, wśród którym powinien oczywiście się znaleźć również autor kodu, wspólnie robimy to, co się robi na Code Review. Czyli zastanawiamy się, czy to wszystko ma sens, czy to jest zrobione w dobry sposób, czy można byłoby to zrobić jakoś inaczej, lepiej, czy może z powodu ograniczeń czasowych lub finansowych coś zostało zrobione na skróty, ale zostało to zrobione świadomie. 

Bo myślę, że to też jest ciekawy aspekt tego Code Review, że jeśli znajdziemy coś, co nie jest zrobione kompletnie zgodnie ze sztuką, to pytanie, czy zostało to zrobione świadomie, czy przypadkowo. Jeśli było to zrobione świadomie, to może okej, ale jeśli to są błędy wynikające z przypadkowości i z tego, że ktoś czegoś nie wiedział albo o czymś zapomniał, to jest wtedy pewnie do poprawy.

Bo myślę, że to też jest ciekawy aspekt tego Code Review, że jeśli znajdziemy coś, co nie jest zrobione kompletnie zgodnie ze sztuką, to pytanie, czy zostało to zrobione świadomie, czy przypadkowo. Jeśli było to zrobione świadomie, to może okej, ale jeśli to są błędy wynikające z przypadkowości i z tego, że ktoś czegoś nie wiedział albo o czymś zapomniał, to jest wtedy pewnie do poprawy.

Myślę sobie, że takie Mob Review może być fajne w przypadku krytycznych albo bardzo istotnych zmian, bo to jednak jest jakiś koszt dla organizacji, więc trudno jest mi sobie wyobrazić, żeby każdy pull request był w ten sposób traktowany, ale tam, gdzie ma to sens, to jest to faktycznie fajne rozwiązanie.

Tak, np. teraz pracujemy nad silnikiem tego naszego rozwiązania, jakimiś 25:10 internalsami, gdzie każdy przepływ będzie korzystał z danego fragmentu, to myślę, że to są takie krytyczne miejsca, czy związane też np. z bezpieczeństwem, miejsca tego typu, to myślę, że tak. To, co próbuję powiedzieć, to że to są różne podejścia do robienia Code Review, taki pair programming czy taki Mob Review. I to wszystko to są narzędzia, które powinniśmy sobie wybrać, użyć, a nie korzystać z nich na ślepo w każdym przypadku.

Dokładnie. Myślę, że to, co teraz powiedziałeś, zbliża nas do podsumowania. Chciałbyś to ująć jakoś w kilku zdaniach, o czym dziś rozmawialiśmy?

Jasne. Pamiętajcie, że w IT zawsze to zależy. Dostosujcie te narzędzia do siebie, a nie siebie do narzędzi i pamiętajcie, jaki jest cel tego Code Review, czyli taka weryfikacja z lotu ptaka całego designu, sprawdzenie spójności tego projektu, sprawdzenie warstw abstrakcji, czy one się ze sobą nie mieszają. Starajcie się o jak najwięcej interakcji z autorem i uruchomcie ten kod, proszę.

Tak, to jest bardzo ważna rzecz, żeby jednak sprawdzić, czy coś działa, czy nie. Rozmawiamy tutaj o narzędziach programistycznych, Code Review jest jak najbardziej narzędziem, wykorzystujmy go tam, gdzie to ma sens, w sposób, który jest istotny. Wtedy wszystko skończy się dobrze.

Myślę, że może nie wyczerpaliśmy tematu Code Review, ale możemy uznać, że parę ciekawych spostrzeżeń w tej rozmowie się pojawiło.

Jak myślisz, Krzysztof, o czym będziemy rozmawiać następnym razem?

Kilka razy zahaczyliśmy o temat pair programmingu, myślę, że to też jest taka fajna metoda i narzędzie, które może być na różny sposób wykorzystane, więc co Ty na to, Łukasz, żebyśmy sobie w kolejnym naszym spotkaniu porozmawiali właśnie o tym?

Jasne. Rozwiniemy w takim razie ten temat i chciałbym też, żebyśmy myśleli o tym wszystkim jako o narzędziach.

I do tego odcinka oczywiście już z wyprzedzeniem zapraszamy, a tymczasem dzisiaj będziemy już kończyć.

Dzięki, Łukasz za spotkanie.

To jest pierwszy odcinek tej nowej serii, więc będziemy bardzo wdzięczni za wszelkie uwagi, komentarze i propozycje. Jestem ciekawy, jak odbierzecie ten odcinek i całą serię. Zapraszam do kontaktu. A osoby, które są zainteresowane zmianą pracy, zapraszamy na Solid.Jobs, gdzie możecie zawsze znaleźć ciekawe oferty pracy i to zawsze z widełkami wynagrodzeń. Tak że na dzisiaj i Wam, i Tobie, Łukasz, bardzo dziękuję.

Do usłyszenia! Cześć!

Dzięki, Krzysztof. Cześć!