Sześć lat temu Patoarchitekci nagrali swój pierwszy odcinek o architekturze vs Agile. Dziś Łukasz i Szymon robią retrospektywę i przyznają się do prawdy: “merytorycznie było ok, jakościowo dramat”. Ale czy ich tezy nadal się bronią? 🎯
Spoiler: architektura ewolucyjna to mit, LLM-y 🤖 nie zastąpią architektów, a DHH ma rację nazywając większość z nas “crud monkeys”. Dlaczego wishful thinking i ludzkie ego rujnują każdy szlachetny plan na keep it simple stupid?
Dowiesz się, czemu vertical slices to nie nowość (pierwsze wpisy z 2018!), dlaczego Agile przetrwał tylko przez ludzkie lenistwo i jak semantic diffusion rozmywa znaczenie pojęć architektonicznych. Plus bonus: jak LLM-y mogą pomóc w dokumentacji, ale jednocześnie zalać nas morzem niepotrzebnych diagramów z emoji.
Czy architektura w ogóle ma jeszcze znaczenie? Łukasz prowokuje: “w większości przypadków można walić architekturę”. Bo główny problem to nie wzorce projektowe, tylko komunikacja i struktura zespołów. ⚠️
Zamiast budować kolejne opus magnum, posłuchaj jak po sześciu latach doświadczenia wyglądają te same tematy. I sprawdź, czy nie czas przestać projektować przyszłość, a zacząć rozwiązywać prawdziwe problemy. 💡
Słuchasz Patoarchitektów dzięki PROTOPII – firmie, w której Łukasz i Szymon działają na co dzień, wspierając zespoły IT na każdym etapie: od projektowania, przez wdrożenia i migracje, aż po optymalizację i zabezpieczenia. Oferujemy też mentoring i szkolenia dostosowane do potrzeb każdej firmy, niezależnie od wielkości. Sprawdź nas: protopia.tech
Discord 👉 https://discord.gg/78zPcEaP22
Linki i ciekawe znaleziska:
#309 – John Carmack: Doom, Quake, VR, AGI, Programming, Video Games, and Rockets
My thoughts on Vertical Slices, CQRS, Semantic Diffusion and other fancy words
#474 – DHH: Future of Programming, AI, Ruby on Rails, Productivity & Parenting
Łukasz Kałużny: Merytorycznie jest ok. Jakościowo jest to dramat.
Szymon Warda: Pozwala na nieprzygotowanie, pozwala na wymyślenie w trakcie.
Łukasz Kałużny: I one prowadzą w różny sposób do tego, że albo przesadzamy, albo budujemy opus magnum.
Szymon Warda: Wydaje mi się, że jest poza możliwościami ludzkimi.
Łukasz Kałużny: Cześć, słuchacie Patoarchitektów. Prowadzą Łukasz Kałużny…
Szymon Warda: I Szymon Warda. Wszystkie linki do odcinka ogarniecie, znajdziecie, Patoarchitekci.io, wygooglacie, wyczatujecie, jakkolwiek nas znajdziecie. Dobrze Łukaszu, to co, wracamy. Po pierwsze, po wakacjach widzę wypoczęty, opalony, wyglądasz jak zwykle świetnie.
Łukasz Kałużny: Ty również.
Szymon Warda: Dziękuję. Dziękuję, dobrze. A już tak totalnie na poważnie, to co będzie dzisiaj? Bo dziś wracamy do odcinka pierwszego po sześciu latach, bo już tyle czasu minęło. I o czym to był odcinek?
Łukasz Kałużny: Architektura versus Agile, czyli 6 lat temu zaczęliśmy tym tematem i dzisiaj zrobimy sobie retro, retrospekcję tego odcinka, można tak powiedzieć. I jak nasze podejście zaktualizowało się albo czy w ogóle się zaktualizowało?
Szymon Warda: Pytanie pierwsze, czy się tego odcinka trochę wstydzisz, czy raczej stwierdzasz, że…
Łukasz Kałużny: Raczej merytorycznie jest ok, jakościowo jest to dramat. O tak, to powiedzmy.
Szymon Warda: Tu zgadzamy się. Zróbmy sobie retrospektywę. Co tam było? Główne punkty.
Łukasz Kałużny: Jeżeli na to popatrzymy, to powiedzieliśmy sobie, że architekturę można robić zwinnie, ale inaczej. Tudzież w tamtym czasie w ogóle, że można ją robić, bo była przecież mocna moda na Agile i architektura była olewana. Powiedzieliśmy, żeby nastawiać się na ewolucję, łatwość zmiany, rozpoczęcia od monolitu, jeżeli nie znamy domeny, szybkie wydawanie i częste, czyli MVP, MLP, opieranie decyzji na danych, a nie założeniach, unikania jak ognia opus magnum i nadmiernego skalowania. Na temat budowania i relacji z biznesem, dokumentowania decyzji, zaakceptowania faktu, że teraz czas życia systemów jest skrócony. Unikanie tworzenia własnych frameworków, uważania na hype, czyli bycia ostrożnym z nowymi wzorcami, technologiami. I ostatnia rzecz, dzielenia duże rzeczy na mniejsze, zarządzalne zmiany, jeżeli na to popatrzymy.
Szymon Warda: Dobrze, brzmi sensownie dla mnie. Jestem pod wrażeniem, to naprawdę fajnie brzmi. Dobra, to zacznijmy od definicji, bo skoro mówimy architektura, to w takim razie czym dla Ciebie jest architektura? Mamy trochę inne definicje, ale do tego samego w miarę.
Łukasz Kałużny: Moja definicja, którą przedstawiam na szkoleniach i jak ja na to patrzę, to dla mnie architektura to jest zbiór decyzji projektowych, które są trudno i/lub drogo odwracalne. To jest taki element, bym to w ten sposób nazwał.
Szymon Warda: To ja na to patrzę inaczej. Dla mnie to jest sposób na podział bałaganu, pierdolnika, który będzie finalnie w każdym systemie, na potencjalnie mniejsze lub łatwiej zarządzalne elementy. Żeby wyznaczyć jakieś granice twarde lub trudniejsze do przekroczenia.
Łukasz Kałużny: Wiesz co, jedna rzecz mi się ostatnio rzuciła, bo było gdzieś, dyskutowałem sobie na Discordzie z Tomkiem Ducinem i było dla mnie takie: dobra, to czym jest ta architektura frontendu? I jak popatrzymy, to Tomek bardzo trafnie podsumowuje - frontend daje w nawias. Czyli jego wpis dobrze pokazuje, że to nie są tak jak ja na to patrzę, że to są decyzje i drivery. Podsumowując to jednym jego tweetem, który jest dobry akurat od strony frontendu: struktura folderów to nie jest architektura i nigdy nie była.
Szymon Warda: Wiesz co, mam wrażenie to może kogoś urazić, ale architektura frontendu to jest po prostu, który framework wybraliśmy tak naprawdę.
Łukasz Kałużny: Właśnie, tak, a Tomek się z tym rozprawia, że framework to jest jakaś pomniejsza decyzja i od tego są drivery i inne założenia.
Szymon Warda: Dobra, to teraz mamy drugą definicję tak naprawdę, drugiego checka, którego musimy zrobić.
Łukasz Kałużny: To właśnie ja chciałem Ci, jak to definiujemy Agile. Ale czy mamy Agile? On ciągle jest Szymon. Jeżeli chodzi o metodyki podejścia do tego jakieś formalne, to wszyscy już tym wymiotują, nie mówiąc, że rzygają podejściami typu Scrum jest zły, nie działa i inne tego typu elementy, jeżeli popatrzymy. Nie mówiąc już o pomysłach typu Scaled Agile Framework i innych tego typu wymiotach firm konsultingowych. Ale go ciągle mamy i to dobrze zdefiniowałeś, jak rozmawialiśmy przygotowując się do tego odcinka.
Szymon Warda: Tak, moja definicja jest taka, czy definicja, spostrzeżenie jest takie, że mamy Agile, ciężko już nazwać Agile’em dlatego, że jesteśmy leniwi. Bo powrót do wszystkich waterfalli i innych takich metodyk bardziej ustrukturyzowanych, bo tak to trzeba nazwać, jeżeli więcej robimy z przodu, wymaga dużo więcej pracy. Agile pozwala na bałagan, pozwala na nieprzygotowanie, pozwala na wymyślenie w trakcie. I to nie tyczy się tylko IT, też biznesu, w ogóle całości organizacji, podejścia “jakoś będzie”.
Łukasz Kałużny: Ja dorzucę dwa takie elementy. To są takie ciekawostki, które zawsze ludziom pokazuję, że te twarde metodyki, które nazywamy waterfallem, Prince, jeżeli popatrzymy, one w sercu były zwinne, one mówiły o iteracyjności, dostosowywaniu się. Więc jeżeli byśmy robili je podręcznikowo, to tam dużo elementów tej zwinności się nadal znajduje. A najbardziej zabawną rzeczą jest, że planowanie w samym, jak popatrzymy sobie na ludzi, którzy tworzyli Agile Manifesto, oni nigdy nie mówili na temat, że trzeba porzucić planowanie, analizę i inne tego typu elementy. Tylko mówili o szybkiej iteracyjnej współpracy, żeby jak najszybciej pokazywać efekty.
Szymon Warda: Ja bym nawet dorzucił większy nacisk, na co powiedziałeś, oni mówili o współpracy tak naprawdę, że to nie jest, że widłami rzucamy z lewa na prawo, tylko jest współpraca i obydwie strony, czy nawet wszystkie strony siadają przy stole i mówią jak to będzie wyglądało. Trochę taki mix tego, co mamy teraz w różnych event stormingach i tak dalej, że znowu siadamy i znowu okazuje się, że nam fajne rzeczy wychodzą, a całego Agila obudowaliśmy w różne procesy, które nam teraz trochę przeszkadzają i planningi 5 godzin.
Łukasz Kałużny: Dobra, słuchaj, ale jak teraz popatrzysz sobie przez te spostrzeżenia po całościowo, po tym co nagraliśmy, ja się jak szykowałem sobie ten spis tego, co znajdowało się w tym odcinku, z większością rzeczy po dziś dzień nie kłócę się i nawet zgadzam. Byłem zdziwiony po sześciu latach, że mi się to aż tak bardzo nie odwróciło w tym miejscu.
Szymon Warda: To była moja taka sama refleksja, że mówię tak: naprawdę dobre.
Łukasz Kałużny: Teraz wiesz co, poszedłbym do jednej rzeczy, z którą mam teraz już problem, w którą kiedyś wierzyłem, teraz już nie wierzę, czyli architektura ewolucyjna.
Szymon Warda: Ja w nią dalej wierzę jako ideał, ale mam świadomość tego, że jest to nierabialne. Czemu? Przez ludzkie ego. Mówimy o architekturze ewolucyjnej. Powstrzymanie się, żebyśmy nie uogólniali, nie tworzyli generyków, nie projektowali przyszłość i takie keep it simple stupid, wydaje mi się, że jest poza możliwościami ludzkimi.
Łukasz Kałużny: Czy wiesz co i teraz tutaj bym wjechał w taki temat, który ja sobie też zapisałem. Jedna rzecz, która chyba mi się bardziej wyostrzyła, taka właśnie też powiedziałeś o keep it simple stupid, bo jest to dla mnie istotne, tak jak patrzę. To jest to, że giniemy, ja sobie to tak zanotowałem, że giniemy przez założenia i wishful thinking. I one prowadzą w różny sposób do tego, że albo przesadzamy, albo budujemy opus magnum, albo robimy przepiękne, nie będziesz tego potrzebował, ale ja uważam, że jednak będę potrzebował, więc musimy to tak zrobić i przygotować się na przyszłość.
Szymon Warda: Bo to jest takie, że Ty nie będziesz tego potrzebował, ale tego, co ja piszę, to będziemy potrzebowali, bo tak to często wygląda. Wiesz co, jeszcze kolejny problem z architekturą ewolucyjną jest to, że wszyscy rozumiemy, o co w niej chodzi. Jak wyszukałem definicję w, ChatGPT zaczął mówić o [niesłyszalne 00:09:29], zgadzałoby się, ciągła iteracja, zgadzałoby się. Architektura modułowa i mikroserwisy, tak niekoniecznie bym powiedział. Feedback loops i ADR i IaC. To nie są elementy w ogóle rewolucyjne, podejścia i wymagania. Więc problem jest taki, że każdy to czuje. Nie mamy jawnych kryteriów, więc to się nie udaje tak naprawdę. Bywa.
Łukasz Kałużny: Raczej tak, ale mit jest, że ewoluuje. Chyba… Inaczej, to tak jak odwieczne refactoringi.
Szymon Warda: To jest ten drugi element, że nawet jak zaczniemy od keep it simple stupid i podejdziemy do tego, że zróbmy proste, a potem poprawmy jeżeli potrzebujemy, to będziemy poprawiali w kółko. I te refactoringi wbrew temu, może się wiele osób obrazić, ale status kodu po refactoringu wcale nie zawsze jest lepszy niż ten przed refactoringiem, bym powiedział. To chyba każdy, kto robi coś większego zdaje sobie z tego sprawę, że refaktoringi często się nie kończą, albo to po prostu się nie udaje.
Łukasz Kałużny: Ja bym jeszcze rzucił właśnie na temat tego wishful thinking, na temat danych do skali, bo wszyscy chcielibyśmy budować nie wiadomo jak duże systemy. I w trakcie wakacji wyszedł podcast Lexa Fridmana, którego nienawidzę słuchać, z osobą przeopiniowaną, czyli DHH, twórcą Ruby on Rails, ale był dobry. W sensie ciężki do słuchania, ale było tam dużo ciekawego contentu do przemyślenia.
Szymon Warda: Ustalmy, jak na podcast Lexa, to nie był trudny, bo tam Lex się mało odzywał. Głównie DHH [niesłyszalne 00:11:15] trudne, jak Lex zaczyna robić filozofię.
Łukasz Kałużny: Były takie fragmenty i nie można było ich zeskipować. To było najgorsze. Ale…
Szymon Warda: Jedna rzecz, bardzo fajny odcinek był z Carmackiem między innymi też długi, chyba z 5-godzinny w ogóle, też bardzo dobry, ale odcinek z DHH był naprawdę dobry.
Łukasz Kałużny: Tak, i tutaj on rzucił coś takiego, ja sobie to przetłumaczyłem: wielu programistów jest niekomfortowych z faktem, że są zasadniczo crud monkeys. Tworzą systemy, które głównie służą do create, read, update, delete w bazie danych i muszą zrekompensować ten egzystencjalny strach przez nadmierne komplikowanie rzeczy.
Szymon Warda: To jest fajny cytat z DHH, bo pokazuje i on to zresztą nawet mówi, że on jest zamknięty w pewnym środowisku. Ogólnie rzecz biorąc w 90% przypadków on ma rację, to są crud monkeys, aż do momentu, jak wejdziesz i trafisz na duży system, który ma skomplikowaną logikę i zaczniesz od cruda i potem nagle jesteś, masz nazwijmy to bałagan po prostu, bo nagle twoje tabele wyciekły do twojej logiki biznesowej i to wszystko zaczyna się sypać. I wtedy już nie masz odwrotu, bo tego jest za dużo. I to jest znowu taki akt balansowania. Nigdy nie wiesz, albo ciężko jest stwierdzić, który element twojej logiki urośnie tak bardzo, że to już nie jest crud. Crud po prostu opiera się na bardzo dużej ilości tabel, danych i klas. Wracam do tego, co mówiliśmy przed odcinkiem, że najważniejsze jest co? Modelowanie danych, jak te dane będą wyglądały jak będą zapisywane.
Łukasz Kałużny: Raczej tak, żeby nie budować spaghetti na modelu danych, nie budować spaghetti i mieć ten ownership danych. I jak teraz, to trochę płynnie wchodzimy w coś, co też tam poleciało, czyli było, że: rozpocznij od monolitu. I to jest rzecz, która… Inaczej, już teraz tak, było: rozpocznij od mikroserwisów. Teraz było: rozpocznij od modularnego monolitu i na to też się już wylewa hejt. I rzecz, którą chyba wtedy podkreśliliśmy, to jest problem znajomości domeny.
Szymon Warda: Który istnieje zawsze.
Łukasz Kałużny: Tak, jak nie znamy, zacznij od monolitu i dowiesz się co Ci wyjdzie. Upilnuj tego modelu danych.
Szymon Warda: Ja bym się z tym ogólnie rzecz biorąc zgodził, bo trzeba od czegoś niewielkiego. Jeżeli zaczniemy od ustawienia struktury katalogów, plików, projektów, połączeń, infrastruktury, kafek i tak dalej i to nam zajmie tydzień, to sorry, ale to nie jest dobry kierunek. To, z czym się zgadzamy chyba obydwaj, że tu nam potencjalnie pomagać mogą w tym podziale tego bałaganu, który się finalnie wydarzy, to są vertical slice’y. Czy one są czymś nowym? Absolutnie nie są.
Łukasz Kałużny: Są…
Szymon Warda: Nie.
Łukasz Kałużny: Kolejny raz opisane, jeżeli popatrzymy w tym. W ogóle ja sobie, tak jak szukałem vertical slice’y, jak popatrzymy jeden z wpisów, który, jeżeli zgoogle’amy, to słuchaj, jest rok przed pierwszym oryginalnym nagraniem poprzedniego tego odcinka o architekturze.
Szymon Warda: O!
Łukasz Kałużny: Tak, jak sobie tam wrzucisz vertical slice architecture, no to wpis wylatuje z 2018 roku, więc one nie są, jak teraz popatrzymy… Odnosząc się, Oskar też jakiś czas temu napisał właśnie na temat, on dobrze się odnosi do architektury, ten wpis, też są vertical slice’y. Ale właśnie jak popatrzymy, to Oskar wrzucił takie pojęcie semantic diffusion, czyli rozmywanie się znaczenia jakiegoś pojęcia, jeżeli popatrzymy, które było dobrze zdefiniowane, a potem rozmywa się.
Szymon Warda: Cała seria właśnie wpisów, właśnie o tym, jest bardzo, bardzo dobra. Fajnie to opisuje, że to wynika z tego czasami niezrozumienie, czasami podciąganie, czasami dostawcy różnych usług rozmywają to. Dzieje się dużo i powodów jest naprawdę, naprawdę sporawo. Wpis jak najbardziej polecamy, dobry jest. Dobrze Łukaszu, ale pewna rewolucja nastąpiła. Weszły nam LLM-y i. Co nam LLM-y i AI ładnie namieszał? Tu się trochę różnimy, wydaje mi się.
Łukasz Kałużny: Dobra, pierwsza rzecz w tym, LLM nie zrobi za nas architektury i tutaj mamy zgodność pod tym względem.
Szymon Warda: Nie wyvipecode’ujesz tego?
Łukasz Kałużny: Wiesz co, vibe coding… Poprosiłem teraz tak z ciekawości, uawaga… Nie, jak wiesz co chcesz zrobić, to świetnie pomaga, a w szczególności jak chcesz zbootstrapować szybko, pokazać elementy, przepiękne. Jak chcesz potem to utrzymać, to jest nadal dobry junior i na tym się kończy. Przykład z rzeczy, które potrzebowałem i to będzie zejście nie architektura, tylko na architekturę kodu, czyli niżej, nałożenie tego. I poprosiłem o, potrzebowałem, żeby mi wygenerował jakiś tam kod w Pythonie, który będzie łatwy do testowania. To zobaczyłem heksagonalną architekturę napisaną w Pythonie. Zobaczyłem kod .Netowy, taki, z którego się naśmiewamy, w Pythonie. I tutaj jak sobie popatrzymy, dlatego architektura vs taki vibe coding, nie, to pojęcie nie istnieje w żaden sposób.
Szymon Warda: Można fajnie wyvibecode’ować diagramy. Fajnie. Znaczy to co powiedziałeś, łatwo użyć LLM-ów wszelkiej maści do lepszej komunikacji. Diagramy, koszt takich rzeczy nagle poleciał dramatycznie w dół, stworzenie diagramów, stworzenie ADR-ów, stworzenie takich rzeczy, które są dookoła.
Łukasz Kałużny: Raczej Szymon, to powiem Ci tak, z tego, co z mojej perspektywy, jeżeli chodzi o LLM-y, jeżeli chodzi o vibe coding versus architektura, wyrzućmy to, nie ma sensu. Jeżeli traktujesz go jako pomoc, sparingpartnera, czyli LLM-a jako architekta traktujemy jako sparring partnera, jako sekretarkę, deep researche na przykład też mają sens. O tak, deep researche mają duży sens i to, żeby poszukać technologii, alternatyw, podejść mają sens, jest spoko. I potem to, co dostarczamy, mieliśmy tak jak jesteśmy, tu też się nam nie zmieniło, dokumentuj decyzje, nie wszystko. Mieliśmy taki punkt w oryginalnym podejściu, czyli właśnie skupić się na ADR-ach, prostym markdownie i to się idealnie spina z LLM-ami, jak popatrzymy sobie i z pomocą. I to dla mnie, z jednej strony, zabija próg wejścia tej czystej strony, którą mam szablon, od czego mam zacząć. Czyli mogę sobie pomóc i deep researchem albo wrzucić pytania. Druga rzecz, którą ja teraz już polecam, to jest przy dokumentach na przykład stworzenie sobie, o tym też mówiliśmy tam kilka odcinków temu, na temat vibe codingu, przygotowanie sobie na przykład promptu, który nam usystematyzuje kawałek dokumentu, na przykład takiego ADR-a. Czyli w szablonie trzymać pomocnicze prompty, które na przykład przerobią nam na język prostszy, poprawią go gramatycznie, stylistycznie, ujednolicą formę. Czyli taka pomoc nam. One tego nie zrobią za nas. Ale jeżeli zrobisz tak, jak ja tam zrzucam siebie, swój dump myśli, który mam gdzieś tam w code’zie czy gdzieś zapisany i wrzucam, żeby mi to ładnie przeformatował, przerobił. Naprawdę ta bariera na zasadzie brain dump z notatek ustrukturyzowany pi razy drzwi, co chcę osiągnąć, to próg wejścia i dostarczenia jest naprawdę przycięty i to mocno.
Szymon Warda: Problem z progiem wejścia, że nagle tych dokumentów generujemy od groma. I co więcej, teraz jest problem, który ja osobiście widzę, to jest to, że LLM-y domyślnie generują dokumenty, częściowo dlatego, że one po prostu potrzebują ich później, żeby potem ogarnąć się w tym, co zastały tak naprawdę i żeby zrozumieć czym jest ta baza kodu. Ale ilość dokumentacji, które LLM-y generują jest przytłaczająca i one po prostu mogą się w tym same pogubić. To jest dla mnie duży problem. Kolejna rzecz to jest to, że obniżył się próg wejścia. Fajnie, tylko LLM-y znowu produkują masę tego i nie zawsze tam gdzie powinny. Mamy takie podejście, że ok, jest dokument, to wrzućmy go do repo. Pierwsze…
Łukasz Kałużny: No nie…
Szymon Warda: Krótko i treściwie. Po drugie, to ma być tam, gdzie potrzeba. I trzeba wprowadzić w organizacji, w zespole pilnowania się, żeby nie było tego za dużo, bo utoniemy z tą ilością problemów.
Łukasz Kałużny: Ale inaczej, tak jak ze strony: nie chcemy pisać dokumentu, wygeneruję dokument, przeszliśmy w drugi tryb, w niektórych miejscach.
Szymon Warda: Najlepiej długi, kwiecisty i z komentarzami, przykładami, emotikonami i wszystkim absolutnie i bardzo ładnie wygląda. Wartość? Ujemna, to jest koszt.
Łukasz Kałużny: Wróciłbym do odcinka do ADR-ów i tam o tym mówimy: prostota, nie za dużo, tak żeby nie odstraszało, bo ktoś zaraz zapyta się kolejnego LLM-a, weźmie ten dokument i poprosi o jego streszczenie.
Szymon Warda: Ale przecież nie będzie absolutnie inaczej. To powinno być, załóżmy taki ADR maksymalnie strona, żeby to się mieściło na ekranie.
Łukasz Kałużny: Tak.
Szymon Warda: Chyba że mamy coś super skomplikowanego.
Łukasz Kałużny: Z jednej rzeczy słuchaj, którą bym wrzucił, którą się łatwo generuje, jest ona przydatna, tylko nie przesadzamy, to są diagramy, na przykład w Plant UML, Mermaid, JS-ie, razem z tym, tak jak zresztą powtarzamy, żeby trzymać to as code, te diagramy takie podstawowe. I to łatwo teraz wygenerować. Jedną z rzeczy, którą kocham od tej strony, to są diagramy typu use case, które do rysowania zawsze były, utrzymywania, zawsze były problematyczne. I tutaj można oczywiście znowu kopiąc i będąc poganiaczem niewolników, jeżeli chodzi o tego LLM-a, tudzież korygując juniora, da się w miarę prosto te diagramy generować i utrzymywać potem.
Szymon Warda: Ja znowu mam problemy z tym, że jak można prosto… Generowanie tak, można prosto. Teraz problem będzie taki, że wygenerujemy je, ale potem każdy taki diagram to jest dodatkowy koszt utrzymania. Więc musi być bardzo jasne kryterium odcięcia, na jak niski próg zejdziemy. Bo wiemy o tym, że niejedna osoba stwierdzi, że będzie fajnie mieć diagram i zrobi: wygeneruj mi diagram na bazie kodu tudzież modułów klas. I to pójdzie do repo.
Łukasz Kałużny: Właśnie, nie powinno pójść do repo. Inaczej, dlatego mówię, że jeżeli robimy tak, robimy jakąś specyfikację, chcemy opisać proces biznesowy, który będziemy na przykład implementowali, czyli wyjdźmy z tego stanu: chcemy opisać zmianę, jak będzie wyglądała. Świetnie w takim opisie, specce warto dorzucić na przykład lepiej niż robić tekst, też to zwizualizować. Proces jak przejdzie przez moduły inne rzeczy, zwizualizować sobie ten use case. Dlatego o tym mówię. Czy wykorzystać swimlane’a do przejścia pomiędzy mikroserwisami i pokazać na swimlane’ach jak to działa, warstwy. Ale też nie ma sensu wrzucać wszystkiego. To z jednym z takich rzeczy, teraz jak robię reverse engineering, gdzieś wsiadam, to nie scommit’uję tego do repo, ale na przykład lubię wrzucić i kazać, że tu mam wejście na przykład, mam taki endpoint i rozpisz mi po systemie całe przejście po kolei - plik, funkcja, jakie przechodzi, żeby zobaczyć całe przejście przez system, przez pierdolnik, który jest i gdzie się łączy. Ale ja tego nie scommit’uję potem, to jest analiza dla mnie, żeby szybciej się rozeznać.
Szymon Warda: Bo to jest ważne. To nie powinno być tak, że diagramy powstają na bazie kodu tego co jest. Tylko diagram to jest to, jak to powinno być. I ta różnica między tym jak jest, a tym jak powinno być, to jest z reguły tam, gdzie błędy żyją najczęściej. Czyli faktycznie to jest ważne i żeby to wybrzmiało, LLM-y umożliwiają łatwiejsze tworzenie diagramów, bo nie trzeba tego pisać łatwiej, po prostu się robi językiem naturalnym. Ale dalej wejściem do tego powinna być nasza wiedza, a nie to co mamy w kodzie.
Łukasz Kałużny: Albo z drugiej strony to co LLM nam zaproponuje, to jest jeszcze gorsze. To jest najgorsza opcja.
Szymon Warda: Bo przecież klikamy enter, enter, enter i commit tylko, to jest wiesz. Dobrze. Trochę się napastwiliśmy. LLM-y dużo ułatwiają, jak najbardziej. Wersja, podsumować, ułatwiają, to ma być krótko. Diagramy i ta część wizualna nagle staje się dużo łatwiejsza, dużo tańsza w utrzymaniu, nie wolno z tym przesadzić, według mnie, to są takie podstawowe rzeczy.
Łukasz Kałużny: Zachłyśnięcie się będzie, wygenerowanie… Tak jak powiedziałeś, wygenerowanie pięknego dokumentu z emoji i trzeba potem to bardzo mocno przycinać, albo najlepiej zastanowić się trzy razy, czy ja chcę to scommit’ować do repo.
Szymon Warda: Mówimy prosto, warstwa pierwsza i druga w C4, to wystarczy. Dalej niekoniecznie bym powiedział, [niesłyszalne 00:24:55], ale już nie commit’ujmy.
Łukasz Kałużny: I potem proces biznesowy.
Szymon Warda: Dobra, to teraz pytanie najważniejsze. Czy to wszystko jeszcze ma znaczenie? Ta architektura, całe przygotowanie i tak dalej, i tak dalej.
Łukasz Kałużny: Czy wiesz co, ja bym podszedł inaczej. Zastanawiam się, w większości przypadków powiedziałbym, że walić architekturę. Bo w jaki sposób podejdziemy do rozwiązania problemu? W większości przypadków z naszej Szymon praktyki, zauważ, że ze wszystkich Dora, z projektów, które mamy, w ogóle problem nie jest architektura. Tak jak możemy ponarzekać, że problemem nie jest architektura, jak popatrzy. Ona jest zwalona, tak. Czy architektura jest zwalona w wielu projektach? Tak, jest zwalona. Czy jest to główny problem? Głównym problemem jest komunikacja z założenia, struktura operacyjna zespołów i sposób współpracy. I to są większe problemy niż to, czy zrobiliśmy dobrze architekturę.
Szymon Warda: Architektura, patrząc na wykresie czasu powiedzmy, ona będzie coraz większym problemem razem z czasem, ale tego nie unikniemy. To jest, po prostu funkcja będzie rosła mniej albo bardziej szybko tak naprawdę. Co nie wycommit’ujemy, za 10 lat i tak będzie ciężkie w utrzymaniu. I tak będzie bałaganem, bo każdy system używany zamieni się w bałagan po jakimś czasie. Tak to wygląda. Ja też jestem tego zdania, że za bardzo skupiamy się na pierdołach. I to jest fajny, [niesłyszalne 00:26:35] jak najbardziej, to jest to, że wybierzmy obszary, gdzie architektura ma znaczenie. Takie, gdzie faktycznie dostarczamy tą różnicę biznesową, a nie skupiajmy się na pierdołowatych obszarach, które nie są wcale konkurencyjne, które nie są wcale ważne i tam będziemy robili sobie mikroserwisy i tak dalej. Nie ma to sensu, po prostu.
Łukasz Kałużny: Jedna rzecz jeszcze z takich gdzieś tam dyskusji prowadzonych w ostatnim czasie, to znajomy taki Norbert, zostawię go w tym, on fajnie powiedział, że trzeba się zastanowić nad elementami, które faktycznie mogą nam wybuchnąć w twarz. To tak zrzucając całą dyskusję, która gdzieś tam była, że faktycznie. I to jest dobre spostrzeżenie, że trzeba przypilnować coś, co może nam wybuchnąć w twarz. Tylko teraz wracamy znowu do analizy potencjalnego ryzyka, określenia prawdopodobieństwa, czy to nam na pewno wybuchnie w twarz. Wtedy można się nad tym pochylić, problemem, czy może wybuchnie w twarz?
Szymon Warda: Ja bym dorzucił funkcję kosztu. Czy wybuchnie nam w twarz? To czy będziemy mogli zasypać to łopatą pieniędzy, czy jednak nie będzie? Bo jak będziemy mogli, to kupujemy sobie czas i jakoś to będzie.
Łukasz Kałużny: Albo czy w ogóle będzie się opłacało to zasypywać.
Szymon Warda: Tak. Dobra, no to w sumie co?
Łukasz Kałużny: Kończymy.
Szymon Warda: Tak. Dajcie znać jak tam podchodzicie do tego odcinka, tak, komentarze, Discordy i inne rzeczy, maile zawsze miło słyszeć, miło widzieć. Jeszcze nie żegnamy, tak że jestem też ciekawy jak Wy patrzycie na to, odcinek ten sprzed 6 lat i ten teraz. No, tyle. Pa pa.
Łukasz Kałużny: Trzymajcie się, na razie.