To jest 227. odcinek podcastu Porozmawiajmy IT, w którym w cyklu rozmów z Łukaszem Drynkowskim z portalu z ogłoszeniami pracy IT SolidJobs, który zresztą mam przyjemność współtworzyć, dyskutujemy o software craftsmanship, czyli o rzemiośle programisty. 

Zapraszamy do słuchania i komentowania. A teraz życzymy Ci już miłego słuchania. 

Odpalamy! 

 

Cześć, Łukasz.

 

Cześć, Krzysztofie. 

 

Spotykamy się po raz kolejny, tym razem w nowej serii podcastów. Wszystkich tych, którzy nie mieli okazji zapoznać i przesłuchać wcześniejszych odcinków, wcześniejszej serii, którą z Łukaszem nagraliśmy na temat narzędzi programistów, to oczywiście do tej serii zapraszamy. Natomiast dzisiaj otwieramy nową serię, nieco można powiedzieć, rozszerzenie tych tematów, które były w tej pierwszej serii, bo będziemy mówić o software craftsmanship, czyli o rzemiośle programisty. Wszystko to, co się składa na bycie dobrym, profesjonalnym programistą. 

I myślę, że wielu z Was gdzieś to widzi na rynku, my też w SolidJobs, patrząc w nasze dane, widzimy bardzo jasno, że rynek ceni i poszukuje profesjonalistów, poszukuje osób z doświadczeniem, ale również takich, które właśnie w takim profesjonalnym podejściu do wytwarzania oprogramowania są w stanie działać. 

W tym odcinku, szczególnie w całej serii tych podcastów, będziemy mówić właśnie, co to znaczy być takim profesjonalnym programistą i na czym polega takie profesjonalne podejście do wytwarzania oprogramowania. 

Dzisiejszy odcinek tyczy się etosu programisty, więc tutaj nie będzie o jakimś szczególnym narzędziu, podejściu, metodyce. Chcemy tak ogólnie wprowadzić do tego właśnie tematu i dzisiaj będziemy opierać tę naszą dyskusję na dwóch dosyć istotnych książkach, których jeśli nie czytaliście, to z pewnością powinniście przynajmniej sobie zaplanować ich lekturę, mianowicie Clean Code i Clean Coder. 

Właśnie, Łukasz, ty na pewno przeczytałeś, powiedz, jaka jest różnica między nimi i co te dwie książki wnoszą do naszego tematu. 

 

Zacznę może od takiej anegdoty, że zaczynając tutaj swoją karierę programistyczną czy będąc jeszcze nawet na studiach, uważałem, że Clean Code to jest taka książka, która mi otworzyła oczy i książka, którą każdy powinien przeczytać. Jeśli przykładowo zatrudniam osobę do nas, do firmy, to oczekiwałbym, że zna na pamięć tego Clean Code’a. 

Natomiast przeczytałem sobie też tego Clean Codera, on jest taką broszurką, tam jest chyba z 200 stron, naprawdę jest dość krótka książka. I jak to przeczytałem, to stwierdziłem, no w sumie mech, to wszystko to są takie oczywistości, ogólniki. Im dłużej tutaj siedzę w naszej branży, im więcej doświadczenia zdobywam, to tym bardziej uważam, że jednak Clean Coder to jest ta książka, którą każdy powinien przeczytać. I jest tą ważniejszą książką z tych dwóch pozycji. Oczywiście zachęcam całym sercem, żeby zapoznać się z obiema pozycjami, natomiast Clean Coder to jest coś, co jednak zmienia tak fundamentalnie Twoje podejście do pracy, do tego, co robisz i po prostu pozwala stać się rzeczywiście lepszym rzemieślnikiem, lepszym profesjonalistą. 

 

Tak, dokładnie. Narzędzia są tylko narzędziami, natomiast bardzo ważne jest to, w jaki sposób się do nich podchodzi, jak się ich używa, w jaki sposób się odnosi do klienta, czy też użytkownika końcowego, bo to o tym też będziemy tutaj mówić, czyli cały ten proces wytwarzania, programowania, myślenia o różnych aspektach, tego software’u, który jest wytwarzany, jest istotny. 

Dlatego my też nie bez powodu zaczęliśmy od narzędzi programisty w poprzedniej serii, a teraz mówimy jak tych narzędzi używać, w jaki sposób podchodzić do całego procesu wytwarzania i oprogramowania i to wszystko składa się właśnie na taki etos programisty, który dumnie tą nazwą sobie odcinek nazwaliśmy, ale myślę, że nie ma w tym jakiejś tam szczególnej przesady i o takim etosie właśnie, o takim software craftsmanship możemy mówić. 

 

Tak, ja myślę, że właśnie Clean Code to była książka, która zmieniła to, jak piszę kod, jak piszę oprogramowanie. Natomiast Clean Coder to była książka, która zmieniła moje podejście do wytwarzania oprogramowania jako całego procesu. To jest po prostu nie do opisania słowami, myślę. Naprawdę zachęcam, jeśli nie czytaliście tej książki, do przeczytania jej ze zrozumieniem, a tutaj postaramy się takie najważniejsze punkty w tej rozmowie poruszyć, żebyście wiedzieli, z czym to się po prostu je. 

 

Dokładnie. Często stawia się znak równości pomiędzy właśnie takim podejściem software craftsmanship a profesjonalnym podejściem do wytwarzania oprogramowania. Ale słowo „profesjonalne” pewnie wymagałoby trochę uszczegółowienia. Czy według Ciebie profesjonalne podejście to jest takie podejście inżynieryjne, czy może to jest tylko rozszerzenie tego tematu? 

 

Myślę, że pierwszy stopień to podejście do tego, co robimy jako do inżynierii. I tutaj wiadomo, że nie możemy testować na produkcji, jeśli budujemy most, tak że tutaj wytwarzając oprogramowanie, mamy trochę większe marginesy błędów, natomiast kryzys oprogramowania trwa. To jest zdanie, które usłyszałem z 15 lat temu na studiach, na pierwszym roku i to było prawdziwe pewnie w latach 80., w latach 90. i jest prawdziwe teraz. Niestety, ale nie umiemy robić oprogramowania tak, żeby jednak było bez błędów i żeby było w jakiś sposób idealne. Albo jest to bardzo trudne, nawet rakiety kosmiczne lecą i wybuchają, i spadają. 

Tak że podejście inżynieryjne to jest jakby pierwszy ten krok. Natomiast drugi krok to jest podejście rzemieślnicze. I tutaj mam nadzieję, że zaraz postaramy się wyjaśnić różnicę. Czyli podejście inżynieryjne to skupienie się na tym, żeby ten proces był zawsze…

[…] nie możemy testować na produkcji, jeśli budujemy most, tak że tutaj wytwarzając oprogramowanie, mamy trochę większe marginesy błędów, natomiast kryzys oprogramowania trwa. To jest zdanie, które usłyszałem z 15 lat temu na studiach, na pierwszym roku i to było prawdziwe pewnie w latach 80., w latach 90. i jest prawdziwe teraz. Niestety, ale nie umiemy robić oprogramowania tak, żeby jednak było bez błędów i żeby było w jakiś sposób idealne. Albo jest to bardzo trudne, nawet rakiety kosmiczne lecą i wybuchają, i spadają.

 

Zgodny z zasadami albo zgodny z jakimiś wytycznymi branżowymi, żeby był doskonały technicznie. 

 

Tak, ja to nazywam tak potocznie „zgodne ze sztuką” i to jakby tutaj daje dużo, bo daje po prostu to, że trzymając się tych pewnych utartych sposobów wytwarzania oprogramowania, np. pisania tych przysłowiowych testów, to daje nam już takie out of the box jakieś korzyści. 

Natomiast teraz przechodząc dalej, to podejście rzemieślnicze to jest takie podejście, które się skupia już na tym produkcie bardziej, skupia się na funkcjonalności, skupia się na tym, żeby ten produkt nie był tylko sztuką, tylko żeby spełniał te wymagania odbiorców, żeby po prostu to był produkt, który jest jak najbardziej intuicyjny, jak najłatwiejszy w obsłudze i może nawet przekraczał oczekiwania. Czyli inaczej mówiąc, jest to myślenie produktowe w tym przypadku. 

 

Tak, wspomniałeś tutaj o kryzysie programowania. Pewnym powodem takiego kryzysu jesteśmy my, programiści, jakby nie było. I myślę, że branża też zauważa powoli, że  na rynku są potrzebni nie tylko software developerzy, czyli osoby, które wytwarzają kod, oczywiście według jakichś określonych standardów itd., ale myślę, że coraz bardziej upatruje się potrzeby zatrudniania i współpracowania z osobami, które są inżynierami w tym podejściu, którzy nie tylko skupiają się na danym witcherze, jego dowiezieniu jakiejś zgodności z najlepszymi praktykami, ale też w przełożeniu odbiciu tego, co zostało zaprogramowane na produkt jako taki, na inne jego fragmenty, na użytkowników korzystających. Czyli takie bardziej holistyczne podejście. 

Właśnie, według Ciebie powinniśmy mówić o software developerach, software inżynierach, szukać właśnie developerów czy też inżynierów, co preferujesz? 

 

To ja może jeszcze dorzucę tu trzeci klocek, czyli programista. I to mi się wydaje, że jest taki zawód na wymarciu. Nie wyłączajcie odbiorników, proszę. Wydaje mi się, że w przypadku programisty to jest najbardziej spłycone, czyli uważa się, że to ktoś, kto po prostu klepie ten kod, dostarcza tę sztukę. 

 

Czyli koder tak zwany.

 

Tak, a rynek idzie w tę stronę, że jednak są poszukiwani software developerzy, software inżynierzy (software engineer) i jakby ta nazwa stanowiska pokazuje, że oczekujemy od tych osób czegoś więcej niż tylko tego klepania kodów. 

Tu jeśli chodzi np. o software developer, czy zastanawialiśmy się, co to znaczy w ogóle dewelopować i czy to, co wytwarzamy, czy rzeczywiście dewelopujemy tę funkcję, to oprogramowanie, czy po prostu robimy tę sztukę, żeby działała. Wydaje mi się, że tu fajny jest przykład GameDevu, bo tam bardzo widać, że ten proces developmentu jest tak najbardziej rozwinięty, jednak jest tu dużo iteracji, czyli deweloperzy, tutaj używam tego słowa, Iterują, patrzą, co działa, co nie działa, robią też testy z użytkownikami, i rzeczywiście tam widać ten rozwój tej funkcji. 

Natomiast tutaj my szarzy deweloperzy tych aplikacji webowych czy desktopowych i tych smutnych excellowych okienek prezentujemy bardziej takie podejście utylitarne i chodzi o to, żeby coś spełniło swoją funkcję, żeby dało się tego pacjenta na tę wizytę umówić albo wypisać tę receptę. I już jest dużo mniejszy nacisk, nie ma nawet mowy o takim czynniku jak fun z używania tej aplikacji. Wiele jest takich czynników, jak łatwość obsługi, intuicyjność, czy po prostu, żeby rzeczywiście użytkowanie tego programu, mimo że to jest użytkowane w pracy, to żeby nie było przykrym obowiązkiem, a jednak rozmawiając z różnymi użytkownikami końcowymi różnych produktów, wiem, że często jest tak, że dlaczego musimy tutaj korzystać z tego programowania, jakbyśmy to zrobili łatwiej i szybciej ręcznie? I to jest niefajne. Myślę, że brakuje tego developmentu w tym procesie ogólnie wytwarzania oprogramowania w tej chwili. 

 

Jasne. Myślę, że to jest taki dobry moment, żeby porozmawiać właśnie, co się składa na ten etos programisty. Czym ten etos w ogóle jest? No bo jak myślimy o etosie, to przychodzi nam etos samuraja, etos jakiegoś rycerza średniowiecznego, czyli zestaw zasad, sposobów postępowania, tego, w jaki sposób taka osoba jest widziana na zewnątrz, w jaki sposób się prezentuje, wiele różnych składowych. 

Gdyby przełożyć to na wytwarzanie i oprogramowanie, to pewnie nie znajdziemy tam takich górnolotnych rzeczy, ale znajdziemy pewne sposoby postępowania, znajdziemy pewne taktyki, znajdziemy pewne drobne rzeczy, które stosowane codziennie, które stosowane przy prawie każdej linijce kodu sprawiają, że to, nad czym pracujemy, na koniec dnia nie tylko dowozi wartość, tak jak wspomniałeś, nie tylko jest kolejną zrealizowaną funkcjonalnością, ale będzie to feature, z którego przyjemnie się korzysta, który będzie po prostu wnosił wartość do całego produktu, a nie będzie tylko takim posklejanym na taśmę elementem. 

Więc co Ty na to, żebyśmy się przyjrzeli właśnie takim drobnym, małym rzeczom, może powszechnym, może nudnym, ale które na koniec dnia zebrane w całość właśnie tworzą ten etos programisty?

 

Jasne. Myślę, że zacząłbym właśnie od wspomnianego wcześniej nastawienia na produkt i na użytkownika. Myślę, że to jest taka różnica światopoglądowa, że nie skupiamy się na tym, żeby po prostu dowieźć tutaj funkcjonalność, która wykona tę utylitarną rzecz, to co tutaj ma być do zrobienia, tylko jednak żebyśmy się też szerzej zastanowili, jak to będzie użytkowane i po prostu znać taki szerszy kontekst, znać tego użytkownika, jego potrzeby. 

 

Przekładam to też na innych profesjonalistów, tak bym to szeroko dosyć nazwał, z innych branż. Tam nie tylko jest zrealizowana usługa, ale też jest podejście czy takie nastawienie na klienta. Miałem jakiś czas temu kontakt ze stolarzem, który wykonywał meble do mojego mieszkania. Więc nie tylko liczę na to, że te meble zostaną wykonane w sposób taki, że się po prostu nie rozlecą bardzo szybko, ale też, że ta osoba wypyta mnie, co jest dla mnie istotne, jak chciałbym, żeby to zostało zbudowane, jak będę to użytkował wreszcie, żeby to sprawowało swoją funkcję, tak? 

I tutaj myślę, że to jest też istotne w przypadku osób, które wytwarzają oprogramowanie, czyli nie tylko ten fragment kodu, klasa, funkcjonalność, ale też takie zastanowienie się, jak użytkownik będzie z tego korzystał, czy to, co tworzę, będzie stanowiło dla niego określoną wartość. 

I myślę, że trzeba sobie jasno powiedzieć, że te dwie rzeczy mogą iść w parze, bo nieraz spotykam się z takim zarzutem, że albo ktoś jest nastawiony na jakość wytwarzania programowania, na to, żeby to było zgodne, czy wykorzystywało jakieś najnowsze technologie i skupia się tylko na tym technicznym aspekcie właśnie software’u, albo ktoś bardziej jest nastawiony na to podejście, czy taką perspektywę użytkownika i wówczas nie do końca się przejmuje tym, jak pod spodem zostało to zrealizowane. Według mnie te dwie rzeczy jak najbardziej mogą iść w parze. 

 

Tak, jeśli chodzi tutaj o ten cały ruch software craftmanship, to oni tutaj wzięli manifest Agile i go rozszerzyli, zmienili na swoje potrzeby. I właśnie tutaj to, o czym teraz powiedziałeś, jest zawarte w pierwszej regule: not only working software, but also well-crafted software. 

 

I ten profesjonalnie zrealizowany software, tak byśmy go nazwali, czy nie tylko software – nawet wychodząc poza naszą branżę – jeśli myślimy, że coś jest zrealizowane właśnie w sposób profesjonalny, to pierwsze, co nam przychodzi na myśl, mam wrażenie, to jest dobra jakość. Profesjonalnie zrealizowana usługa to jest usługa z dobrą jakością. Profesjonalnie zrealizowany produkt to jest dobry jakościowo produkt. 

Właśnie, czy według Ciebie jakość jest istotna w tym etosie programisty, jaką rolę sprawuje i jak podejść do jakości, jeśli chcemy być właśnie tym profesjonalnym programistą?

 

 I ten profesjonalnie zrealizowany software, tak byśmy go nazwali, czy nie tylko software – nawet wychodząc poza naszą branżę – jeśli myślimy, że coś jest zrealizowane właśnie w sposób profesjonalny, to pierwsze, co nam przychodzi na myśl, mam wrażenie, to jest dobra jakość. Profesjonalnie zrealizowana usługa to jest usługa z dobrą jakością. Profesjonalnie zrealizowany produkt to jest dobry jakościowo produkt.

 

Tak, jakość jest tutaj kluczowym czynnikiem i mówimy tutaj zarówno o jakości produktu, jak i o jakości tego całego procesu wytwórczego. Czyli przykładowo takie podejście profesjonalne to jest takie, w którym rzeczywiście te testy, czy to jednostkowe, czy jakiegoś innego rzędu powstają. Oczywiście są różne projekty, różnie to bywa. Dostosujmy po prostu to podejście do testów, też oczywiście do swojego projektu, bo czasami rzeczywiście takie testy akceptacyjne w Selenium sprawdzają się lepiej niż pisanie testów integracyjnych i jednostkowych, a czasami można to wszystko połączyć ze sobą – to tutaj wszystko oczywiście zależy. Ale trzeba mieć tę strategię automatycznych testów i trzeba to rzeczywiście robić, a nie tylko polegać na testach manualnych, gdzie wiadomo, że nie jesteśmy w stanie tego powtórzyć przy każdej zmianie. 

Rozszerzając to na kod, to też jakość kodu. Nie może być zgody po prostu zespole na to, żeby były klasy liczące sobie po kilka tysięcy linii kodu. Nikt tego nie ogarnie, nikt tego nie zrozumie. Wprowadzenie jakiejkolwiek zmiany to dramat. Nie może być zgody na to, żeby ten kod się powielał wielokrotnie, chcemy wprowadzić jedną zmianę i musimy to samo zmieniać w 10, 20, 100 miejscach – to tak nie może wyglądać, bo po prostu ta słaba jakość wewnętrzna rzutuje na tę jakość potem produktu, choćby w tym, że będzie nam dłużej zajmować właśnie jakieś bugfixowanie. 

 

Dorzuciłbym do tego też słynną zasadę skauta, czyli że jeśli trafiamy na jakiś fragment kodu, który nie spełnia oczekiwań, to po prostu zostawiamy go lepszym i to też dobrze się aplikuje do tego podejścia, o którym rozmawiamy, że nie tylko reagujemy na zmiany, reagujemy na to, co nam klient mówi, jakie zmiany rynek wymusza, ale też dodajemy cały czas jakąś wartość do tego software’u, nad którym pracujemy. 

Myślę, że bardzo ważne jest to, co powiedziałeś, że to profesjonalne podejście w wytwarzaniu oprogramowania to jest nie tylko dobrze skrojony kod, to jest nie tylko ten clean code, o którym na początku wspomnieliśmy, ale to też jest odpowiednie podejście do tych procesów, że różne rzeczy, które się w zespole, w firmie źle dzieją, niezgodnie z tym, pewnie będą miały swoje przełożenie też na wytwarzanie oprogramowania. 

I właśnie takie rzeczy, o które też warto pewnie mówić, to jest podejście do rekrutacji, podejście do onboardingu, podejście do offboardingu całego zespołu i pojedynczych osób. Myślę, że to też świadczy o tym, jakimi programistami, jakimi deweloperami, jakimi inżynierami jesteśmy, i też powoduje, że inni naśladują, wsiąkają w tę kulturę organizacyjną  i po prostu ma szansę wówczas wytworzyć się taka kultura dbania o pewne rzeczy, zwracania uwagi na pewne rzeczy, tak że nie pozwalamy sobie na tę byle jakość, o której tutaj powiedziałeś.

 

Musimy sobie także zdać sprawę z tego, że za jakość odpowiada cały zespół, a nie ten przysłowiowy tester czy QA. Nie jest tak, że za błędy w tym, co ja zrobię i co pójdzie na produkcję, odpowiada tester, który nie znalazł tych błędów. No nie… Musimy brać odpowiedzialność za to, co robimy, i też niech pierwszy rzuci kamieniem ten, kto nigdy nie puszczał kodu bez jego odpalenia po jakichś zmianach, ale nie powinniśmy tak robić. Naprawdę jeśli coś zmieniamy, to musimy to zbuildować, sami przetestować, wrzucić. 

Tak samo to mówiliśmy też przy code review. Jeśli wystawiam pull request, no to nie czekam, aż ktoś znajdzie oczywiste tutaj literówki, tylko pierwsze co, no to sam ten pull request przeglądam, pierwszą paczkę poprawek pushuję, no i dopiero wtedy zapraszam kolegów i koleżanki do współpracy przy tym code review. 

Musimy sobie także zdać sprawę z tego, że za jakość odpowiada cały zespół, a nie ten przysłowiowy tester czy QA. Nie jest tak, że za błędy w tym, co ja zrobię i co pójdzie na produkcję, odpowiada tester, który nie znalazł tych błędów. No nie… Musimy brać odpowiedzialność za to, co robimy, i też niech pierwszy rzuci kamieniem ten, kto nigdy nie puszczał kodu bez jego odpalenia po jakichś zmianach, ale nie powinniśmy tak robić.

 

Często dzisiaj wybiegam poza tę naszą bańkę programistyczną, natomiast myślę, że warto też podpatrywać, jak etos jest realizowany w innych grupach zawodowych, czy też społecznych. I tak przyszło mi na myśl, że jeśli pomyślimy sobie o takim etosie angielskiego gentlemana, to tam oprócz tego, jak taka osoba wygląda, jak się zachowuje, jest też to, w jaki sposób uczestniczy w społeczności innych osób. 

I myślę, że można to też przełożyć właśnie na etos programisty, gdzie nie tylko liczy się nasza indywidualna kontrybucja do wytwarzanego software’u, ale liczy się też to, w jaki sposób przeprowadzamy interakcje z innymi programistami, w jaki sposób tworzymy społeczność, w jaki sposób wzajemnie się wspieramy, pomagamy itd. To wszystko też buduje etos programisty. 

 

Tak, ale tutaj nie jesteśmy też w tym wszystkim sami. Myślę, że też ważne jest to, żeby organizacja nas wspierała, czyli nasza firma, mówiąc tutaj wprost, w tym, żeby rzeczywiście wytwarzać to oprogramowanie w sposób profesjonalny i jakościowy. 

Jak myślisz tutaj, Krzysztofie, jak taka organizacja może tutaj nas w tym wspomóc? 

 

Tak, zdecydowanie. Myślę, że mówimy tutaj o kulturze organizacyjnej i faktycznie, jak w tym przysłowiu, ona zjada wszystko inne na śniadanie. I nawet jeśli my jako indywidualny programista czy programistka w tym zespole mamy dobre chęci, wiedzę i umiejętności, jak ten etos rozwijać, to jeśli cała organizacja nie będzie wspierała tego, to po prostu to się na koniec dnia rozsypie i jedna osoba zazwyczaj tej rewolucji nie wprowadzi.

Więc bardzo ważne jest to, żeby tę kulturę organizacyjną, która wpasowuje się w etos programisty, kreować. A to kreowanie bardzo często zwłaszcza w przypadku takich początkowych, mniejszych, rozwijających się firm, idzie z góry. Więc nie bez znaczenia jest rola jakiegoś senior dewelopera, team lidera, architekta, osoby, która ma jakieś poważanie, na którą się po prostu patrzy, której zachowania się naśladuje.

Na to bym tutaj zwrócił zdecydowanie uwagę, że jeśli chcecie widzieć pewną zmianę, chcecie widzieć określone zachowania, to sami musicie takie zachowania pokazywać, sami musicie postępować według tych zasad.

 

Tak, ryba się psuje od głowy, jak wiadomo. Nie może być tak, że przyjdzie lider i powie, że teraz czas wzorców się skończył, a musimy tutaj dowieźć coś na jutro. Jeśli tak firma działa, to daleko nie zajedzie.

 

Myślę, że duże znaczenie ma też to, czy mamy przestrzeń i czas na realizację tych wszystkich rzeczy związanych z opiekowaniem się kodem, z pomocą innym w zespole. I jeśli w organizacji nie ma na to przyzwolenia albo nie widzi się w tym żadnej wartości, to po prostu to też na koniec dnia się przełoży na jakość wynikową, na jakość naszej pracy.

Myślę tu o przewidzeniu, zaplanowaniu czasu na refaktoryzację. Jeśli dana osoba ma zaplanowane pod kokardę, że tak powiem, że będzie realizowała nowe funkcjonalności i tylko nowe funkcjonalności, nigdy nie będzie tego czasu na refaktoryzację, nie będzie przyzwolenia wręcz, żeby taki czas znaleźć, no to oczywiście będziemy obserwować taki powolny rozkład – nie tylko software’u, ale też całego zespołu, który po prostu nie będzie dążył do tego, żeby ta jakość była lepsza, żeby realizować te wszystkie założenia, o których powiedzieliśmy, tylko będzie miał za główny cel dowożenie jak najszybciej nowej funkcjonalności.

Więc właśnie, refaktoryzacja idzie też w parze z pisaniem kodu, który jest utrzymywany na dłuższą metę. Każdy, kto miał okazję pracować w jakimś projekcie kilka lat, docenia na pewno to, że pierwotne dobre założenia i takie pisanie kodu utrzymywalnego na koniec dnia wpływa na to, że mamy mniej problemów, że pewne zmiany są łatwiejsze, że nie musimy po nocach się budzić, naprawiać jakiejś funkcjonalności, bo ten kod nie jest utrzymywalny.

Wreszcie to się przekłada też na sam biznes, na sam produkt, który widzi, że wprowadzenie nowych rzeczy, nowych jakichś zmian jest łatwiejsze, szybsze niż gdy ten kod jest takim spaghetti kodem.

 

Tak, jeszcze jedną tutaj rzecz chciałbym dodać, czyli unikanie buzzwordów i dobrych praktyk. Dobrze słyszycie. Zasady są po to, żeby je łamać, ale oczywiście tylko pod warunkiem, że robimy to świadomie, wiemy, dlaczego to jest okej i dlaczego w danym przypadku daną zasadę chcemy złamać. I tutaj nie trzymajmy się dogmatycznie pewnych reguł, pewnych sformułowań. Czasami po prostu specyfika projektu jest taka albo w danej chwili, że rzeczywiście trzeba zrobić coś trochę inaczej niż zgodnie ze sztuką.

Tutaj dobrym przykładem jest reguła YAGNI. I taki przykład życia wzięty. Robię sobie code review, znajduję jakieś elementy, które po prostu wiem, że w niedługiej przyszłości na pewno będą tutaj musiały zostać zrobione inaczej, więc dodaję komentarz: proszę, tutaj dodaj dodatkową warstwę abstrakcji, opakuj w jakąś klasę, a dostaję informację, że na razie to nie jest potrzebne i zostawmy to na później.

A to później szybko przychodzi i się okazuje, że jednak gdybyśmy to zrobili od razu dobrze, to byłoby łatwiej. Wtedy to było, powiedzmy, małym kosztem, a teraz jak ten fragment kodu jest używany w iluś miejscach, to ta zmiana jest trochę trudniejsza, więc nie zawsze trzymajmy się dogmatycznie tych reguł i zasad, bo czasami po prostu trzeba użyć zdrowego rozsądku.

 

Tak, każdy profesjonalista prędzej czy później musi zrobić coś niezgodnie może z regułą sztuki, tylko dlatego, żeby dowieźć, można powiedzieć. Właśnie, to wsparcie organizacji jest mega istotne po to, żeby był czas na odpowiednią jakość, na refaktoryzację, po to, żeby programiści mogli się wymieniać wiedzą, po to, żeby był czas na przeanalizowanie, jak to, co się robi, wpływa na użytkownika końcowego.

 

Tak, ale też musi być czas na edukację, na to, żeby ludzie mogli po prostu chwilę odsapnąć, czy to na koniec sprintu, czy pomiędzy sprintami i żeby był taki czas, gdzie możemy czegoś nowego się nauczyć.

 

Jakiejś nowe praktyki, jakiegoś nowego podejścia, jakiegoś nowego frameworku, wszystkiego tego, co sprawia, że po prostu ten nasz warsztat staje się coraz lepszy. To jest według mnie istotne, co powiedziałeś, że nie tylko wsparcie organizacji jest potrzebne, ale może przede wszystkim jest potrzebny nasz indywidualny rozwój. Cały czas musimy sobie tę naszą przysłowiową piłę ostrzyć, żeby ten nasz warsztat przynajmniej nie rdzewiał.

Właśnie, ten czas potrzebny na rozwój z jednej strony może być w jakiś sposób zapewniony przez pracodawcę, ale nie możemy zwalić tutaj całego samorozwoju na pracodawcę.

 

Tak, bo to przecież nie firma jest odpowiedzialna za Twój rozwój, tylko jednak Ty sam. Firma może to wspierać i bardzo fajnie, jeśli funduje Ci np. licencję Pluralsight albo zapłaci za udział w konferencji,  to ja nie mówię, żeby codziennie robić jakieś researche, projekty na boku i nie wiadomo co, ale ten czas raz w tygodniu, dwa, trzy razy w miesiącu znaleźć na to, żeby po prostu czegoś nowego się dowiedzieć i nie stać w miejscu.

 

To jeszcze raz przywołam to, o czym mówiłem, że nieraz bardzo się przydaje i bardzo wiele może nas nauczyć, jeśli jesteśmy w danym projekcie trochę dłużej niż pół roku i widzimy konsekwencje decyzji, podejść, technik, które wykorzystaliśmy, jak to wpływa na utrzymywalność, na różne błędy, na to, w jaki sposób dalej jest możliwe rozwijanie software’u, jak to wpływa na użytkowników, jeśli pojawia się większa skala, że teoria teoriom czy rozpoznanie nowych narzędzi to jedno, ale takie profesjonalne podejście to jest też uczenie się na przykładzie tego, co samemu się zrobiło, jak to się sprawdza, czy tutaj możemy jakieś wnioski z tego wysunąć.

 

Tak, ale też profesjonalnym podejściem jest dzielenie się swoją wiedzą, a nie np. podejście zatrzymam to dla siebie, jak będą chcieli to zmienić, to będą się musieli do mnie odezwać, tylko po prostu, żeby była możliwość taka, żeby jednak dowolny członek zespołu mógł tutaj z danym tematem się zająć. I to też jest korzyścią dla wszystkich, bo jeśli ja jako nawet taki regular mam tutaj gdzieś w zespole juniora, któremu mogę coś wytłumaczyć, to sam też tłumacząc, zaczynam tę rzecz rozumieć lepiej. Działa to w dwie strony, nie jest to też tak jednostronnym działaniem, więc warto.

 

Czyli mamy wsparcie organizacji, mamy nastawienie na nasz rozwój, na który musimy znaleźć czas, tutaj o kilku różnych technikach, podejściach powiedzieliśmy. Myślę, że to jest dobry moment, żeby spróbować podsumować to, o czym mówiliśmy do tej pory.

 

Dobrze, w takim razie pozwolę sobie tutaj na krótkie podsumowanie tego, o czym dzisiaj rozmawialiśmy. Tak że może zacznę od tego, żebyście wykorzystywali narzędzia dostępne Wam. Zachęcamy tutaj do odsłuchania poprzedniego cyklu naszego podcastu, gdzie właśnie o tych narzędziach mówiliśmy i Wam trochę przybliżyliśmy pewne techniki.

Na pewno używając takich ogólnie przyjętych praktyk i technik, jesteście do przodu, bo macie out of the box pewne rzeczy już zapewnione, nie musicie o pewnych rzeczach myśleć. Podchodźmy do tego wytwarzania oprogramowania profesjonalnie z naciskiem na produkt, z naciskiem też na jakość samego procesu, a nie na dostarczenie tylko sztuki. To jest może ważne też, że róbmy ten produkt, z taką myślą, jakbyśmy mieli go utrzymywać przez najbliższe 20 lat, a nie z myślą, że za rok to mnie już tu nie będzie i to będzie problem kogoś innego. To jest właśnie to myślenie, które nie cechuje się tutaj profesjonalizmem, tylko właśnie też nie rozwija nas w żaden sposób, bo jeśli robimy coś na odwal się, może utkniemy z tym czymś. Musimy tutaj myśleć o innych, myśleć o testerach, myśleć o użytkownikach, o całym zespole.

Co tu jeszcze możemy podsumować? Jakość wewnętrzna kodu i tego procesu na pewno wpływa na jakość zewnętrzną. Nie wiem, czy wpływa pozytywnie, ale na pewno jeśli jest słaba jakość, to wpływa negatywnie – i to jest to, na co warto zwrócić uwagę. Objawia się to np. w czasie potrzebnym na bugfixy, czy na wprowadzenie kolejnych zmian, czy po prostu objawia się w braku awaryjności tej aplikacji i łatwości jej obsługi.

I ostatni punkt podsumowania, czyli pamiętaj, ciągle się rozwijaj, to Ty jesteś odpowiedzialny za swój rozwój. Zadbaj też o to, żeby firma wspierała ten rozwój zarówno Twój, jak i Twoich kolegów, ale oczywiście nie zapomnij o tym, że warto np. czytać książki.

Tak że Krzysztofie, powiedz mi, o czym będziemy rozmawiać w kolejnym odcinku.

 

Dzisiaj zrobiliśmy, myślę, bardzo fajne wprowadzenie do etosu programisty. Kolejne odcinki będą tyczyły się już poszczególnych technik, podejść związanych z tym, jak faktycznie stawać się lepszym programistą, jak zadbać o nasz warsztat. I myślę, że taką pierwszą rzeczą, o której będziemy chcieli powiedzieć, jest nos programisty, który powinien być wyczulony na brzydkie zapachy w kodzie, czyli Code Smells. Przyjrzymy się temu, co może nam dawać znaki, jakieś pierwsze objawy w kodzie, że niekoniecznie idziemy w dobrym kierunku i powinniśmy skorygować nasz kurs. Tak że Code Smells będzie tematem kolejnego odcinka.

Dobrze, Łukasz, myślę, że na dzisiaj, jeśli chodzi o to wprowadzenie, to chyba tyle. Bardzo Ci dziękuję za spotkanie, za tę rozmowę.

Zapraszamy oczywiście wszystkich do zapoznania się z naszą wcześniejszą serią podcastów o narzędziach programisty. To jest dobre wprowadzenie do tego, o czym będziemy w tej serii rozmawiać. Zapraszamy do podzielenia się informacją o tym odcinku w Waszych kręgach. Zapraszamy też wreszcie do odwiedzenia SolidJobs, jeśli szukacie dla siebie nowej pracy. Tam znajdziecie wiele ciekawych ofert, zawsze z widełkami wynagrodzeń. Zapraszamy też do dodawania tam ogłoszeń i na dzisiaj dziękujemy bardzo za uwagę. Słyszymy się już niedługo.

 

Dzięki za rozmowę. Do usłyszenia.