Ostatnie Patoszkolenie w tym roku👇
Czy architekt powinien kodować? W tym odcinku poruszamy tą jakże istotną kwestię: a także co nieco o jakości kodu.
Linki i ciekawe znaleziska:
Szymon Warda [SW]: Cześć, słuchacie Patoarchitektów Short! Prowadzą Szymon Warda…
Łukasz Kałużny [ŁK]: …I Łukasz Kałużny. Wszystkie linki do tego odcinka klasycznie znajdziecie na patoarchitekci.io Tym razem: /57. No to co, miło wrócić po przerwie. Trochę się stęskniłem za mikrofonem, chociaż nie za porannym wstawaniem, żeby to nagrać.
SW: Dla kontekstu: ósma trzydzieści.
ŁK: Dobra, lecimy. Co masz, Szymon?
SW: Ja mam dla Ciebie zagadkę. Dostałem się do raportu. I żeby nie było, jakiejś tam stronniczej organizacji, mianowicie organizacji Association of Digital Machinery. I raport dotyczy tego, ile czasu jest marnowane. To jest ważne. Marnowane. Czasu deweloperów marnowane jest na tzw. no… Technical Depth. Strzel liczbę. Jaki procent ich czasu jest marnowane na technical depth?
ŁK: Dobra ,obstawiam że pomiędzy 20-30 procent.
SW: 42. I że tak powiem ładnie, I’m calling bullshit on that. Mój problem w ogóle z całym liczeniem chodzenia wokół technical depth jest taki, że po pierwsze żyjemy z tym co mamy, ale nie jest to liczone w kontekście tego, ile kosztowałoby nas przepisanie. To jest pierwsza rzecz. Po drugie wcale nikt nie powiedział, że przepisanie się uda i obniżymy to w jakikolwiek sposób; w ogóle, że nie cofniemy się tak naprawdę. I sorry, ten technical depth… To, że łatwiej się pracuje na kodzie, który jest nowy, to często wynika z tego, że on jest cały czas rozwijany, że ludzie mają tą wiedzę w głowie, a nie z tego, że te biblioteki, są starsze. No naprawdę czasem tak jest. Zgodzę się jak najbardziej, ale to wynika z aktualności wiedzy i tego nigdy nie przeskoczymy. Pewne systemy mają różne czasy życia, niektóre są aktualnie rozwijane, niektóre są mniej rozwijane, nawet obszary systemów i tak to będzie zawsze wyglądało.
ŁK: Kurde właśnie ten… Jeden kontekst… Szymon zabronił mi tego otwierać przed nagraniem tego linka przed zapoznawaniem się. To jest druga rzecz. Kurde, trafiłem na idealny link. Idealny komentarz do tego, który w ogóle to świetnie podsumowuje, bo ostatnio na LinkedInie, Twitterze, znowu ten technical depth się ostatnio w feedach przelewał w różnych tam wejściach - i bodajże ex-CTO GitHuba bardzo fajną rzecz powiedział w ogóle na temat przepisywania systemów i innych rzeczy, jeżeli nie potrzebujesz za dużo FT żeby utrzymać system, to go nie przepisuj.
SW: Dokładnie tak, jeżeli system jest na takim typowym maintenance’ie, nie ruszaj go, nie masz nawet wiedzy domenowej, żeby go ruszać.
ŁK: Tak, dokładnie - I wiesz, dlatego powiedziałem, że to jest 20 - 30%. Gdzieś tam nam produktywność ściąga, to, że tak powiem brak wiedzy, syfność kodu i inne takie rzeczy. Nie wierzę w to, że to jest…
SW: 60%.
ŁK: Inaczej. Znam projekty, w których są tak przekombinowane, że jest to prawdziwe, ale to nie wynika z tak naprawdę długu technologicznego, tylko że ktoś nawalił abstrakcję na abstrakcji.
SW: Też, albo czasami to jest dług technologiczny, ja się z czymś zgodzę.
ŁK: Tak, ale to nie są jakieś…
SW: Problem był taki, że to jest… Przy odpowiednim rozmiarze systemu to nie zrobimy tak, że nie napiszemy go w ciągu jednego dnia, żeby miał zero. Z reguły to są systemy, które są tworzone przez lata. Więc nawet jak zaczniemy przepisywać, to on ten dług zbierze. Po prostu nie utrzymamy tego.
ŁK: Tak, jest jedna rzecz, którą w ogóle trzeba było kiedyś… To jest odcinek, którego nigdy nie nagraliśmy, ale trzeba by wreszcie nagrać też o długu technologicznym, bo można go na różnych poziomach bardzo różnie rozumieć.
SW: Zgodzę się, dla mnie dług technologiczny, taki realny, to jest coś, co faktycznie nas zwalnia w kontekście rozwoju biznesu. To jest taki dług, którym powinniśmy się przejmować. Cała reszta - sorry, nie.
ŁK: Wiesz co? Dorzuciłbym do tego jeszcze koszty i security, bo to są też… Bo one się realnie na to przekładają, na efektywność i inne rzeczy.
SW: Tak, zgodzę się, faktycznie to ominąłem, ale to powinno być dodane. Ale cały dziki pęd w kontekście zróbmy przepisanie nie ma żadnego sensu. Od tego jest architektura, żeby takie systemy ładnie wydzielać. I gdzieniegdzie mamy bałagan, powiedzmy sobie to delikatnie - i tam to ładnie enkapsulujemy, że tam nie wycieka ten cały bałagan, a gdzie indziej rozwijamy, dobudowujemy. I tak dalej, i tak dalej. Bo pierdolnik będzie zawsze, pytanie, czy to nam się rozleje po całości. Czy będzie w jednym, kilku miejscach.
ŁK: Tak, świadoma modelaryzacja burdelu?
SW: Tak, bo tu tu właśnie leży wartość systemu opartego na serwisach… Specjalnie nie mikroserwisach. Właśnie, że upychamy to, że wiemy gdzie jest pierdolnik, tam gdzie mamy “nowo”, to lecimy nowym bez długu technologicznego. Tego się po API komunikujemy, a tam gdzie “staro” to też mamy staro i to ruszamy raz na miesiąc i nas nie zwalnia.
ŁK: Dokładnie tak, ale 42%? Nie, naprawdę? Aż mnie teraz zaintrygowało to, żeby wejść bardziej do środka tego i zobaczyć jakie podjęli de facto mierniki. Bo to jest tak zwana… wygląda to…, Nie jak liczba taka z palca, tylko liczba z dupy.
SW: Tak, w ogóle. Wartości, które przyciągają… I widać od razu, że to, jak to liczyli, to było bardzo stronnicze wg. mnie. Np. piszą, że w nowym - stary kod ma piętnaście razy więcej defektów.
ŁK: Mhm, bo widzę, że to jest teraz tak our goal is to understand how code quality impacts. I tak, liczbę defektów czas do rozwiązania problemów…
SW: Tak, ale…
ŁK: Przewidywalność rozwiązywania tych bugów no…
SW: Raz mierzą tu oni, mierzą de facto code quality, a nie technical depth. OK, w ramach technical depth-u wchodzi kod quality, ale zmiana tego wcale nie spowoduje, że będzie lepiej. To jest najgorsze taka ignorancja bardzo. Sam kod i “ooo, jakie to jest słabe”.
ŁK: Może to jest… Trzeba byłoby sprawdzić, to napisałby jeszcze zaraz, to wyjdzie, że to reklama tego toola, z którego korzystali.
SW: No właśnie nie wygląda to…
ŁK: Tak, ale jest tam właśnie code signs. Akurat się z tym nie spotkałem.
SW: No ale: jest to ciekawy temat, który chciałem poruszyć, bo mnie po prostu wkurzał.
ŁK: Z poziomu kodu chyba najlepszą rzeczą jak mówimy o długu w poziomie tam gdzieś jakości kodu czy cokolwiek, to jest wstawienie sobie znienawidzonego Sonara czy innego… Statycznej analizy na quality gate’ach, już na początku, patrzenie żeby ten load kognitywny i inne te rzeczy - jak to było? Złożoność cyklomatyczna, tak, bo zawsze zapominam, żeby nie była wysoka na tym kodzie; patrzenie jak już tworzymy to żeby po prostu bullshit nie był commitowany.
SW: Ja powiem tak - jeżeli chcemy w ogóle używać code sonara, to od samego początku nie widziałem chyba sytuacji… Gdzie mam sytuację, gdzie faktycznie sonar włączony w połowie projektu przyniósłby jakąkolwiek wartość. Z reguły to jest frustracja i dostajemy na twarz setki warning’ów, błędów, masakra.
ŁK: Dlatego, że to trzeba zrobić jakoś… Nie. Dlatego trzeba zrobić to od początku, że trzymamy się ustalonego coding guide’u i tyle - i koniec.
SW: OK, bym się zgodził i też też bym zawęził. Niektóre rzeczy naprawdę nie muszą mieć super kodu.
ŁK: A to już dawno do takich wniosków doszliśmy.
SW: Tak, ale żeby to publicznie powiedzieć generalnie, że nie wszystko musi być super. Naprawdę.
ŁK: Inaczej. Czytelny, gówniany kod jest czasami lepszy od pięknych abstrakcji.
SW: Tak, aplikacja, która ładuje plik CSV, jakikolwiek plik do systemu, naprawdę nie musi być podzielona na super abstrakcje. Może to być jeden plik.
ŁK: Jedna klasa. Nikt nie przeżyje.
SW: Jeżeli to ma 200 linii kodu, naprawdę nie musi być podzielone na 20 plików. Nie musi.
ŁK: Dobra.
SW: Co tam, Łukaszu, Ty masz?
ŁK: Ja… Taka klasyka i pytanie, Szymon - czy architekt powinien kodować, bo to jest jedno z ulubionych pytań.
SW: Powiem tak, widziałem… Czy nie… To może kwestia, jaki dzień dzisiaj mamy. Widziałem ten artykuł bo akurat mogłem go zerknąć, i mnie wkurzył jak nie wiem co.
ŁK: Dobra.
SW: Bo to jest bardzo szerokie pojęcie czym jest architekt.
ŁK: Tak właśnie ja chciałem w ogóle zacząć… Może zacznijmy od tego, co spowodowało te pytanie. Jest sobie coś co się nazywa ładnie blog, The Architecture Elevator. Ogólnie ciekawy blog. Autor ma fajne opinie i może dać do myślenia. O tak. I jest znowu tutaj pewnym triggere,. I podszedł na temat właśnie czy architekt musi kodować i stwierdził, że kodowanie? No nie tak, ale debugowanie na pewno.
SW: I to mnie pierwsze wkurzyło, bo to wykonanie wymaga dużo, często więcej wiedzy niż samo kodowanie.
ŁK: Właśnie. I to jest pytanie w ogóle kim jest… Takie wiesz, pytanie być czy nie być, czyli kim jest architekt?
SW: Powiem właśnie więcej wydaje mi się, że używamy słowa architekt tak samo jak chirurg. I to generalnie jest dość szeroka bajka. Neuro- albo generalnie nawet ortopedyczny. Powinniśmy to podzielić na dwie rzeczy: architekt systemowy i architekt aplikacyjny. Aplikacyjny siedzi w jednej aplikacji. Osoba, która zajmie się po prostu kodowaniem. On jak najbardziej powinien kodować. Systemowy, który patrzy coś na governance i nagle ma też bardzo wysoki poziom, pisze dokumenty standaryzujące firmy i tak dalej. Nagle ma zejść na bardzo niski poziom… Generalnie debugowania, wycieku pamięci. Nie ogarniesz tego.
ŁK: Tak, raczej… I powiedzmy sobie wprost czy taki Lead Architect, Enterprise Architect, System Architect, jak go tam sobie nazwiemy? Bo są też sformalizowane nazwy, które są gdzieś tam domenowe czy inne… Na pewno musi mieć jakiś background i rozumieć to… Nie powinien podejmować decyzji. To jest bardzo ważne. Nie powinien podejmować decyzji technologicznych, jeżeli przestał już to czuć.
SW: Zgadzam się.
ŁK: Tylko to jest czuć, a te czuć oznacza, że on nie musi być full time koderem i poświęcać swojego 80% czasu na kodowanie.
SW: Znaczy ja powiem tak, dla mnie właśnie ten taki lead architect, czy tam właśnie solution architect, czy architekt systemowy. To jest osoba, która po prostu powinna wiedzieć, umieć rozmawiać z osobami odpowiedzialnymi za konkretne systemy, ale przede wszystkim on na czym innym się zupełnie skupia. Debugowanie. OK, bo jestem w podobnej sytuacji, jak dalej mam ten workflow mentalny jak debugować i czasami mogę pokazać, ale nie wiem już o każdej klasie, a mówimy o systemach, które mają dziesiątki tysięcy klas. Więc po prostu zanim dojdę… Wejdę w każdy projekt, a wchodzę w niego raz na jakiś czas, to ten narzut inicjalny jest na tyle duży, że ja albo robię to w formie programowania z kimś, żeby powiedzieć - okej, ja potrzebuję znaleźć to, oni mi to znajdują tak naprawdę: i bardziej pokazuję ten proces mentalny. Ale już samodzielne debugowanie wycieków i tak dalej. Sorry, nie ogarniesz tego.
ŁK: Tak, raczej to trzeba popatrzeć na sytuację, jeżeli mamy duże problemy z procesem pomiędzy systemami. Raczej kiedy mamy duże fuckupy, to tak, faktycznie, architekt może wnieść naprawdę dużą wartość.
SW: Ale powiedziałeś coś kluczowego - między systemami.
ŁK: Tak. To, że są sytuacje, tak, jak powiedziałeś, że robisz za gumową kaczuszkę?
SW: Tak, dokładnie. Dokładnie. Dokładnie tak. I wprowadzasz tą wiedzę ogólną tych systemów wspierających, systemów komunikujących, ekosystemów w ogóle, w którym jest uruchomione. Limitów wszystkiego właściwie, których nie ma z reguły developer także jesteś tym przekaźnikiem. Tak.
ŁK: Więc całość to tak, jak ja sobie zawsze podchodzę, że czy architekt musi w ogóle kodować? Jak tu jest zadane pytanie? Jeżeli zajmujesz się tylko architekturą jednego systemu, architekturą aplikacji, to musisz na bieżąco kodować. I sorry, to nie jest odpływ już do bycia PowerPoint Architektem. Jeżeli zajmujesz się infrą… Jeżeli zajmujesz się infrą, nigdy nie pójdziesz jakościowo dalej. Jeżeli trochę nie pokodujesz, nie będziesz miał tej świadomości. Jeżeli ktoś wywodzi się ze ścieżki infrastrukturalnej i chce być dalej architektem, właśnie solution architektem, system architektem, whatever. Musi sobie trochę ubrudzić ręce kodem, żeby mieć… On już nie będzie świetnym programistą, świetnym architektem od samego software’u i to trzeba powiedzieć, ale powinien już złapać ten feeling. O co w ogóle chodzi.
SW: To ja to doprecyzuję - feeling czego, bo to nam wychodzi często w rozmowie. Ten feeling, gdzie to jest sensowniej i taniej zrobić, czy w aplikacji, czy na poziomie platformy infrastruktury tak naprawdę? Bo o to tak naprawdę chodzi, bo ta osoba decyduje, czy standardy pewne implementujemy wykorzystując jakieś pudełko, biorąc jakąś usługę, która to ogarnia np. mesh’a, czy bierzemy generalnie i np. dodajemy mts’a w każdej aplikacji i to jest ta decyzja.
ŁK: I ma np. tą świadomość, że jesteś w stanie dopracować te mechanical sympathy, bo to mi idealnie pasuje do tego, i żeby wiedzieć czy to zajmie np. dwie dniówki czy lepiej poświęcić tydzień i zrobić to na inszej, zapomnieć, bo tam roboty będzie jeszcze nie wiadomo ile. To jest moim zdaniem dobre podejście. Co do później uważam, że jeżeli nie jesteś Enterprise Architektem, który już siedzi totalnie przy Governance, modelu organizacji i innych takich rzeczach, że trzeba tą piłę troszeczkę ostrzyć i nie przesadzajmy. Ale dobrze jest raz na jakiś czas zrobić jakieś POC i wziąć kawałek kodu. Może zafiksować gdzieś sobie buga dla sportu, ale żeby być troszeczkę chociaż ostrzyć to.
SW: Nie wiem czy bug’a, bardziej dropować tool’e wspierające. Tak naprawdę, to jest to sposób, tak jak to bardziej realizuję.
ŁK: Każdy może inaczej, ale chodzi o to, żeby gdzieś brać jakiś żywy kawałek kodu, czy nawet tak jak mówię, ja np. Jestem z tych osób, które najbardziej to są POC, które są potem przekazywane dalej, ktoś już to uprodukcyjnia.
SW: Tak. To jest bardzo stanowcze, zdecydowanie. Jeszcze dorzucę jedną rzecz, bo mówimy, że czasem powinien kodować, tak, powinien. Każdy koduje w innym języku, w innym środowisku. Jak piszesz, generalnie infrastrukturę, kubernetesy i tak dalej. Jeszcze jakieś dokładki do nginx’a które potrzebujesz, bo masz na nim postawionego API Gatewaya. To znowu wchodzenie w niskopoziomowego pythona do modułu machine learningowego, potem C#i jeszcze node’a. Sorry, nie da rady, po prostu nie ma tej opcji. Tak naprawdę. Każdy koduje, jak najbardziej, tylko w innych językach.
ŁK: Chyba że masz 16 godzin na pracę i nie masz życia.
SW: Czyli masz 16 lat generalnie albo 20 lat, coś w tym stylu, ewentualnie udajesz, że wszystko rozumiesz, wszystko robisz, ale potem jakość tego jest taka, jaka potem jest. Więcej fixowania i tworzysz ten wspomniany wcześniej właśnie technical depth.
ŁK: No dobra, to chyba kończymy.
SW: My mamy jeszcze jednego linka, bo jeszcze mam jeden link.
ŁK: Dobra, to dawaj ostatni.
SW: Pierdoła, ale mnie ucieszyła bardzo mocno - znowu z takich rzeczy, które nie wiesz, że potrzebujesz póki się o nich nie dowiesz. Ostatnio miałem dużo do czynienia z Loki. I Grafana wydała… Bo Grafana jest właścicielem Loki, wydała osobny język do querowania trace’ów. I teraz, w jakim kierunku idą - nowa wersja będzie zapisywać dane w parquecie czy systemie do analityki dużych danych. Więc w jakim kierunku to idzie, jeszcze Loki nakłania do tego, żeby w ogóle nie samplować. Tylko ,żeby pisać wszystko, przykładowo Azure Block Storage’a.
ŁK: Wiesz co, to jest ciekawe.
SW: Tak i… więc do czego dochodzimy, mając fajny język do analityki i system plików do analityki Big Data, będziemy mógli robić fajną analitykę na trace’ach i robić z tego takie naprawdę sensowne raporty. Jak raporty robiłem trace’ów lat temu, nie wiem, chyba z 6.
ŁK: To była makabra.
SW: Po prostu wyciąganie wszystkiego do pamięci i przetwarzanie w ten sposób. I to było parsowanie JSON’a, a jak będziemy mieli to są możliwości nagle i wartość z trace’ów w kontekście pilnowania jakości i patrzenia na całą skalę. To mi się mordka uśmiechnęła, bym powiedział.
ŁK: Raczej tak. Dobra, mam tylko jedno pytanie czemu parquet a nie ten date’owy? Jak on się nazywał… Data Lake? Zawsze zapominam.
SW: Delta Lake. Ale faktycznie, faktycznie, potem masz Delta Table.
ŁK: Delta Lake, tak, Delta. Bo to jest Delta Lake.
SW: Delta Lake jest standardem, ale potem faktyczna wartość to pojedyncza tabela, to jest delta table. Jest nadbudówką na parqueta.
ŁK: Ja wiem nie wszystko. Tylko, że, mówię, format prostu… to już taka miłość do bebechów. Czemu akurat ten, a nie inny?
SW: Podejrzewam, że parquet jest bardziej popularny i ludzie z tego kontekstu wychodzą, ale naprawdę ucieszyłem się, więc czekam na Loki w wersji drugiej, bo z użycia… Nawet jak używamy, to ja jestem pod wrażeniem. Naprawdę sensownie jest zrobione.
ŁK: Loki, tak, Loki… Tylko jest… Trzeba się pogodzić, że to nie jest full text search. I to jest bardzo fajne narzędzie. To jest moja opinia na ten temat.
SW: Tak, tak, ale integracja. Wokół tego kierunku poszła Grafana. Zaczynając od prostego dashboarda do budowania takiego fajnego observability, pewnego toola. No, czapki z głów bym powiedział.
ŁK: No dobra, skończmy, bo zaraz wyjdzie, że trzeba zrobić nowy odcinek o observability.
SW: Dobrze, to teraz już kończymy. Na poważnie. Trzymajcie się.
ŁK: Trzymajcie się, na razie. Hej!