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

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

Odpalamy!

 

Cześć, Łukasz!

 

Cześć, Krzysztof!

 

Spotykamy się już po raz siódmy, żeby porozmawiać o narzędziach programisty. Dzisiaj, zgodnie z zapowiedzią z wcześniejszego odcinka, będziemy mówić o Dziel i zwyciężaj – o tej regule, podejściu, które sprawdza się nie tylko w zastosowaniach historycznych, ponieważ właśnie można powiedzieć, że tu należy upatrywać korzeni Dziel i zwyciężaj.

Już w czasach rzymskich ta reguła była znana. Polegała na podziale czegoś większego na mniejsze, żeby łatwiej i lepiej zarządzać. O tym, czy nadal się to sprawdza, jeszcze pewnie dzisiaj porozmawiamy, natomiast w podejściu programistycznym, bo skupiamy się narzędziach programisty, jest to po prostu takie rekurencyjne podejście rozłożenia problemu większego na mniejszy, realizowany sposób powtarzalny, aż dojdziemy do zupełnie banalnego zadania do rozwiązania, a rozwiązania tych banalnych problemów służą nam się na rozwiązania tego większego.

 

Oczywiście nie będziemy rozmawiać o algorytmach sortowania przez scalanie czy quicksorcie, chociaż oczywiście to są standardowe przykłady podejścia Dziel i zwyciężaj. Może zrobię tylko jeden wyjątek dla algorytmu wyszukiwania binarnego, ponieważ w mojej opinii to nie jest przykład wykorzystania podejścia Dziel i zwyciężaj, tylko to jest właśnie konkretna implementacja tego podejścia, taka uporządkowana, która polega na czymś konkretnym. A my będziemy tutaj rozmawiać o takich nietypowych i trochę może niestandardowych zastosowaniach tego podejścia.

Może zaczniemy od tego, że jest to podejście, które jest stosowane także w zarządzaniu, np. przy estymacjach zadań, o czym już wspominaliśmy ostatnio. Możemy dzielić zadania na mniejsze, dzięki czemu estymacja tych zadań jest dużo prostsza.

Natomiast w przypadku wykorzystania tego podejścia do zarządzania zasobami ludzkimi jest to oczywiście antypattern i jest to podejście, które jest szeroko krytykowane.

 

Właśnie, jeśli chodzi o algorytmiczne czy programistyczne zastosowania, to myślę, że sprawdzi się dosyć dobrze, bo komputery zazwyczaj dosyć sprawnie realizują to, co byśmy chcieli, żeby realizowały. Natomiast ludzie są na tyle nieprzewidywalni, że taka relatywnie prosta polityka Dziel i zwyciężaj niestety nie sprawdzi się zbyt dobrze.

Skupmy się może na tej prostszej wersji, czyli jak zastosować Dziel i zwyciężaj do naszego programistycznego rzemiosła. Pierwsza, najbardziej oczywista rzecz, którą znajdziecie pewnie googlując tę zasadę, to są algorytmy, tak jak Łukasz powiedział, nie będziemy zbyt mocno wchodzić w ten obszar, i oczywiście quicksort, wyszukiwanie binarne i pewnie wiele innych rzeczy tutaj się dobrze odnajdzie.

 

Tak, ale także możemy wykorzystywać to podejście po prostu, pisząc kod, refaktoryzując, dzieląc klasy na mniejsze, dzieląc zadania, user stories na mniejsze. Ogólnie myślę, że mniejsze jest takie bardziej ogarnialne. Tak jak nazwa wskazuje: dzielcie rzeczy duże i zwyciężajcie, dochodźcie do celu.

Tak, ale także możemy wykorzystywać to podejście po prostu, pisząc kod, refaktoryzując, dzieląc klasy na mniejsze, dzieląc zadania, user stories na mniejsze. Ogólnie myślę, że mniejsze jest takie bardziej ogarnialne. Tak jak nazwa wskazuje: dzielcie rzeczy duże i zwyciężajcie, dochodźcie do celu.

 

Tak, tak. Pisanie kodu, ale też pisanie testu, czy w ogóle testowanie, to też są dosyć dobre obszary, gdzie Dziel i zwyciężaj się sprawdzi. Jeśli nie wiemy, co może być źródłem błędu, źródłem problemu, to przez takie przecinanie na pół tego pozostałego obszaru jesteśmy w stanie w jakiś sposób znaleźć źródło, czy miejsce błędu.

 

Tak, i warto powiedzieć, że takie przecięcia mogą być zarówno, nazwijmy to, na potrzeby tej rozmowy, wertykalne i horyzontalne. Możemy sobie podzielić większe zadanie. Posłużę się przykładem teraz z poprzedniego odcinka: mamy jakiegoś CRUD-a, gdzie jest wyszukiwanie, wyświetlanie tych wyników, możemy więc to wyświetlanie podzielić jako jedną funkcję wyszukiwania i jako drugą, czyli podzielić funkcjonalnie. Możemy też to podzielić na front-end, back-end czy na warstwy. Tutaj możemy np. zająć się warstwą infrastruktury osobno, warstwą prezentacji osobno. Tych płaszczyzn podziału jest dużo, a sam podział nam daje dużo dobra, można się podzielić tą pracą.

Mały fragment jest też dla nas bardziej zrozumiały i mniejszy jest próg wejścia w takie zadanie. Łatwiej jest zacząć coś robić, jeśli mamy przed sobą małe zadania. Tak że nie zawsze musimy od razu cały feature programować, może jesteśmy w stanie z tego wydzielić coś mniejszego, np. patrząc bardziej z lotu ptaka, MVP.

To, co próbuję powiedzieć: dzielmy, dzielmy, dzielmy. Tak jak też wspominałem w odcinku o pull requestach – im mniejszy pull request, tym więcej komentarzy, im większy, tym mniej komentarzy. Tak że jest na pewno bardziej strawny taki mniejszy fragment, bardziej do ogarnięcia, jest bardziej zrozumiały też dla innych osób, które z nami współpracują. To jest nie tylko zaleta dla nas.

 

Myślę, że to jest istotne, bo wbrew pozorom chcemy mieć więcej tych komentarzy w pull requeście, a nie mniej, więc jeśli damy taką możliwość oceniającemu, czy też przeglądającemu ten kod, żeby mógł się zmierzyć z mniejszym pull requestem, to zdecydowanie przychylniej na to spojrzy, znajdzie czas, pewnie też łatwiej będzie nam uzyskać jakikolwiek feedback.

 

Tak, kolejnym przykładem takiego zastosowania Dziel i zwyciężaj jest wspomniany wcześniej algorytm wyszukiwania binarnego, czyli dzielimy problem na pół i szukamy czegoś w lewej części, w prawej części. Jeśli nie znaleźliśmy, dalej dzielimy tę połówkę, aż znajdziemy to, czego szukamy. Lub nie znajdziemy – wtedy się wracamy. Takie podejście ma zastosowanie np. przy testowaniu lub debugowaniu problemu. To jest wtedy takie bardziej podejście uporządkowane. Może nazwę to w stosunku do takiego dowolnego tradycyjnego algorytmu Dziel i zwyciężaj, gdzie dzielimy np. na chybił trafił, co jak wiadomo z algorytmu quicksort ma swoje…

Tak, kolejnym przykładem takiego zastosowania Dziel i zwyciężaj jest wspomniany wcześniej algorytm wyszukiwania binarnego, czyli dzielimy problem na pół i szukamy czegoś w lewej części, w prawej części. Jeśli nie znaleźliśmy, dalej dzielimy tę połówkę, aż znajdziemy to, czego szukamy. Lub nie znajdziemy – wtedy się wracamy. Takie podejście ma zastosowanie np. przy testowaniu lub debugowaniu problemu. To jest wtedy takie bardziej podejście uporządkowane.

 

Minusy.

Chciałem powiedzieć zalety właśnie. Jeśli dane są uporządkowane w jakiś szczególny sposób, to randomizacja nam może pomóc w stosunku do tego uporządkowanego podejścia. Np. ja sobie tutaj potrafię wyobrazić, szukam tego błędu i próbuję wykomentować wszystko, co jest niepotrzebne i potem odkomentowuję fragmenty kodu. Gorzej jeśli są dwa błędy i rozwiążemy częściowo problem. Albo tylko ten błąd się nam pojawi, jeśli jest więcej części, też tak mi się zdarzało.

 

Bywa.

 

Bywa, tak. Ale myślę, że Dziel i zwyciężaj dotyczy nie tylko programowania, także testowania, także tego etapu pierwszego właśnie, czyli etapu tworzenia user stories, podział na mniejsze. To jest narzędzie uniwersalne.

 

Tak, na pewno jest uniwersalne, można zastosować w wielu obszarach, ale myślę, że warto byłoby powiedzieć, po co mielibyśmy to narzędzie stosować. Taką bardzo oczywistą rzeczą, która tutaj już gdzieś między wierszami padła, to jest właśnie podział na łatwiejsze do opanowania zadania i ułatwienie zarządzania nimi.

Łatwiej nawet psychologicznie, tak jak wspomniałeś, Łukasz, zmierzyć nam się z czymś łatwiejszym. Nie bez powodu mówi się, że słonia je się łyżeczką, powoli. I ten podział na mniejsze zadania właśnie umożliwia nam to, że będziemy czuli większą motywację do tego, żeby to zadanie całe wykonać.

Motywacja działa też w ten sposób, że jeśli mamy już odnotowany jakiś sukces na swoim koncie, czyli udało nam się jakąś mniejszą część tego zadania wykonać, będziemy bardziej chętni do tego, żeby kontynuować.

 

Tak i tutaj idealnie właśnie z tym się wiąże filozofia Kaizen – tych małych kroczków i tego właśnie, żeby ten próg wejścia do zadania był jak najmniejszy i żebyśmy mieli szybki feedback, o którym wspomniałeś. Pozytywny feedback.

 

À propos szybkości, oczywiście możemy sobie podkręcać taktowanie procesora i w ten sposób próbować realizować obliczenia szybciej, ale też całkiem skuteczną techniką jest zrównoleglenie prac. I taki podział właśnie na dobrze zdefiniowane, mniejsze zadania umożliwia zrównoleglenie wykonywanej pracy nad takim większym zadaniem. Możemy wręcz kilku programistom te zadania zlecić, później połączyć w całość i w ten sposób zarządzić wykonaniem całego zadania.

 

Czyli takie programowanie przez merge sort.

 

Tak, oczywiście to jest jakaś idealna sytuacja, zakładając, że te wszystkie kawałki da się ładnie ze sobą scalić i za sobą działają. Nie zawsze tak oczywiście jest, ale w teorii powinna działać.

 

Tak, ale pamiętajmy, że też tu jest jakaś granica, bo im bardziej dzielimy, to tym więcej tutaj mamy tego czasu traconego na narzut, że się tak wyrażę. Choćby na zmianę kontekstu. Tak samo, jakbyśmy sprint mieli dwutygodniowy czy jakbyśmy robili codziennie nowy sprint – gdzie wtedy zmieścić te wszystkie spotkania? Jest gdzieś pewna granica i nie przesadzajmy też w drugą stronę.

 

Myślę sobie, że jeśli Ty jako programista dzielisz i zwyciężasz swoją pracę, to jest taki prostszy wariant, ale w sytuacji, kiedy pracujesz w zespole i to członkowie zespołu są odbiorcą tych podzielonych zadań, to jest potrzebna jakaś tam praca na scalenie tego, co ten zespół wyprodukuje. To jest jedno, a dwa, to takie przygotowanie tej pracy, czyli takie zdefiniowanie tych zadań, często przez PM-a, żeby tę pracę później można było po prostu scalić. Więc to też wymaga zdefiniowania tych wszystkich wymagań, zadań i odpowiedniej wiedzy PM-a.

 

Tak, ja się też spotkałem kilkukrotnie z taką sytuacją, że były te zadania w sprincie podzielone, ale i tak brałem dwa albo trzy na raz, bo i tak tę pracę trzeba było wykonać równolegle, nie było sensu tego robić po kolei. To i tak była ta sama praca, tylko np. trzy razy do zrobienia, to szybciej było to zrobić za jednym zamachem.

Natomiast Dziel i zwyciężaj to jest takie narzędzie, które możemy stosować nie tylko do programowania, czy też do zarządzania projektami informatycznymi. Możemy też często w codziennym życiu zastosować taką metodę. I tutaj jest taka książka, którą chciałbym polecić: Algorytmy. Kiedy mniej myśleć. I cała idea tej książki polega na tym, żeby w codziennym życiu stosować różne algorytmy, które znamy z programowania i się po prostu nie zastanawiać, bo czasami łatwiej jest coś wykonać tym algorytmem i efekt jest albo porównywalny, albo nawet lepszy niż ta metoda nazwijmy to zachłanna, którą stosujemy w codziennym życiu. Tak że książka autorstwa dwóch panów: Toma Griffithsa i Briana Christiana.

 

Podlinkujemy albo wrzucimy w opisie do odcinka. Dzięki za tą polecajkę.

Na początku powiedziałem, że Dziel i zwyciężaj to jest takie rekurencyjne podejście, gdzie stopniowo dzielimy sobie na kolejne kroki. Myślę, że to jest warte zaznaczenia: że nie chodzi nam o to, żebyśmy na samym początku, przed przystąpieniem do pracy, już podzielili sobie to nasze zadanie na setkę mniejszych zadań, bo często też nie mamy nawet odpowiedniej wiedzy wówczas, żeby takiego podziału dokonać. Zresztą ten narzut czasu potrzebny na taki podział mógłby być całkiem duży. Warto tutaj stosować jeszcze metodę takich małych kroczków i na początku podzielić sobie na pół to zadanie, później z tej połowy na kolejne pół czy jakkolwiek i w ten sposób taki rekurencyjny właśnie ten problem sobie kolejno dzielić.

Więc najtrudniejszy jest ten pierwszy krok, nie ma sensu zbyt długo o tym myśleć, po prostu wystarczy dokonać pierwszego podziału i później iść z procesem.

Dziel i zwyciężaj – metoda, podejście, które może się sprawdzić nie tylko w programowaniu, ale również w codziennym życiu, tak jak Łukasz wspomniał. Łukasz, chciałbyś podsumować to, o czym do tej pory powiedzieliśmy?

Na początku powiedziałem, że Dziel i zwyciężaj to jest takie rekurencyjne podejście, gdzie stopniowo dzielimy sobie na kolejne kroki. Myślę, że to jest warte zaznaczenia: że nie chodzi nam o to, żebyśmy na samym początku, przed przystąpieniem do pracy, już podzielili sobie to nasze zadanie na setkę mniejszych zadań, bo często też nie mamy nawet odpowiedniej wiedzy wówczas, żeby takiego podziału dokonać. Zresztą ten narzut czasu potrzebny na taki podział mógłby być całkiem duży.

 

Myślę, że takie inne spojrzenie może na to Dziel i zwyciężaj, to jest to, że po prostu jest mniejszy próg wejścia wtedy w te zadania, jeśli one są mniejsze. To jest coś, co ułatwia nam rozpoczynanie dużych zadań. To, co opowiedziałeś, czyli nie trzeba od razu dzielić wszystkiego, tylko znowu rekurencyjnie zastosujmy tę zasadę. Wydzielmy dwa, trzy pierwsze kroki, a resztę będziemy dzielić w miarę jedzenia, jak będziemy trochę dalej. Wtedy będziemy też mieć większą wiedzę i to nam też pozwoli lepiej zarządzać pozostałą częścią.

I ostatnia rzecz, czyli nie ograniczajcie się tutaj do tych algorytmów, do kodu, tylko też zobaczcie czy tego samego podejścia nie można zastosować także w fazie np. planowania tego projektu, np. określając jakieś MVP tego, co robimy. Dzielcie user stories na jak najmniejsze części, ale też zastanówcie się, żeby one nie były zbyt małe, bo to też może być problemem. I też zastanówcie się, czy tego algorytmu gdzieś tam w codziennym naszym życiu nie można by też wykorzystać. Tak że to są moim zdaniem najważniejsze takie punkty z tego odcinka.

 

To był odcinek o podejściu Dziel i zwyciężaj. A o czym będziemy rozmawiać w kolejnym?

 

W kolejnym – już ostatnim – odcinku tej serii będziemy rozmawiać o AI, czyli sztucznej inteligencji jako narzędziu, które wspomaga programistę w wytwarzaniu kodu.

 

Zapowiada się bardzo ciekawie, już teraz oczywiście na ten odcinek zapraszamy. Polecamy też zapoznać się z wcześniejszymi odcinkami, jest tam całkiem sporo przykładów z życia i mniej oczywistych zastosowań różnych narzędzi programisty.

Za ten odcinek, za to spotkanie bardzo Wam dziękujemy, zapraszamy do kontaktu, do oceniania w social mediach i na platformach podcastowych tego odcinka. Feedback jest dla nas bardzo cenny, bardzo za niego dziękujemy. Zapraszamy do odwiedzania strony Solid.Jobs, gdzie zawsze znajdziecie ciekawe oferty pracy z widełkami wynagrodzeń. Zapraszamy do dodawania tam ogłoszeń o pracę, a ja Wam i Tobie, Łukasz, za dzisiaj bardzo dziękuję.

Cześć!

 

Dzięki, Krzysztof, cześć!