DevTalk Trio S03E08 – Kto odpowiada za kod, którego nikt nie rozumie?

Dzień dobry, nazywam się Maciej Anisarowicz i jestem twórcą podcastu DevTalk, którego właśnie słuchasz. W zamierzchłych czasach robiliśmy eksperymentalne nagrania takiego cyklu DevTalk Trio, w którym to w trzy osoby nagraliśmy kilkanaście odcinków, które następnie puszczaliśmy regularnie. I te odcinki spotkały się z bardzo dużym zainteresowaniem i ciepłym przyjęciem. Wtedy występowałem ja wraz ze Sławkiem Sobutką i Andrzejem Krzywdą. A teraz przed Tobą trzeci sezon DevTalk Trio, gdzie znowu eksperymentalnie dajemy wypowiedzieć się innym ekspertom. Przed Tobą ekipa DNA Drogi Nowoczesnego Architekta oraz Architekta Jutra, czyli Kuba Kubryński, Łukasz Szydło i Kuba Pilimon. Enjoy!

I dopiero po... W naniesieniu poprawek na ten high level design mamy coś, co pozwala na rozpoczęcie fazy deweloperskiej, jeszcze nie implementacji. Drugim krokiem, bo to był pierwszy, jest przygotowanie specki. I znowu tę speckę przygotowuje jedna osoba. Ta specka ląduje w repo. Jakub Kubryński, Łukasz Szydło, Kuba Pilimon, DevTalk. Najbardziej newralgiczny moment review, bo błędy popełniane na etapie review specyfikacji się jeden w jeden przełożą na błędy na poziomie kodu i potem tak naprawdę dopiero trafia ten finalny kod, który bardzo często jest na tyle duży, że przejrzenie jego już jest jakby trudne.

Zapewne w tym workflow'e są, jeżeli powstaje jakiś kod, to najpierw jest kontrakt jakichś testów, I one przechodzą, one są dobrze napisane, jest agent, który weryfikuje zgodność ze specką, jest agent, który weryfikuje sensowność testów, czy one cokolwiek sprawdzają. Być może do testów mutacyjnych, nieważne. Jest pewnego rodzaju workflow, który ubezpiecza ciebie na to, że jeżeli później w git blamie jest Kuba Kubryński, to mimo że tej linijki nigdy nie widziałeś, bo nie przejrzysz całości implementacji, tylko przejrzysz być może kluczowe punkty, To jesteś na tyle bezpieczny, że i tak to wrzucisz do maina czy też do mastera. Jasne, co ciekawe my też komitujemy te wszystkie reviews, specki, wyniki, weryfikacji tych wszystkich agentów, które sprawdzają np.

I teraz to, że ja mogę napisać testy wydajnościowe to super, ale muszę mieć ekosystem do odpalenia tych testów wydajnościowych. Mogę sobie napisać testy, które plikają mi po guju, ale te testy trwają swoje. One jakby nie są idealne. Zdarza się, że one jakby wiesz... Jakub Kubryński, Łukasz Szydło, Kuba Pilimon, DevTalk. Takich, które są, ale w zasadzie jak je wywalisz, to za dużo nie tracisz.

I też możemy je znaleźć, tak jak Kuba wcześniej powiedział. Dużo dodatkowych mechanizmów, typu nawet agenty, które robią review, które są w stanie zreviewować testy i też zweryfikować, czy tam przypadkiem jakichś takich tego typu rzeczy nie ma. Nawet więcej, rzeczy typu Asset True w teście, to jest w stanie Sonar Cube mi wykryć, że mam jakiś teścik, który w ten sposób mnie robi. Więc wydaje mi się, że trochę Kuba przesadzasz tutaj, że to ma moim zdaniem jednak dużo większą wartość niż koszty, które się z tym wiążą. Musisz odróżnić słowo Kuba, aż imię Kuba, bo ja nie wiem do kogo zawsze mówisz. To było do mnie. Ja się zgadzam, że nad review procesu wytwórczego jest dużo ważniejszy niż review poszczególnych pull requestów i wyłapanie, że brakuje mi subagenta, który weryfikuje to i to, jest kluczowe itd.