podcast TechChatter
Odcinek 3

Bartek Gajowczyk: Cześć wszystkim. Z tej strony Bartek Gajowczyk. Jestem architektem oprogramowania Capgemini, gdzie zajmuję się zarządzaniem portfolio aplikacji dla jednego z klientów z branży finansowej. I do dzisiejszego podcastu zaprosiłem swojego kolegę Jacka, żeby porozmawiać o oprogramowaniu i lenistwie. Witaj Jacku.
Jacek Panachida: Cześć. Nazywam się Jacek Panachida. Pracuję jako deliver architekt. Obecnie nad systemami z obszaru data governance, data management. Właściwie interesuję się wszystkimi systemami, które przetwarzają dużą ilość danych. Dodatkowo pracuję jako people development leader, oraz jestem fanem, dużym fanem Agile’a. 
Bartek Gajowczyk: No to jak to jest z tym lenistwem? Czym właściwie jest lenistwo? Ja tak sobie pozwoliłem zajrzeć do słownika języka polskiego. No i lenistwo jest tam określane jako niechęć do wysiłku, niechęć do pracy. I gdybyśmy to przełożyli na programowanie, ja myślę, że programiści z natury są niechętni do nadmiernego wysiłku. Wszelkie rozwiązania, które są nadmiarowe, powtarzalne, wpisują się świetnie w naturę programowania. No bo po co robić coś dwa razy, jak można robić raz. Po co robić dziesięć, jak można robić dwa. I tak dalej. I tak dalej. Idąc tym tropem zacząłem się zastanawiać, czy lenistwo może być konstruktywne. Jacku, co ty o tym sądzisz?
Jacek Panachida: Ja myślę, że zdecydowanie. Gdyż tak samo, jeżeli będziemy rozpatrywać to na wyższym poziomie, jakby praca nad programowaniem, tak naprawdę niezliczona w liczbie napisanych linii kodów, wykonanych commitów, bądź liczby napisanych klas. Tak naprawdę liczy się ta wartość. Wartość, która została stworzona, dostarczona klientowi. I tak samo, jeżeli chodzi o lenistwo. Ja myślę, że po prostu warto spojrzeć na to jakby z wyższego poziomu, tak? Czyli nie z tej, powiedzmy, liczny spalonych kalorii, tylko właściwie na oszczędzonej, zbędnej, nudnej pracy i właściwie na skupieniu się na tym clue problemu, tak? Czyli właściwie można powiedzieć, że zwiększenie efektywności i produktywności.
Bartek Gajowczyk: No właśnie. Czyli wychodzi na to, że można wysunąć tezę, że dobry programista, to leniwy programista. No bo jeżeli mamy automatyzować, jeżeli mamy wdrażać usprawnienia, no to takie konstruktywne lenistwo tutaj nam jak najbardziej pomaga. Ja nawet ośmieliłbym się powiedzieć, że lenistwo poniekąd jest motorem rozwoju. No bo pomyślmy sobie o takim biznesmenie, który prowadzi sklep, no i oczywiście on chciałby, żeby ten sklep sam działał, żeby on mógł tylko leżeć na wakacjach, wylegiwać się do góry brzuchem, opalać się, pływać w basenie i żeby gdzieś tam z tyłu cały czas kaska leciała. No jak to osiągnąć? No można to osiągnąć. No oczywiście jest na to pewien narzut, ale no tutaj trzeba wdrożyć pewne rozwiązania, które często są dostarczane przez świat IT. No bo zamiast siedzieć za ladą w sklepu, możemy pójść online i wyjść z rozwiązaniem do szerszego grona odbiorców. Możemy zautomatyzować pewne procesy. Oczywiście, do tego wszystkiego potrzeba ludzi, czasu, inwestycji. Ale efektem końcowym, myślę, że jest całkiem fajne rozwiązanie, które pozwala nam zaoszczędzić czas, czyli poniekąd lenić się. 
Jacek Panachida: Zdecydowanie. Jedną właściwie z roli programistów jest tak naprawdę stworzenie sobie tego, jakby warunków do pracy. To znaczy właśnie zautomatyzowanie tych nudnych procesów, a jednocześnie sprawienie, że ta praca jest wydajna i przyjemna, tak? Czyli można powiedzieć, że to lenistwo tak naprawdę w moim przypadku na przykład bardzo często rozpoczyna się od czasu, który przeznaczam na rozmyślania, tak? W jaki sposób chcę rozwiązać dany problem, jak podejść do tego problemu, co tak naprawdę stanowi istotę problemu. Dopiero później, po rozmowie na przykład z wieloma osobami, przystępuję do działania. Też być leniwym, według mnie, to też jest unikanie takich, powiedzmy, zbędnych działań. Czyli unikanie takiego samopoczucia, gdzie po całym dniu jestem zmęczony, okazało się, że tak naprawdę krążyłem w kółko, moja praca nie przyniosła żadnych efektów. I pomimo tego, że czuję się zmęczony, tak naprawdę nie zrobiłem kroku dalej, więc tak jak wspomniałem, warto zacząć od zastanowienia się, co chcę tak naprawdę zrobić. A dopiero później realizować kolejne na to kroki.
Bartek Gajowczyk: Właściwie dochodzimy tutaj do wniosku, że te wszystkie jakby reguły, które krążą w świecie programistów, bardzo mocno się z tym spajają, bo jeżeli pomyślimy o chociażby całym Agile’u i cookbookach, o których ostatnio rozmawialiśmy, wszelkich ceremoniach scrumowych, no to one starają się ułożyć pracę programistów w ten sposób, żeby ona nie była nadmiarowa. Żeby zostały wprowadzone konkretne reguły, których wszyscy się trzymamy, których upraszczają nam zarówno komunikację, jak i dowożenie całości. Dowożenie, czy to jakichś malutkich zadań, czy to wielkich epików, story i tak dalej. I wczoraj jak rozmawialiśmy sobie podczas lunchowej pogawędki, wspominałeś nawet o kilku takich regułach krążących, myślę, że zwłaszcza na rozmowach kwalifikacyjnych do wielu firm, jak to akronimy bardzo popularne drajki, zjagni i tak dalej. Czy myślisz, że to też jest właśnie niejako przejaw takiego konstruktywnego lenistwa? Co byś powiedział o tych regułach?
Jacek Panachida: Absolutnie. To znaczy wbrew pozorom tak naprawdę stosowanie tych reguł wymaga wysiłku. To znaczy, one tak naprawdę w dużej części sprowadzają się do uporządkowania świata, ale takiego abstrakcyjnego, w którym się poruszamy, jako architekci. I wbrew pozorom uporządkowanie tego świata, wprowadzenie pewnych reguł jest to ciężka praca. Natomiast ona pozwala nam oszczędzić wiele pracy później, a jednocześnie być pewnym, że to nad czym pracujemy jest jak najbliżej, powiedzmy, A, wymagań klienta. I tutaj właśnie wymieniłeś te akronimy, typu don’t repeat yourself, keep it simple stupid, you aren’t gonna need it. I te wszystkie rzeczy sprawiają, że architektura, choćby którą tworzymy, jest bardziej przejrzysta I łatwiejsza w utrzymaniu. 
Bartek Gajowczyk: No właśnie, bo przecież kto chciałby pracować nad kodem, gdzie pojedyncza zmian, taka z punktu widzenia biznesu, wymaga dziesiątek, o ile nie setek, modyfikacji, kodów w różnych miejscach. Ponieważ ktoś zamiast zaprojektować dobrze rozwiązanie, to po prostu je skopiował. No ja nie raz widziałem kod napisany w nienajlepszy sposób, gdzie nie były zastosowane wzorce programistyczne i rozwiązanie było straszeni rozwleczone, zduplikowane. I nawet prosta modyfikacja, która z punktu widzenia biznesu wydawała się trywialna, okazywała się niezwykle wymagająca dla programistów. No trzeba było się przebić przez spaghetti różnych poplątanych warstw ze sobą, ponieważ nie było tam odpowiedniego podejścia. I tutaj wychodzi na to, że dobrze przemyślane rozwiązanie, dobrze zaprojektowana architektura, a nawet na niższym poziomie, nawet poszczególna klasa, fragment kodu, znacznie pozwalają oszczędzić czas, który jest potrzebny na dowiezienie zadania. 
Jacek Panachida: Zdecydowanie. Jakby tytułowe bycie leniwym tak naprawdę w wielu przypadkach sprowadza się do myślenia długoterminowego. Dbanie nie tylko o rzeczy, które dostarczamy, ale również jest to dbanie o innych członków zespołu. Tak właśnie. Żeby poczuli się członkami zespołu. Że wszyscy pracujemy nad tym rozwiązaniem. Wspomniałeś o tych cookbookach, które na przykład właśnie jako firma Capgemini rozwijamy w wieku obszarach, na przykład Agile’a. Są to materiały, które sprawiają, że osoby nowe w danym temacie, poczują bardziej, jakby bliżej danego zagadnienia i szybciej mogą stać się efektywne. Jednocześnie wskazuje pewne kierunki rozwoju, być może inspiruje. Ja myślę, że to jest niezwykle ważne. 
Bartek Gajowczyk: Mi tutaj na myśl przychodzi przykład w sumie z ostatnich kilku dni, gdzie takie nieszablonowe podejście właśnie jednego z moich kolegów, Piotrka, pozwoliło nam rozwiązać, może nie mega poważny problem, ale dość irytujący problem, jeżeli chodzi o aktualizację w jednym z systemów po stronie klienta. Okazało się, że mamy do wykonania taką zbiorową aktualizację pewnych danych w formularzu na stronie internetowej, aplikacji webowej, gdzie niestety nie można robić wielu zmian jednocześnie. Okazało się, że taka zmiana może przechodzić jedna po drugiej, czyli możemy wprowadzić jeden rekord, potem kolejny i za każdym razem te rekordy muszą być rozwiązywane, zapisywane i tak dalej i tak dalej. No i mieliśmy taki przypadek, że tych rekordów musieliśmy wpisać kilkaset. No i oczywiście jak programista spojrzy na tego typu problem, no to mówi, no zaraz, zaraz, ale dlaczego? Przecież powinno dać się to zaktualizować w sposób zbiorowy. My niestety nie mieliśmy do API pod spodem. Natomiast krótka analiza ruchu sieciowego i wszystkich requestów, które leciały pod spodem, pozwoliła właśnie Piotrkowi na znalezienie takiego workeranda, który by umożliwił właśnie zmodyfikowanie oryginalnego żądania i wysłanie tak zwanego batch update. Czyli zbiorowej aktualizacji. Dzięki temu no dostaliśmy pełną kontrolę nad aktualizacjami tego formularza i idąc dalej tą ścieżką wpadliśmy na pomysł stworzenia w ogóle oskryptowanego rozwiąznia, które docelowo może być w pełni zautomatyzowane. Gdzie konfiguracja dotycząca wartości w tymże formularzu może leżeć sobie gdzieś w repozytorium kodu. A pipeline odpowiedzialny za na przykład uderzenie do API, uruchamianego pod spodem, w efekcie sprawia, że jakakolwiek zmiana z repozytorium może automatycznie zaktualizować ten formularz bez konieczności ręcznej ingerencji i, dajmy na to, wielkiego narzutu takiego manualnego.
Jacek Panachida: Podałeś świetny przykład związany z takim nieszablonowym myśleniem. Właściwie skoncentrowaniem się na dostarczeniu rozwiązania. I jeżeli chodzi o automatyzację, ja mogę podać inny przykład, więc praca w pewnym projekcie wymagała od nas dostarczenia zmian na bazie danych w konkretnym formacie danych. A było wymagane od nas, żebyśmy poszczególne skrypty rozbili na części, odpowiednio je pogrupowali, zagregowali i tylko w taki sposób te skrypty mogły zostać wykonane później przez administratorów na bazie danych. W związku z tym, że to był akurat czas, w którym intensywnie pracowaliśmy nad rozwojem aplikacji, właściwie co sprint dowoziliśmy nowe funkcje, a więc zmian na bazie danych było całkiem sporo. Praca nad tymi zmianami, czy właściwie opis tych zmian na bazie danych, to była czynność kłopotliwa, czasochłonna i właściwie rozwiązanie nasze polegało na tym, że jeden z naszych kolegów przygotował skrypty, które odpowiednio obrabiają te zmiany pozytonowe, które przygotowaliśmy w godny dla nas sposób i przygotowują ten format dl agamy później przez DBE-ów. I właściwie ten skrypt został napisany na jednym z początkowych etapie projektu i później był sukcesywnie używany przez długi czas.
Bartek Gajowczyk: W takim razie można powiedzieć, że dzięki nieszablonowemu podejściu lenistwo twojego kolegi z zespołu, no bo nie chciał w kółko robić tego samego, zaprocentowało bardzo dużą oszczędnością czasu w późniejszych iteracjach. Jak tak patrzę na te tematy, które do tej pory poruszyliśmy, to ukazuje mi się taki obraz, w którym mamy pewne procedury, mamy procesy i mamy podejście ludzi, co sprawia, że sumarycznie, jak to złożymy w całość dążymy do, no powiedzmy, doskonałości. Ale dążymy przede wszystkim do płynności. Dążymy do takiej zwinności w dostarczaniu oprogramowania. I myślę, że sama nazwa agile jest tutaj świetna w tym kontekście, no bo właśnie ta zwinność, ten spryt i ta płynność w dostarczaniu rozwiązań moim zdaniem robi prawdziwą robotę w świecie programistów. Jakby pójść dalej tym tropem pewnie natrafilibyśmy na może bardziej konkretne rozwiązania, które wspierają nas wszystkich w codziennej pracy. I tutaj do głowy przychodzą mi wszelkie konwencje i reguły. Myślę, że nie raz podczas pracy projektowej każdy z nas, każdy z programistów, architektów, czy nawet analityków, zetknął się z dyskusjami dotyczącymi konwencji tworzonych rozwiązań. Jak ma wyglądać kod, jakich słów powinniśmy używać, jak on ma być sformatowany, jaka powinna być składnia. Czy powinny klamry się zaczynać w tej samej linii, czy w nowej linii. I tak dalej i tak dalej. Także wszelkie reguły formatowania, wszelkie reguły dotyczące składni, oraz narzędzia, które wspierają w trzymaniu porządku z kodzie. Chociażby jakiekolwiek pluginy mainvenowe albo plugginy do jakiegokolwiek innego narzędzia do budowania aplikacji, czy też do środowiska programistycznego. Także tutaj dużo zmieniają i pozwalają oszczędzić sporo czasu, bo tak długo jak wszyscy w zespole trzymają się dobrze opracowanych reguł i wiedzą, jakie są to reguły, no to możemy dużo łatwiej się komunikować. To jest tak trochę jak z wszelkimi rozmowami dookoła. BDD albo DDD. Gdzie tam rzeczywiście mega istotny jest kontekst i mega istotne jest zrozumienie i wspólne słownictwo, bo tak długo jak rozumiemy się nawzajem, tak długo możemy płynnie prowadzić wszelkie rozmowy, dyskusje, oraz wymieniać się pomysłami, oraz oceniać swoje rozwiązania.
Jacek Panachida: Zdecydowanie. Tutaj przed chwilą wspomniałeś o regułach, natomiast ja też często poruszam tematykę standardów. I te standardy mogą być opracowywane na wielu poziomach. Na poziomie kodu są to często interfejsy, które pomagają w organizacji kodu, pomagają w implementacji tak naprawdę tego, jak poszczególne moduły powinny się ze sobą komunikować. Jakie dane powinny ze sobą wymieniać. Później te zespoły już indywidualnie pracują nad poszczególnymi, nad swoimi częściami systemu właśnie na podstawie tych dobrze zdefiniowanych interfejsów. No dla mnie równie ważna jest konwencja nazewnicza. To znaczy świadomość całego zespołu, jakiego słownictwa używamy, jak nazywamy poszczególne komponenty, moduły. Jak tworzymy jakby nowe. I to wszystko pomaga stworzyć taki język, który jest używany w projekcie i pomaga również uniknąć takiej dwuznaczności, niejednoznaczności. 
Bartek Gajowczyk: No. To jest temat mega popularny wśród wszelkiej maści programistów. I też tak z własnego doświadczenia, jak spojrzę wstecz, pamiętam jak no uczyłem się jeszcze pisać ten kod, uczyłem się dobrze nazywać metody, klasy i tak bardzo szczegółowo opisywać wszystkie rozwiązania. Niewiele wiedząc jeszcze o architekturze i niewiele myśląc o architekturze, no bo nie oszukujmy się, mając tam parę lat doświadczenia, studia i może jakieś tam pierwsze komercyjne projekty, no to o tej architekturze za wiele nie wiedziałem. Było to jeszcze za wcześnie, żebym potrafił spojrzeć na to z góry i takim spostrzegawczym okiem powiedzieć, no zaraz, tu jest taka warstwa, tutaj powinien być taki interfejs. To przecież się wszystko ze sobą łączy i nadaje kształtu całości. Dlaczego o tym wspominam? No chodzi o to, że jak patrzę na taki swój wczesny kod, trochę się śmieję, że te nazwy zarówno klas, metod i zmiennych, no są strasznie długie i przypominają trochę takie wyśmiewane rozwiązania, gdzie to rzeczywiście wydaje się takie skomplikowane, ciężkie, rozpasłe i tak dalej. I jak spojrzę na coś, co staram się, przynajmniej teraz, dowozić, no to widzę, że te wszystkie kontrakty, o których wspomniałeś, czyli ta czysta architektura, bardzo pomagają uprościć zarówno nazewnictwo metod, zmiennych, klas, całych komponentów i paczek, bo dobrze zaprojektowany kod jest bardzo specyficzny. Jest bardzo ograniczony w swojej odpowiedzialności. I dzięki temu też łatwo zarządzalny. Czyli mamy taki malutki byt, który odpowiada za realizację pewnego wycinka wymagań biznesowych. Ale to pomaga mu właśnie w bardzo przejrzysty sposób zrealizować daną funkcjonalność. Więc możemy mieć, dajmy na to, jakiś interfejs, który jesteśmy w stanie opisać jednym, dwoma słowami, no bo on jest umieszczony w jakimś kontekście. Jakakolwiek metoda wewnątrz też może być jednym czasownikiem opisana. No bo my wiemy, że to jest właśnie na przykład kontroler tego widoku. I nie musimy mówić, że metoda w tym kontrolerze jest odpowiedzialna za przetwarzanie danych, które przyszły z bazy danych i lecą sobie po restowym api gdzieś dalej. My możemy po prostu powiedzieć przetwórz. I to jest to, bo cały kontekst, cała ta architektura dookoła, odpowiada na wszystkie inne pytania. Wystarczy na to spojrzeć i w bardzo łatwy sposób widać zależności między innymi warstwami. 
Jacek Panachida: To jest zresztą zgodne z taką zasadą, która mówi, żeby nie mnożyć bytów ponad potrzebę. To też praca, czy właściwie rozpoczęcie pracy w nowym projekcie, a również kontynuacja pracy polega wielokrotnie na tym, żeby połączyć pewne kropki. Tak złapać ten szerszy obraz i kontekst. I to, moim zdaniem, właśnie pozwala na dostarczenie takiego prawidłowego rozwiązania, które właśnie jest oczekiwane od dobrego programisty. I tutaj może też poruszę następny temat. Następny temat, który jest związany z taką jakby proaktywnością dobrego programisty. To znaczy, dobry programista myśli długoplanowo i dba o różne aspekty rozwoju oprogramowania. Czyli nie tylko o tą jakby fazę tworzenia tego kodu, jak również o fazę choćby testowania, tak? I tutaj mówię nie tylko o testach jednostkowych, ale również o innego rodzaju testach, na przykład wydajnościowych, które mają zapewnić, że ten produkt już używany przez użytkownika końcowego spełnia jego oczekiwania. I tutaj mam przykład właśnie takiej innej automatyzacji, którą wprowadziliśmy w projekcie. Podczas developmentu rozwoju jednego z komponentów musieliśmy generować, czy właściwie posługiwać się, dużą liczbą różnego rodzaju plików. I w zależności od wymagań, od sytuacji danego testu, te pliki miały mieć różną postać. I właśnie ta automatyzacja, którą wdrożyliśmy, polegała na tym, że napisaliśmy pewien generator tych plików. Czyli ustawiając poszczególne opcje mogliśmy wygenerować pliki, które odpowiadały różnym scenariuszom testowym. Więc jeżeli chodzi właśnie o bycie dobrym programistą, to ja widzę też jako element bycia dobrym programistą również to szersze patrzenie tą sprawę. Czyli nie tylko jakby samo tworzenie tego oprogramowania, jak również zapewnienie, że to oprogramowanie rzeczywiście działa. I tutaj wspomniałem o tego różnego rodzaju testach, ale innym przykładem może być metaprogramowanie. Czyli zapewnienie, że ten kod, który tworzymy jest opisany w odpowiedni sposób. Czyli dodajemy taką jeszcze dodatkową warstwę abstrakcji, która w wielu przypadkach pozwoli nam uniknąć błędów. Czyli można powiedzieć, że konkretne adnotacje, bądź inne metody ostrzegą nas, gdy, powiedzmy, stan systemu wymknie się spod jakby oczekiwanego stanu. 
Bartek Gajowczyk: Skoro mowa o otrzymaniu właśnie rozwiązań, więc nie tylko tworzeniu nowych, to tutaj mi się nasuwa na myśl jeszcze jeden świetny przykład z mojej kariery. Co prawda nie mój, ale mojego kolegi Przemka, który dołączył do projektu, w którym byłem, oj, lata temu to było, bodajże z 10 lat temu. Mieliśmy wtedy bardzo intensywny okres, gdzie pracowaliśmy nad, tak naprawdę, portfolio aplikacji. Wszystko w technologiach około javowych, bo tam była Java, Skala, Groovie może do testów. Ale głównie Java i scala. Natomiast było kilka końcowych aplikacji, bodajże pięć i one miały sporo wspólnych komponentów. Sumarycznie pewnie koło 50 komponentów naszych własnych na drzewku zależności. No i w związku, że to był bardzo gorący okres, zespół około 10, 15 programistów rozsianych po całym świecie, no to problemem było dla nas zarządzanie różnymi wersjami nie tylko końcowych aplikacji, ale każdego składowego komponentu. No bo równolegle potrafiliśmy prowadzić prace nad trzema różnymi wersjami tych komponentów. W związku z tym, że jedna aplikacja końcowa zależała jeszcze od tej najstarszej wersji, potem mieliśmy jakąś inną aplikację, która była już na nowszej wersji jakiegoś komponentu. A jeszcze mieliśmy najnowszą wersję serwera, który korzystał jeszcze z czego innego, bo tam już zupełnie inne reguły wprowadziliśmy. No i jeśli do tego się doda rozbudowanie właśnie tego modelu, rozszerzenie tego modelu na jeszcze zależności przechodnie, no to robi się całkiem duże, całkiem spore zamieszanie z wprowadzaniem wszelkiego rodzaju zmian i dostarczaniem back fixów dla tychże komponentów. No i wtedy początkowo próbowaliśmy po prostu jakoś merge’ować to między branchami, zachować kolejność, upewnić się, że nie ma konfliktów. Zajmowało to całkiem sporo czasu i największym wyzwaniem było po prostu synchronizowanie się między różnymi członkami zespołu, którzy mogli pracować nad zupełnie innymi rozwiązaniami i wymaganiami. Zupełnie nawet nie wiedzieli o tym, co dowozi inna osoba. No i Przemek przyszedł, zobaczył, co tutaj się dzieje i on powiedział, no zaraz, zaraz. Ale po co my mamy się zastanawiać, skoro możemy przecież stworzyć sobie proste reguły. Wiemy, które komponenty są najstarsze, a które są najnowsze. Właściwie, które wersje. I możemy sobie stworzyć taką strukturę i konfigurację, która będzie nam mówiła, no okej, wszystkie zmiany z tej wersji powinny wejść do tej wersji i tak dalej i tak dalej. Oraz możemy mieć reguły, że no wiadomo, tutaj trwa development, no to żeby jeszcze za szybko nie krzyczeć i nie alarmować, no to niech będzie chociażby tydzień, dwa, na domerdżowanie tego wszystkiego. No i Przemek postanowił to zautomatyzować. I on napisał plugin w scali do mainevena, który wpięliśmy we wszystkie projekty i ostatecznie zapomnieliśmy o kwestii w ogóle mergowania tychże zmian, na zasadzie no nie trzeba było się zastanawiać, co, gdzie domerdżować. Z którego brancha do którego. Czy coś jeszcze w danej wersji komponentu brakuje, czy już wszystko zostało dostarczone. Bo każda zmiana pojedyncza no była przetwarzana, wtedy to był projekt na SVN-ie, więc szedł komit do SVN-a. Natomiast ten plugin przy każdym bildzie, każdego komponentu, generował raport i sprawdzał czy reguły, które tam wprowadziliśmy, no bo te reguły też były konfigurowane, no przecież nie będziemy trzymać się jednej, sztywnej reguły. Dla różnych aplikacji mogą być te reguły inne. No to te reguły nam mówiły, okej, czy tutaj krzyczeć i wywalić bild, czy tylko na żółto zaświecić się z warningiem i powiedzieć, ej, słuchajcie, tutaj została jakaś zmiana wprowadzona, a jeszcze jej nie macie na ten wersji. Może trzeba coś w tym zrobić. No i dookoła tego zbudowaliśmy sobie taki fajny bildchain, stworzyliśmy sobie nawet dedykowany komponent, który generował nam raz, bodajże, na dzień albo raz na tydzień raporty dotyczące wszystkich projektów, no a poza tym każdy projekt miał ten plugin wpięty z osobna. I myślę, że do końca istnienia tych projektów na SVN-ie, to zrobiło nam grubą robotę. Oczywiście po latach przeszliśmy do wspierania tylko najnowszych, najświeższych wersji, co nam znacznie uprościło proces. Natomiast no dzięki Przemkowi, pozdrawiam go serdecznie, jeśli nas słucha, mieliśmy z górki i to przez kilka ładnych lat. 
Jacek Panachida: Też mi się od razu skojarzyło, że dobry programista to jest osoba, która stawia sobie wyzwania, a jednocześnie unika tej powtarzalności. Wspomniałeś jeszcze o automatyzacji. Natomiast są znane również inne techniki, które sprawiają, że praca staje się bardziej przyjemna i bardziej efektywna. Taka z jednych, kolejnych rzeczy, która mi przychodzi do głowy, to jest po prostu znajomość narzędzi, z których się korzysta. To znaczy na przykład środowiska programistyczne, które mamy dostępne obecnie obfitują w różnego rodzaju funkcje. Niezwykle istotne jest to, żeby je poznać i rzeczywiście móc je efektywnie stosować. Ja wspomniałem tutaj tylko o środowisku programistycznym. Natomiast ta sama zasada właściwie odnosi się do różnych frameworków, bibliotek, systemów, które mogę być używane do tworzenia, wytwarzania oprogramowania. Albo gotowych narzędzi, czy gotowych systemów, z których korzystamy, jako część składowa.
Bartek Gajowczyk: Wiesz co? Jak najbardziej się zgodzę z tym. Dlatego też bardzo promuję pair programming i to w każdej możliwej formie. Wiadomo, odkąd przyszedł COVID bardzo mocny jest nacisk na pracę zdalną i w ogóle bardzo duża chęć pracy zdalnej. Natomiast moim zdaniem taki pair programming w formie fizycznej to jest świetna sprawa, bo nie raz zdarzyło mi się siedzieć koło jakiegoś właśnie bardziej doświadczonego kolegi z zespołu, który po prostu w mgnieniu oka wstukał parę skrótów klawiszowych i wygenerował sobie w środowisku programistycznym jakieś rozwiązanie, albo dużo przyspieszył analizę kodu, albo w świetny sposób potrafił zdebugować rozwiązanie i zdebugować jakąś aplikację. Znaleźć problem, rozwiązać problem produkcyjny. Także to są rzeczy, oczywiście można to robić zdalnie i też robimy to zdalnie, natomiast to są rzeczy, które super widać podczas programowania w parach. Dlatego ja bardzo lubię, zwłaszcza jak jakaś młoda osoba dołącza do zespołu, podzielić się tą wiedzą. Podzielić się doświadczeniem. Ale nawet wśród bardzo zaawansowanych programistów, architektów, zdarzyło nam się po prostu na sesji jakiejś wspólnej siedzieć i nagle takie po prostu zdziwienie wszystkich. Wow, jak ty to zrobiłeś? Człowieku, podziel się tym. No i okazuje się, że jest cała masa trików, z których korzystamy. Czasem pewnie nawet nieświadomie. Ale które bardzo usprawniają pracę. No i jedno to jest właśnie narzędzie, a drugie to jest framework, bo znajomość taka dogłębna rozwiązania pozwala naprawdę, naprawdę w dużo lepszy sposób napisać swój własny kod, dostarczyć coś dla biznesu. I tutaj wydaje mi się, że mega istotne jest doświadczenie. 
Jacek Panachida: Tak jest. Też warto może zaznaczyć, że ten dobry programista, który jest leniwym programistą, ma świadomość tego, że jednak czas to jest zasób ograniczony. Dlatego przede wszystkim skupia się na rzeczach ważnych. Potrafi sobie pogrupować te rzeczy tak, żeby móc zacząć właśnie pracę od tych rzeczy najważniejszych. Tak, żeby później móc znaleźć czas na te wszystkie rzeczy, które musi wykonać. I tutaj wspomniałeś też o tym, że praca dobrego programisty w wielu przypadkach skupia się na komunikacji z innymi ludźmi. Ja też chciałbym to przełożyć może nad pracę nad systemem, więc jeżeli dokonujemy codziennych zmian w systemie w postaci commitów, niezwykle ważne jest to, żeby te zmiany, które wprowadzamy były jasne dla innych członków zespołu. To oczywiście może sprowadzać się do dobrego opisu tekstowego tej zmiany. Natomiast tutaj też wraz tutaj z podejściem Agile’owym ważne na przykład jest dla mnie to, żeby każda wprowadzona zmiana miała jakąś wartość biznesową. Tak, żeby była łatwa do zrozumienia przez wszystkich członków zespołu, jak również później przez naszych stakeholderów. 
Bartek Gajowczyk: No dobra. Czyli podsumowując, mamy clean code, mamy clean architecture, mamy procesy i narzędzia, które nas w tym wspierają, ale przede wszystkim ponad to mamy podejście. I myślę, że podejście jest tutaj kluczowe. Takie dobre lenistwo, sprytne, sprawia, że te rozwiązania, nad którymi pracujemy, mogą być coraz to lepsze, coraz to szybsze. A jeżeli nie, no to przynajmniej dowiezione w rozsądnym czasie i z wykorzystaniem optymalnego budżetu. 
Jacek Panachida: Mi też wpadło właśnie do głowy takie może stwierdzenie, że jakby bycie dobrym programistą, to jest właśnie szukanie takich elementów, które sprawiają radość, czyli właśnie unikania takich nudnych. Czyli sprawienia, że właściwie mamy większą kontrolę nad tym, co robimy. Czyli zamiast na przykład produkowanie ręczne tych różnych plików testowych, możemy napisać w ramach na przykład w innym jakimś nowym języku programowania. Jeżeli używamy na co dzień javy możemy napisać właśnie ten program w kotlinie, który nam generuje pliki. Moim zdaniem to jest jakby, daje nam poczucie takiej sprawczości. Spycha, powiedzmy, tą nudę na bok i też no pozwala właśnie na automatyzację tego rozwiązania, no i zwiększenie efektywności. 
Bartek Gajowczyk: No rutyna nigdy nie jest dobra. Rutyna i taka nuda wynikająca z powtarzalności. Ja spotkałem na swojej drodze myślę, że dwa rodzaje programistów. Osoby, które są leniwe źle, tak negatywnie i po prostu chcą szybko zrobić łatwym kosztem swoje zadanie, ale na zasadzie odbębnić je. No więc zajrzą sobie na jakiś już istniejące rozwiązanie, skopiują je, wkleją gdzieś. Niespecjalnie zastanowią się nad tym. No i spotkałem na swojej drodze też ludzi takich leniwych pozytywnie, którzy też zajrzą na to rozwiązanie, porównają i zastanowią się, czy można wyciągnąć części wspólne, bo teraz przyszło takie wymaganie. Tak naprawdę pół roku temu mieliśmy podobne wymaganie, więc to już jest drugi raz, gdzie musimy coś zmienić. To może warto tutaj pewną warstwę abstrakcji zrobić, a może warto to jakoś przepisać? No i wtedy pojawiają się pomysły, które rzeczywiście usprawniają pracę. Także jak najbardziej trzeba trochę spędzić czasu na główkowaniu i potem do przodu, bo efekty naprawdę, naprawdę mogą być super.
Jacek Panachida: Idąc dalej można powiedzieć, że bycie leniwym programistą to jest ograniczenie sobie zbędnej pracy. To znaczy przed implementacją jakieś nowej funkcji w systemie niezwykle ważne jest to, by poznać wszystkie wymagania funkcjonalne i niefunkcjonalne. I dopiero wtedy, gdy te wymagania, a można powiedzieć spełniają definition of ready, można przystąpić wtedy do pracy. Po prostu gdy ma się pełne zrozumienie problemu. Albo można te części zmienne po prostu enkapsulować. Wiedząc, że potencjalnie one mogą się zmienić w przyszłości. Czyli zbytnio nie usztywnić tych elementów. I to wszystko przychodzi po części z doświadczeniem, ale też jest wynikiem po prostu rozmów albo z członkami zespołu albo właśnie z klientem.
Bartek Gajowczyk: Szczerze mówiąc ja nie raz się przejechałem na takich zewnętrznych zależnościach, czyli fragmencie kodu, biblioteki, który gdzieś tam do nas został dostarczony i zdecydowaliśmy się go wpiąć bez jakiejś enkapsulacji, bez dodatkowej warstwy abstrakcji. A potem okazało się, że mamy straszne problemu z nim, czy to z samym testowaniem. Chyba każdy programista lubi sobie ponarzekać na rokowania statycznych wywołań, albo finalnych wywołań. I w ostatnim czasie po prostu, jeżeli gdzieś coś takiego widzimy w projektach, to unikamy jak ognia, bo wiemy, że są z tym problemy i to już doświadczenie pokazuje, że nie ma co pchać się właśnie w tą stronę. Lepiej rzeczywiście troszkę wyabstrahować, trochę się odciąć i mieć pełną kontrolę nad tym, co się dowozi. No ale tak jak wspomniałeś, to nie od razu Rzym zbudowano. Trochę trzeba doświadczenia albo wsparcia kogoś z boku, kto jednak swoje już przeżył. Swoje na ścieżce programistycznej przeszedł i może pochwalić się tym wyczuciem i doświadczeniem. 
Jacek Panachida: Jeżeli wspomniałeś o pracy w grupie, niezwykle ważnym dla mnie aspektem jest dokumentacja. A i ta dokumentacja może mieć różną formę. Może mieć postać dokumentacji w kodzie, na przykład w javie za pomocą java doków. Natomiast również stosujemy dokumentację na przykład architektury zastosowanych rozwiązać bądź procesów, które nie zostały jeszcze zautomatyzowane, bądź trudno je tak naprawdę zautomatyzować. I dla mnie ważne, jako odbiorcy, który czyta tą dokumentację, bądź tworzy, jest przygotowanie jej w niezwykle ustrukturyzowanej formie. Tak, żeby była przyjemna dla użytkownika. Tak, żeby osoba nawet nie zaznajomiona z tym tematem mogła go, powiedzmy, można powiedzieć w sposób leniwy przeczytać krok po kroku od początku do końca. I będąc pewna, że te wszystkie wykonane kroki po drodze doprowadzą ją do prawidłowego rozwiązania. Więc ja zawsze upatruję, że gotowe rozwiązanie składa się nie tylko z kodu, ale również z odpowiednich testów, jak i dokumentacji. I dopiero te trzy elementy stanowią wartość dla klienta, ale również dla pozostałych członków zespołu. 
Bartek Gajowczyk: Z tą dokumentacją to jest ciekawa sprawa, no bo wiadomo, programiści uwielbiają tworzyć tony dokumentacji. Natomiast muszę powiedzieć, że nie jest tak źle, bo to lenistwo w przypadku dokumentacji też się całkiem fajnie zakończyło. Znaczy zakończyło, no to cały czas się dzieje, ale są narzędzia na rynku, które i to pozwalają zautomatyzować. Ostatnio jak byłem na konferencji JDD w Krakowie, to właśnie była prelekcja dotycząca między innymi automatyzacji dokumentacji dotyczącej bazy danych. Nie pamiętam dokładnie szczegółów teraz, natomiast, jeżeli ktoś jest zainteresowany, to może sobie poszukać tego typu rozwiązań i sprawdzić jak to można sobie zmieniający się model bazy danych łatwo wygenerować przy użyciu odpowiednich narzędzi i zapomnieć o tym, że jakieś diagramy mają się pojawiać. Jeżeli tak jest akurat wymaganie klienta. No bo to wszystko da się w sensowny sposób zautomatyzować. Także każde powtarzalne czynności należy pamiętać, że zawsze jest na nie sposób. Trzeba tylko chwilę się zastanowić i na pewno będzie sensowna droga do dowiezienia tego.
Jacek Panachida: Tak jest. Tutaj, jeżeli chodzi o temat bycia leniwym programistą, to przyszedł mi też również do głowy sposób podejmowania, czy dostarczania rozwiązania. Jest takie znane powiedzenie, że właściwie raz zrobiona robota, to dobra robota, tak? Czyli ten dobry programista, który jest leniwym programistą nie wraca już do tego, co zostało stworzone. To znaczy ma pewność, że to, co zostało dostarczone do tej pory jest dobre, zostało zweryfikowane, ma jakąś wartość. No i wie, że może się skupić na dalszych rzeczach. A to, co już dostarczył może stanowić fundament dla innych do dalszego jakby rozwoju na przykład systemu.
Bartek Gajowczyk: No jak najbardziej, myślę, że takie poczucie, tudzież przeświadczenie o dowiezieniu, o zakończeniu pewnego etapu, o zrealizowaniu zadania jest na pewno budujące. Ale idąc Agile’owym tropem bym powiedział continuous refactoring, to jest coś, co nigdy się nie powinno kończyć. My nie powinniśmy osiadać na laurach i tak naprawdę zamrażać jakiegokolwiek fragmentu kodu. Chyba, że nie ma żadnej potrzeby. Są takie biblioteki, które, chociażby w Apache Commons od 10 lat się nie zmieniły. No bo nie ma takiej potrzeby. One robią swoje i mają robić tylko tyle, co wtedy zaimplementowano i to jest okej. Natomiast w większości jakichś takich bardziej zaawansowanych biznesowych rozwiązań wszystko ewoluuje i trzeba się z tym pogodzić. No i nie bać się. Nie bać się dotykać czegoś, zmieniać, usprawniać. W miarę potrzeb oczywiście.
Jacek Panachida: I tutaj myślę, że ogromną rolę odgrywa automatyzacja. Natomiast już na poziomie integracji i dostarczania oprogramowania na produkcję. Czyli tutaj mówię konkretnie o rozwiązaniach CICD, które odpowiednio napisane sprawiają, że programiści właśnie nie boją się podjąć zmian w systemie, wiedzą, czy mają jakby zwiększoną pewność tego, że zmiany, które dokonują są testowane po drodze zanim trafią na produkcję. Na przykład w jednym z obecnych systemów mamy zaimplementowane quality gatesy, które weryfikują na bieżąco kod pod względem metryk. Dają nam znać, gdy nastąpi jakiś błąd, powiedzmy po naszej stronie, który wymaga naszej uwagi. 
Bartek Gajowczyk: Pipeline’y, wszelkiego rodzaju rozwiązania buildowe robią dużą różnicę w porównaniu z jakimiś takimi manualnymi podejściami. Mi się wydaje, że to jest obecnie standard, ale wiem, że są jeszcze projekty, gdzie nie jest tak gładko i nie są w pełni rozwiązania CICD zaimplementowane, ale naprawdę to daje duży spokój. Spokojną głowę, bo nie musimy się po pierwsze bać, że nasza zmiana coś namiesza. No mamy to otestowane jednostkowo, integracyjnie. Idealnie by było, żeby to jeszcze leciało sobie przez wszystkie stage’a, no i jeżeli mamy dobrze napisane reguły, no to niech leci kod na produkcję. Czemu nie? Także dobry przepływ, continuous integration, continous delivery, continous deployment, jak najbardziej pomaga. I myślę, że też daje dodatkowe poczucie satysfakcji, bo nie tylko widzimy jak się testy odpalają, nie tylko sprawdzamy sobie lokalnie na naszej maszynie, tudzież na jakimś testowym serwerze, jak rozwiązanie działa, tylko widzimy, że to przechodzi przez te wszystkie etapy i możemy się cieszyć, że jest zielono. O ile jest. No ale życzę wszystkim, żeby było.
Jacek Panachida: Tutaj też w temacie właśnie bycia tym leniwym programistą, świetnie wpisuje się sposób tworzenia testów jednostkowych. To znaczy piszemy tak mało kodu, jak to jest tylko możliwe, żeby te testy, poprawne testy przeszły, tak? I myślę, że to też jest niezwykła wartość, którą powinien się kierować dobry programista. I właśnie uskuteczniana za pomocą sposobu tworzenia oprogramowania połączonego z testowaniem jednostkowym.
Bartek Gajowczyk: No dobra. Wiemy jak to wszystko się robi, albo jak powinno się robić. Natomiast zastanawiam się, co nam przyniesie przyszłość? Jacku, jak myślisz, jakie zmiany nas czekają albo co w najbliższym czasie może się zmienić na rynku? Albo jakie rozwiązania mogą pomóc wszystkim programistą rozkoszować się tym błogim lenistwem? 
Jacek Panachida: Więc pierwsze co przychodzi mi do głowy to są rozwiązania typu AI, machine learning i właśnie jedno z tych rozwiązań zastosowaliśmy w naszym ostatnim projekcie. To znaczy wiele weryfikacji, które były dokonywane przez ludzi zastąpiliśmy przez, poprzez modele machine learningowe i dzięki temu znieśliśmy nie tylko liczbę tych nieprawidłowych odpowiedzi, ale również odciążyliśmy ludzi, którzy robili te weryfikacje. A jednocześnie w dużo krótszym czasie byliśmy w stanie udzielić tych wszystkich odpowiedzi i zwrócić je do kolejnego systemu. Więc tak naprawdę myślę, że to jest bardzo dobry przykład takiego rozwiązania, które pozwala odciążyć ludzi takimi powtarzalnymi zadaniami. Drugi pomysł, który przychodzi mi do głowy jest po prostu wirtualna rzeczywistość. Wielokrotnie w pracy pomogłaby mi podczas wizualizacji poszczególnych elementów systemów, czy nawet całych systemów. Ja chciałbym mieć możliwość właśnie przedstawienia tego, jak system działa w 3D. jak systemy się ze sobą komunikują, jakie dane przetwarzają, z jaką prędkością, jakie istnieją pomiędzy nimi powiązania. To obecnie funkcjonuje, to znaczy można generować różnego rodzaju raporty, natomiast myślę, że taka właśnie możliwość zapoznania się z tymi informacjami w formie 3D ogromnie ułatwiałaby mi pracę.
Bartek Gajowczyk: Jak najbardziej się tutaj zgodzę z tobą. Takie koncepcje, które znamy, czy to z filmów, czy z książek Stanisława Lema, to wcale nie jest pieśń przyszłości. To jest coś, co się już dzieje. No ja myślę, że niewiele nam potrzeba, żeby już całkiem niedługo skorzystać z rozwiązań, które pozwolą nam zastosować augmented reality, wizualizacje. Coś, co znamy chociażby, nie wiem, z urządzania domu, bo myślę, że to jest standardowe rozwiązanie, jak ktoś próbuje urządzić sobie mieszkanie. Zamawia u architekta wizualizację, no żeby wiedzieć jak to jednak będzie w 3D wyglądało. No i tak jak wspomniałeś, jeżeli byśmy właśnie mogli zamiast spoglądać na papierki, na jakieś diagramy, które są dość płaskie, zanurzyć się w tej wirtualnej rzeczywistości i pochodzić sobie między komponentami w taki sposób interaktywny, no to pozwoliłoby nam dużo lepiej, raz, że zrozumieć system, a dwa, że wytłumaczyć jego działanie wszystkim ludziom. Szczególnie tym mniej technicznym. No bo wiadomo, programista, architekt, analityk, doskonale sobie radzą w tym swoim obszarze, ale już użytkownik końcowy, człowiek z biznesu, osoba z marketingu, ktoś, kto to sprzedaje, menedżer, nie mają takiej technicznej płynności. A taki dodatkowy bodziec, czyli to działanie na wzrok, myślę, że na pewno pomoże w odbiorze i w zrozumieniu. Dobra. Fajnie nam się rozmawiało Jacku. Dziękuję ci bardzo za udział. Rok temu ty mnie zaprosiłeś do innej dyskusji, też około architektonicznej. Także cieszę się, że mogłem ja się zrewanżować i porozmawiać na też może podobne tematy, ale w trochę innym tonie. Mam nadzieję, że jeszcze kiedyś coś nam razem uda się zrobić. Dzięki wielkie, no i wszystkich słuchaczy pozdrawiam i życzę błogiego lenistwa w programowaniu. 
Jacek Panachida: Dziękuję Bartku za zaproszenie. Było mi niezwykle miło porozmawiać na tematy dla mnie ważne. Czyli tematy związane z byciem dobrym programistą. Z możliwością rozwoju na tej ścieżce. Omówiliśmy tutaj wiele, wiele tematów, które mam nadzieję okażą się przydatne dla naszych słuchaczy. No i również dziękuję za udział w tym podcaście. 
Bartek Gajowczyk: Do dalszej lektury polecam Githuba, jak i blog Daniela Pokusy, na którym porusza on tematy związane z wydajnością, z automatyzacją, z usprawnieniami w kodowaniu. No i zwłaszcza materiałem godnym polecenia będzie jego pomysł na usprawnienie efektywności w wykorzystywaniu terminala linuxowego. 
Jacek Panachida: Ja polecam książkę Andrew Hampta “Pragmatyczny programista. Od czeladnika do mistrza”. Jest to książka, która opisuje w przystępny sposób różne sposoby, które pomagają stać się lepszym programistą. Pokazuje na konkretnych przykładach, jak możemy dostarczać lepsze oprogramowanie. Oprogramowanie, które będzie bardziej zrozumiałe dla użytkowników. Drugą pozycją jest książka z zakresu psychologii Daniela Kahnemana “O pułapkach myślenia, o myśleniu szybkim i wolnym.” Jest to niezwykle bogata pozycja, która porusza wiele tematów. Natomiast, jeżeli chodzi o nasz dzisiejszy temat, to ja myślę, że w bardzo fajny sposób obrazuje sposób w jaki myślimy. W jaki podejmujemy decyzje. I tutaj myślę, że wiele osób mogłoby być zainteresowanych tym, w jaki sposób działa nasz mózg i właśnie kiedy pozwalamy sobie na zbytnie lenistwo, a kiedy to lenistwo jest wręcz pożądane.