Patoarchitekci Short #34: Znów rzucamy mięsem. Dzisiaj wracamy na chwilę do raportu McKinsey’a i tematu badania skuteczności developerów. Wszystko za sprawą artykułu Orosza i jego komentarza do raportu. Porozmawiamy też o Oskarze Dudyczu i jego newsletterze na temat prototypowania biznesowego - raczej o wpisie Oskara, który popełnił w ramach jednego ze swoich newsletterów. Na koniec trochę o testach end-to-end. Kiedy, jak, gdzie, po co? I dlaczego część z nich warto szybko kasować? Zaczynamy?
Słuchasz Patoarchitektów dzięki Protopii. Sprawdź, jak Patoarchitekci i Protopia mogą Ci pomóc ➡️ protopia.tech
Linki i ciekawe znaleziska:
Łukasz Kałużny: Cześć, słuchacie Patoarchitektów. Prowadzą - Łukasz Kałużny.
Szymon Warda: I Szymon Warda. Wszystkie linki do tego odcinka znajdziecie na patoarchitekci.io lub gdzieś w opisie. Dacie sobie radę, wierzymy w was.
Łukasz Kałużny: I zgodnie z nową świecką tradycją, w zależności gdzie oglądacie, prosimy o łapkę w górę, reakcję, lajka czy subskrypcję. Dobra Szymonie.
Szymon Warda: Kontynuacja wielkiej dramy.
Łukasz Kałużny: Właśnie, co dzisiaj?
Szymon Warda: Dzisiaj dalej internet trochę wrze w temacie McKinseya. Ja tu wystąpię trochę jako adwokat diabła, bo wydaje mi się, że trochę przeginamy. Mianowicie Pragmatic Engineer, którego generalnie chwalimy, dobry blog, dobry newsletter. Wydaje mi się, że idziemy trochę w zaparte na zasadzie, że nie potrzebujemy w ogóle metryk, wszystko jest w porządku. Weźcie się od nas odczepcie, ale znowu…
Szymon Warda: Orosz, który prowadzi Pragmatic Engineer pisał, że jest potrzeba. Nie uciekniemy od tego, żeby się jakoś w IT nie rozliczać. I Orosz daje ciekawy przykład i trochę wydaje mi się, że sam się podkłada pod tą sytuację, bo daje przykład rekrutera, który rekrutował developerów i miał super metryki i w ogóle wszyscy przyjmowali jego oferty, wszystko było super. Tylko okazało się, że w jakiś czas po jego odejściu spłynęły tam po 3 miesiącach, czy po pół roku od jego odejścia, spłynęły oceny pracownicze. I okazało się generalnie, że czemu miał takie fajne metryki? Dlatego, że wszyscy przyjmowali jego oferty, bo on obiecywał to, że będą bonusy razy 10. Czyli po prostu oszukiwał. I Orosz podaje to jako przykład tego, że metryki są złe, że nie możemy mierzyć tylko na bazie metryk, outcome’ów, jak on to ładnie nazywa, czyli wyników jakości pracy.
Szymon Warda: Ale to jest przykład gdzie jest źle zdefiniowana metryka. Po prostu metryka powinna być zdefiniowana nie na bazie jednej wartości, czyli czy udało mu się, tylko na bazie dwóch metryk. Jest metryka i kontrmetryka, czyli czy udało mu się? To jest jedna metryka, która optymalizuje w jednym kierunku. A druga to jest to, że sprawdzamy tą metrykę po jakimś czasie, czyli czy my jesteśmy zadowoleni z kandydata, czy kandydat jest zadowolony z nas po jakimś czasie. I dopiero jak te dwie metryki połączymy ze sobą to dają nam jakiś w miarę sensowny wynik i też opóźniamy tą metrykę. To jest przykład złego czasu mierzenia metryki, zbyt wczesnego i nie posiadania kontrmetryki.
Łukasz Kałużny: Czy wiesz co… Przykład Jest akurat moim zdaniem też trochę naciągany, bo wiesz, patrząc się na całość to bardziej jest, że przyjął kandydata. Metryka jest, nie ma nic wspólnego z developer productivity, taki dałem tutaj przykład. Fakt, że dobrze obrazuje problem jednej metryki, o tak.
Szymon Warda: Tak, on pokazuje problem metryki. Wydaje mi się właśnie, że tego patrzenia tylko że mamy tylko jedną metrykę. Znowu ja jeszcze powiem jedną, bardzo ważną rzecz, którą wydaje mi się, że omijamy tutaj - niemierzenie wyników pracy, niemierzenie ludzi przez metryki czy przez outcome’y, aktualizowane są przez wyniki ich pracy, to ma swoją nazwę, to jest mikrozarządzanie generalnie. Jeżeli mam zespół to im przekazuję to jak oni będą komentowali, daję metryki, jakieś KPI, cokolwiek odnośnie wydajności, jakości itd. Ale nie wchodzę im w ten kod bardzo głęboko. Jak ktoś mnie wkurzy to mogę iść i z nim porozmawiam, ale nie możemy, a szczególnie przy większych zespołach bardzo, bardzo, bardzo wchodzić w detale. Od tego mamy ludzi, od tego mamy całe struktury. Na poziomie całej organizacji mierzymy na podstawie outcome’ów, bo tylko to możemy mieć, tak naprawdę.
Łukasz Kałużny: Wiesz co, jedna rzecz, która mnie trochę w tym wpisie, właśnie w tej drugiej części tego wpisu kontynuacji to było też, że on de facto też poleciał na jednej metryce, jak pokazał swój przykład tam tabelki z impact właśnie, złapaniem impactu.
Szymon Warda: Business Impact, system performance i developer effectivness, te trzy metryki.
Łukasz Kałużny: Tak, a on pokazał tutaj właśnie ten capturing the impact of engineering, gdzie de facto mierzył jedną metrykę, która jest niemierzalna, czyli impact de facto na koniec dnia.
Szymon Warda: Zgadza się, ale zapomniałem o jeszcze jednej rzeczy i Orosz o tym też zapomniał, że po co mamy metryki? Metryki mamy po to, żeby uzyskać, na słowo ładnie angielskie tu pasuje, alignment takie uwspólnienie całej organizacji, że teraz optymalizujemy się na wzrost, więc cele, które robimy, robimy w kontekście tej metryki, żeby ją zmaksymalizować. I to jest potęga metryk. To jest potęga mierzenia na podstawie outcome’ów właśnie, że patrzymy, nie wchodzimy w najmniejszy detal, kto, jak, co pracuje, tylko patrzymy czy jesteśmy, w tym samym kierunku idziemy. I to jest potęga mierzenia na outcome’y właśnie, na wyniki pracy.
Szymon Warda: I znowu Orosz jeździ po McKinsey’u, że McKinsey patrzy pod kątem developer productivity, ale źle czyta, bo McKinsey tu miał rację jak najbardziej, bo częściowo to jest z Valve, jak mówiliśmy w poprzednim odcinku, że McKinsey mówi, żeby mierzyć productivity na poziomie systemowym, zespołowym i indywidualnym. Jeżeli Orosz tam jeździ, że wydajność jest dużo ważniejsza na poziomie zespołowym. Tak, ale McKinsey też to robi. Trzeba te trzy obszary mierzyć. Mamy różne wymiary pracy i mamy różne wymiary tego, jak ludzie współpracują, gdzie wartość dają, tak naprawdę.
Szymon Warda: Wiadomo, że team lead będzie bardziej na poziomie zespołowym, będzie bardziej na poziomie kooperacji mierzył, a nie na poziomie kodowania tak naprawdę.
Łukasz Kałużny: Wracając dla mnie z McKinseya zgodzę się, że trzeba mierzyć, to uderza na pewno, bo nigdy nie było pomiędzy zarządzającymi IT jasnych metryk pod takimi rzeczami, w szczególności w części wytwarzania oprogramowania, bo w części OPS-owej jest trochę… Mówisz o de facto jakości, o kosztach. To jest trochę, i onboardingach, sprowadza się to trochę do, nazwijmy to, do łatwiej rozumianych metryk. Można powiedzieć, że ilość fuck-upów na miesiąc jest też dobrą metryką dla OPS-ów. A w przypadku developerki trzeba mierzyć. Dużej części osób się to nie podoba. Tylko jest jedna rzecz, którą tak jak to założyliśmy we wcześniejszym odcinku, że McKinsey stara się spychać tylko do kodowania, że bycie developerem to tylko kodowanie i dla mnie to jest największa wina tego raportu.
Szymon Warda: Zgadza się, ale i tu będę bronił, że mimo że ten kawałek o kodowaniu jest absurdalnie debilny, bo tak to trzeba nazwać, ale mają tam fragmenty tego artykułu, które nie są głupie, które są naprawdę sensowne. Więc nie jedźmy po nim i nie negujemy go w całości, bo jest tam parę obszarów, które mają ręce i nogi tam gdzie powinny mieć te ręce i nogi. No nie?
Szymon Warda: A ja powiem jeszcze jedną rzecz odnośnie tego co mówi Orosz. To, co już Ty wspominałeś, że mierzy business impact, system performance i developer effectivness. Realnie tak naprawdę to na koniec dnia interesuje nas business impact. To jest cholernie trudne w mierzeniu, otwiera wielką bramę na spychologię, która będzie w każdej organizacji istniała, bo w każdej organizacji będzie polityka i tak dalej. Możemy tego nie lubić, ale taka jest prawda. Ale realnie, chodzi tylko o ten business impact. Więc kwestia jest wypracowania dobrej współpracy i mierzenia de facto na koniec business impact. Bo jeżeli nawet jest spychologia, to co byśmy nie mierzyli, co byśmy nie robili, to to jest problem organizacyjny organizacji, jeżeli ta organizacja nie będzie wydajna, bo ludzie ze sobą walczą po prostu. Ale na koniec dnia firmy optymalizują zysk.
Szymon Warda: Business Impact mierzy zysk i jego potencjalny wzrost. Więc ja bym po prostu olał wszystkie pozostałe. Ta metryka zawiera wszystkie inne. Brutalne, ale prawdziwe. Dobrze. Ty Łukaszu, Ty też masz jeden temat do omówienia większy.
Łukasz Kałużny: Większy? Tak. Oskar, którego gościliśmy swego czasu, Oskar Dudycz, wrzucił w swoim mailingu taką dla mnie bardzo zaczepną rzecz, czyli jak robisz design oprogramowania? Prototypujesz czy naklejasz karteczki? I tutaj pokazał właśnie tą stronę, czyli próby modelowania sobie w kodzie modelu biznesowego i innych takich rzeczy. Jak lubię Oskara to jest miejsce, z którym się z nim w diabły nie zgadzam, o tak patrząc sobie, bo w większości elementów prototypowanie, w szczególności modelu biznesowego, w ogóle nie ma sensu w mojej opinii, bo API nie pokażesz biznesowi. Ktoś jeszcze uzna, że połowa roboty jest zrobiona, bo też są takie ciekawe potem podejścia mentalne. A projektowanie, że tak powiem, ten design, upfront i nawet nie klejenie, ale normalne projektowanie sobie i zastanowienie się jakie mamy wymagania i inne rzeczy, często będzie lepsze. Mówię o części biznesowej aplikacji.
Szymon Warda: Dla mnie, jeżeli chodzi o prototypowanie, w ogóle części biznesowej tworzenie, to jest event storming i potem wybieranie happy patha. I to jest ten obszar, który możemy prototypować, ale potrzebujemy tych kartek, żeby je zrozumieć. Siadanie od razu do kodu jest zbyt optymistyczne, bym powiedział. Chyba, że mam bardzo małą domenę, którą doskonale znamy, to może być inna bajka. Ale te kartki są potrzebne, bym się z tym zgodził.
Łukasz Kałużny: Wiesz co? Tak, te kartki są potrzebne, bo całość np. przy prototypowaniu samych podsy, kiedy mamy wyzwania nazwijmy to technologiczne i czegoś nie wiem od strony technologii, to bazgraniem na ścianie tego nie przeskoczymy.
Szymon Warda: Ja bym się z tym nie zgodził, ponieważ bazgranie na ścianie dla mnie i to jest potęga i jak i dla mnie jest główny artefakt, bo jego znaczenie jest to, że definiujemy sobie czego my realnie potrzebujemy od danej technologii. Często idziemy, że mamy tutaj kolejkę, mamy cokolwiek, to jedziemy z Kafką. A mieliśmy sytuację nawet w tym, jak doradzamy, że ludzie wchodzili w Kafkę, a okazywało się nagle generalnie, że przykład mają dużo subskrybentów i nie zgadza im się i wychodzą poza limity. Więc to bazgranie technologiczne też jest potrzebne, bo daje wkład w podejmowanie świadomych decyzji, czego wymagamy od tego bloczku technologicznego, że to nie jest tylko generyczne, a wykonamy Kafkę, a wkładamy Rabbita czy cokolwiek innego, tylko nagle wiemy co, gdzie i po co i dlaczego.
Łukasz Kałużny: Wiesz Szymon, to jest jedno, ale możesz mieć z drugiej strony technologiczne, że musisz użyć biblioteki “A”, bo będzie zewnętrzna kupiona do rozwiązania problemu, musisz zintegrować się z jakimś API, bo masz je biznesowo z góry narzucone, jakąś integrację. Powiedzmy, że będzie pasowało potem do mojego późniejszego linku. Np. musisz sprawdzić integrację ze Stripem w jakimś tam kontekście, którego nie wymienisz. I w takich miejscach to się naprawdę sprawdza, takie sprawdzenie sobie jak ja to powinienem zakodować? Czy to w ogóle będzie działać?
Szymon Warda: Tak, jak już masz wybraną technologię, taka eksploracja, jakiej użyć, jakie ta technologia ma API i cała obudowa wokół tego, ja to nazywam fazą eksploracji, już nie designu, bo tam już decyzję projektową wybraliśmy, tak naprawdę. W tym momencie wchodzimy jak użyć tego narzędzia czy poznawania, to tu się zgodzę. Tak, tu trzeba sobie ręce ubrudzić i nie uciekniemy od tego, bez dwóch zdań.
Łukasz Kałużny: Tak, więc tak, design na papierze zawsze ma… Inaczej, niektórzy wolą stracić trochę, jak z czytaniem dokumentacji, lepiej stracić jeden dzień na próbie kodowania i klikania, niż poświęcić godzinę na myślenie bezpośrednio nad problemem. I dla mnie to jest właśnie takie porównanie trochę z czytaniem dokumentacji.
Szymon Warda: Która jest dalej ważna, ale faktycznie realne przepływy jak, co zadziała i co musimy mieć, chociażby np. tokeny, sesje, itd., będzie dopiero jak sobie rączki ubrudzimy, to się zgadza w zupełności.
Łukasz Kałużny: Wychodzę z tego takiego pisania prototypów. Ja np. jestem, szczerze, wolę np. jak mówimy o biznesie i innych takich rzeczach, że chcemy coś pokazać, wartość biznesową i inne rzeczy, to dla mnie wszystkie wspaniałe, brzydkie makiety i inne tego typu rzeczy są lepsze, bo nie ma świadomości, że jesteśmy gdzieś blisko i coś jest gotowe.
Szymon Warda: A to jest też kwestia różna, bo nigdy nie wiadomo gdzie te makiety pójdą wyżej. Im one dalej idą, im są dalej forwardowane mailem, bo tak też często bywa, tym one bardziej tracą kontekst w ogóle co to jest, jak to ma wyglądać, itd. Ogólnie to jest to, co mówiliśmy już parę razy, że musimy mieć wewnętrzne zarządzanie produktem do tego co wytwarzamy. Nieważne czy to jest platforma, nie ważne czy to jest jakiś wewnętrzny produkt, czy to jest zewnętrzny produkt, tam musi być ten kontekst produktowy, gdzie jesteśmy, co mamy zrobić, co to jest i tak dalej. To mogą być 2-3 slajdy, ale to musi być. Bo wydaje mi się, że tu jest to rozbicie, ten taki strach, że wyślemy coś i ktoś to inaczej zinterpretuje.
Łukasz Kałużny: Dobra, podejdźmy, słuchaj tak, czyli hit czy kit? Prototypowanie biznesowe niestety dla mnie kit. Sorry Oskar.
Szymon Warda: Na poziomie kodu pojedynczych procesów, chyba, że są jakieś super małe, to realne. Na poziomie czegoś większego też tego nie widzę do końca. Dobrze, ale teraz, żeby nie było, to ja teraz, też od Oskara, bo nie ukrywam, że to jest link z jego newsletteru i bardzo dobre linki, też mieliśmy okazję o tym pogadać sobie - Why we killed our end-to-end test suite, od Oskara i link zapisu Nubanku. Co wyszło? Stwierdzili, że mają pewien problem z end-to-end testing. Czekanie, brak pewności, koszt utrzymania tego przede wszystkim, że jak się coś wywali to ciężko jest namierzyć co się dokładnie wywaliło, czyli źródło problemu, mała wartość dostarczania i wolna dostarczania i wydajność tego w kontekście czasowym. I stwierdzili, że de facto ubijają swoje end-to end testy. Co dali jako rozwiązanie? Jako rozwiązanie zaproponowali testowanie kontraktów, czyli testowanie integracji między systemami. No i oczywiście jest, oczywiście ogłosili sukces. I z pewnymi rzeczami się, w sumie nawet jak rozmawialiśmy z Oskarem, się zgadzamy bardzo mocno, są end-to-end testy, tak samo jak testy UI-a, są absurdalnie wręcz drogie w utrzymaniu. Ja widziałem jeden projekt, który prowadziłem, gdzie faktycznie się udały.
Szymon Warda: Tam było ponad chyba 300 czy 400 testów UI, całkowicie UI i to działało. Ale czemu to działało? Działało to dlatego, że UI był całkowicie generowany na bazie lambd właściwie i liderów z poziomu C-Sharpa. Developerzy nie dotykali HTML-a, developerzy nie dotykali JavaScriptu. Więc w tym momencie kontrola była tym, co się wyświetli i jak się wyświetli, jakie ma znaczniki i tak dalej. W tym momencie można było przegenerowywać powiedzmy klasy C-Sharpowe opisujące dostęp, pathy do HTML-a i to działało. W innej formie, nie utrzymywalne. Z testami end-to-end jest bardzo podobnie, ale wydaje mi się, że ten artykuł traci jeden bardzo ważny przypadek. Mianowicie, że jaka jest wartość z testów np. jednostkowych czy nawet integracyjnych? Realnie dla biznesu niewielka. Widziałem strony, które miały powyżej tysiąca testów, były wdrażane i generalnie wywalały się na połączenie z bazą danych po prostu.
Szymon Warda: Testy end-to-end są drogie i trudne w utrzymaniu, bo testują cały proces biznesowy. I ten zarzut, że one nie pokazują oczywistych źródeł problemu, bo o to w nich chodzi, one nie mają pokazywać co się wywaliło, która klasa jest zła, ale mają powiedzieć, że proces biznesowy nie działa i to jest ich światło czerwone. To jest to, co się dzieje…
Szymon Warda: Często nie robimy, ale co powinno być robione? Testy end-to-end powinny być elementem naszego DoD. Takiego DoD nie programistycznego tylko produktowego de facto, bo definiując produkt definiujący jakiś tam zakres mówimy jakie use case’y będziemy obsługiwali. Te use case’y powinny mapować na testy end-to-end. Znaczy, że robimy… Ten system spełnia albo nie spełnia tych case’ów. Jest to trudne, to jest często omijane. Wiadomo, że nie ma sensu robić jakichś tam powiedzmy testów, jakiś totalnych corner case’ów, ale happy pathy end-to-end powinny być przetestowane.
Łukasz Kałużny: I wiesz co?Jest jedna rzecz, dużo osób potrafi pomylić test end-to-end, testowanie na bazie de facto gdzieś pomiędzy integracyjnymi a end-to-end, czyli sprawdzeniem sobie tego od strony API, a z drugiej strony budowaniem testów UI-owych. Bo bardzo często, jak mówimy o takich grubych babolach, to mówimy de facto, tak jak mówisz opłaca się, to mówimy o tym przepływie, który leci pomiędzy API. I też ludzie potrafią, zauważyłem przy rozmowach, że potrafią, dużo osób myśli end-to-end to od razu Selenium i inne tego typu elementy, że wchodzą w grę. Bardzo często trzeba sobie powiedzieć, że tutaj sprawdzenie sobie przepływu procesu na takiego happy pathu na podstawie API nie jest już taką straszną rzeczą.
Szymon Warda: Nie jest, tym bardziej, że rozgraniczmy jedną rzecz, proces biznesowy się tak często nie zmienia. UI zmienia się dużo częściej. Więc odetnijmy tą najbardziej zmienną część, czyli UI i testujmy generalnie w tym momencie, gdzie mamy w miarę sensowną stabilność procesu względem wartości, którą dostarczamy. Nie ma co się spiąć w jedną definicję. Wytnijmy te kawałki takie zewnętrzne i tam gdzie to ma sens, gdzie jest większa wartość, tam testujemy. Jest kilka sztuczek, które tu mogą pomóc. Pierwsza, jestem wielkim fanem reużywania danych z produkcji, anonimizacja. Przy realnych przypadkach biznesowych w skomplikowanych systemach, nie działa albo nie działa w pełni, albo jak zanonimizujemy, to potem nic z nich nie wyciągniemy.
Szymon Warda: Wydzielmy środowisko, żeby nie było do nich dostępu, do danych, traktujmy jako dane produkcyjne i obserwujmy tylko z wyników. De facto można to zrobić. Robimy to. Kolejne, jakbyśmy bardzo chcieli, duplikacja ruchu sieciowego. Możemy zrobić bazę, snapshoty baz, backup ich i potem patrzymy na ruchy i duplikujemy te ruchy. Nie jest to super tanie, to jest drogie, bo będziemy musieli te dane odświeżać, jak się w bazie zmieni schemat, to będzie się to zmieniać, ale jak patrzymy na te procesy, to jest rabialne i to jest dużo.
Szymon Warda: A potem idziemy w data-driven testing.
Łukasz Kałużny: Wiesz co, patrząc się Szymon, jak mówisz o tych sztuczkach, to polecam wam dodatkowe środowisko w rygorze produkcyjnym, do którego dostęp jest jak do produkcji, bo to jest najprostsze do implementacji bo shadowing… Jeżeli system nie jest gotowy na to, to potrafi być wesoło i być dużo niepotrzebnych błędów po stronie testowej instancji.
Szymon Warda: Zgadza się i tak też właśnie zalecamy często. Inną opcją jest to, że taki shadowing częściowy, czyli załóżmy mamy bazę z produkcji i system z produkcji wysyła sygnały tylko do wydzielonego środowiska, które nic wcale nigdzie nie wysyła i tylko monitoruje na bazie sygnałów, na bazie wiadomości. To też można zrobić. Ten shadowing komunikatu z produkcji można osiągnąć na wiele etapów i to jest tanie w zrobieniu i realnie weryfikuje nam end-to-end, weryfikuje nam przypadki biznesowe, weryfikuje nam realne dane, jest zmienne, tak jak zmieniają się procesy biznesowe. Można te rzeczy zrobić. Ale od testów end-to-end, jak bardzo są trudne, nie uciekniemy. Wolę mieć kilka testów end-to-end, niż od obsrania testów jednostkowych, które tylko potem powodują, że jakikolwiek refaktor jest nierealny, bo jest zbyt trudny, nikt ich nie utrzymuje, bo nikt ich nie rozumie i są robione tylko po to, żeby były i ludzie testują tu stringi albo testują dodawanie do tablicy. Fajnie, że test jest. Liczba się nie liczy, liczy się wartość biznesowa tego testu. A to testy end-to-end mają największą wartość biznesową. Jednostkowe, sorry, minimalna.
Łukasz Kałużny: Jednostkowe mają dać tylko szybki feedback i musimy się nauczyć je kasować, a nie zakładać, że to jest teraz napisane, ma zawsze przechodzić.
Szymon Warda: Rzadko kiedy widuję, żeby były usuwane, bo się przydadzą kiedyś.
Łukasz Kałużny: Tak, to jest całość, przy refaktorze potem code Cobry się nam rozpada. Co zrobić, co zrobić?
Szymon Warda: Zgadza się. Dlatego znowu przykład - źle zdefiniowane metryki, że musi być code coverage wysoki.
Łukasz Kałużny: Tak, code coverage powinien być tylko na warstwie biznesowej i nigdzie dalej zazwyczaj. I na warstwie technicznej, jak sami ją naklepaliśmy, a nie jest to framework, gotowiec. Wiesz co, jedna taka rzecz do tego wpisu, która jest całością. Tam jest nagłówek “A new hope contract testing”. Ja mam taki problem z contract testingiem, że sama idea pracy na kontraktach dla mnie jest nieziemsko świetna, jeżeli mamy systemy mikroserwisowe, integracji i inne rzeczy. Tylko całością rynkowo brakuje mi takich, żeby ten stos do contract testingu był taki opinionated. Nie ma kilku podejść na rynku jak to zrobić, nie wyrobiły się do tego, mimo że mówimy o tym… Ja pamiętam, interesowaliśmy się Karate na jednym z pierwszych odcinków o Thought Works Radarze. To był 2019 chyba rok i 4 lata potem nadal nie mamy jakoś super ustabilizowanego gruntu i praktyk jak to robić. I mimo, że sama idea mi się podoba, ale brak narzędzi mnie odrzuca.
Szymon Warda: A mówisz o narzędziach. A ja doszczegółowię co mnie wkurza w contract testingu, za dużo manualnej roboty, za dużo. To powinno być robionetak, że jeden system generuje, drugi automatycznie weryfikuje i jakby na to spojrzeć… Bo w kodach testingu chodzi nam o to, żeby systemy umiały się ze sobą dogadać po prostu. Więc to można by zautomatyzować. Nie mam pojęcia, jak to zrobić, poza skryptami bashowymi itd. Ale weryfikowanie schematów, contractów, zachowań względem tego co zapisaliśmy, a nie tego co system robi, wprowadzamy sobie kolejne źródło prawdy. W tym momencie co jest źródłem prawdy? Ten nasz opis contractów czy ten contract, który system realnie wypluwa obecnie?
Łukasz Kałużny: Wiesz co, Szymon, dlatego trochę patrzę na to, że musimy się cofnąć krok dalej i tak jak Open AI, AKA, swagger, czy wiesz protobufy w całym contrac’cie gRPC są nam potrzebne. Tak jak gRPC nam w pewnym sensie pewne rzeczy narzuca, tak HTTP API i dokumentowanie woła o pomstę do nieba. To powinno się generować prawie że z kodu automatycznie, bez naszego udziału. I to jest dla mnie taki ból dupy szczerze, że tego nie robimy, a potem nie można wprowadzić następnych części.
Szymon Warda: Tu się zgadzam. Tak to jest za dużo roboty do zysku i to z dużej skali potrafi być upierdliwe po prostu, zbyt dużym narzutem. Więc w ogóle ciekawy artykuł, propsy dla Oskara, że znalazł tego linka, więc naprawdę polecamy, ma dobry newsletter. Dobrze, Łukaszu, też miałeś coś jeszcze.
Łukasz Kałużny: Tak, ostatnia rzecz. 4-częściowa seria, słuchajcie, od Stripa i całość tutaj… Oni opisują jakie mają podejście do budowy swojego API. Więc de facto dla mnie, można powiedzieć, że warto się z tym zaznajomić, bo mówią o 3 takich elementach właśnie tworzenia API dla ludzi, bo to zazwyczaj człowiek ma mieć jak najmniejszy kognitywny narzut ze względu na wykorzystanie. I w tych czterech częściach mówią o tym jak nadawać ID-ki obiektom, jak robić ROR-y, w jaki sposób, jakie stosować wzorce projektowe. I ostatnim, w którym mnie przyciągnęło, to jest Common Design Patterns at Stripe. I oni pokazują na temat… Zaczyna się od nazewnictwa, które jest ciężkie. Czyli np. w przypadku karty wyrzuć żargon i używaj rzeczy, które są w powszechnym języku. Potem struktura np. pokazana właśnie, że statusy są lepsze. Lepiej zastosować statusy, które gdzieś się mapują, niż bóle w API i tak dalej, więc pokazują…
Szymon Warda: Łukaszu, ja coś dorzucę, bo jak opisujesz to to brzmi jak oczywistości, ale wydaje mi się, że potęga tego artykułu nie jest w tym, co on pokazuje, bo te rzeczy, które wymieniasz teraz, one są oczywiste, ale przykłady jak oni to pokazują są świetne po prostu. Oni taką drogę pokazują, jak się to zmienia i jakie są wyniki i czemu to jest złe. Świetny artykuł, naprawdę.
Łukasz Kałużny: Tak i to fajnie pokazuje. Wadą dla niektórych może być to, że pokazują to na pięknym RESTfulowym API. To może być dla niektórych wada, bo mogą sobie pracować na resource’ach w swojej domenie. Ale pokazuje te praktyki, jak te poprzednie wpisy, bo np. właśnie ID-ki przecież, ustalmy, zaczęli od ID-ków, które potrafią być naprawdę problemem przy ustalaniu w jaki sposób to zbudować. Więc to taka polecajka na koniec, warto sobie to… Jeżeli musicie budować jakieś API, to polecam sobie to przejrzeć i zobaczyć w jaki sposób do tego można podchodzić lepiej.
Szymon Warda: Tak, ten artykuł w ogóle nie jest długi, jest całkiem fajny, ale musimy chyba zacząć zbierać dobre artykuły o budowaniu API, bo ostatnio parę ich wypłynęło.
Łukasz Kałużny: A, przy czym ja szanuję ich za części, za błędy. Zaczęli od Status 200 error, message error.
Szymon Warda: Fajnie pokazują drogę w tym artykule. To jest potęga, bo to fajnie tłumaczy jakie decyzje i co kopnie po drodze. Więc no… niezłe. Dobra, chyba tyle na dzisiaj.
Łukasz Kałużny: Zawijamy się w takim razie, trzymajcie się. Do usłyszenia. Hej!