乌鸦传媒

Bartek Gajowczyk: Cze艣膰 wszystkim. Z tej strony Bartek Gajowczyk. Jestem architektem oprogramowania 乌鸦传媒, 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鈥檃.聽
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鈥檜 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鈥檛 repeat yourself, keep it simple stupid, you aren鈥檛 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 乌鸦传媒 rozwijamy w wieku obszarach, na przyk艂ad Agile鈥檃. 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鈥檕wa膰 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鈥檕wym 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鈥檕wym 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鈥檡, 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鈥檃, 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 鈥淧ragmatyczny 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 鈥淥 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.聽