Better Software Design

Konferencja PHPers Summit 2023 była świetną okazją do tego, aby zrobić coś zupełnie inaczej w podkaście. Mikrofony i reszta sprzętu wylądowała w jednej z hal Międzynarodowych Targów Poznańskich, na scenie zasiedli obok mnie Michał Giergielewicz i Grzegorz Korba z trójmiejskiego GetResponse, a na sali pojawiło się kilkaset zainteresowanych rozmową osób.

Summit i 10-lecie community były świetną okazją do tego, aby to właśnie słuchacze napisali scenariusz tej rozmowy. Pojawiały się pytania z sali i na chacie, a zaplanowane na sam koniec konferencji 45 minut nagrania przeciągnęło się do 1.5 godziny, za co wszystkim tam zebranym jeszcze raz dziękuję!

Zapraszam!

Idea zaproponowanej przez Alistaira Cockburna architektury heksagonalnej ma już prawie 20 lat. Ale jak krótko i rzeczowo opisać założenia Hexagonal Architecture, czy też Ports & Adapters? I jak to przekłada się na kod systemu?

Każdy koncept można bardzo mocno i niepotrzebnie skomplikować. Nawet tak prosty w swojej istocie jak Porty i Adaptery. Dziś z moim gościem, Kubą Nabrdalikiem, wracamy do korzeni z 2005 roku i staramy się wyłuskać esencję tego wzorca architektonicznego. A jeśli przy drugim mikrofonie gości Kuba, to wiadomo, że będzie do bólu pragmatycznie i prosto w z mostu...

W dzisiejszym odcinku:

• czym jest architektura heksagonalna,
• czym są porty i adaptery,
• skąd w ogóle wywodzi się ten koncept i jak ma się do dzisiejszych czasów,
• jakie typowe błędy można popełnić stosując ten wzorzec w kodzie,
• nie zabrakło oczywiście przykładów z życia i produkcji...

Materiały dodatkowe:

• hexagonalarchitecture.org, homepage na temat Ports & Adapters
• Hexagonal architecture, nowsza wersja oryginalnego wpisu Alistaira Cockburna na temat architektury heksagonalnej z 2005 roku
• Hexagonal architecture @ wiki c2, wpis na blogu Warda Cunninghama
• SmallerWebHexagon, wspominane w odcinku repo pokazujące bazową ideę
• Hentai, repozytorium Kuby Nabrdalika pokazujące użycie hexagona z modularyzacją i innymi technikami

Subdomena czy bounded-context może być odkryta lub zamodelowana z użyciem heurystyk, które pojawiły się już kilkukrotnie we wcześniejszych rozmowach. Ale jak te koncepty mapują się na kod naszego systemu? Gdzie i jak zobaczymy w IDE ich istnienie i zakres? Odpowiedzią na te pytania mogą być opisane przez Erica Evansa moduły, zwane także pakietami.

Dziś ponownie moim gościem jest Marcin Markowski, a nasza rozmowa będzie dotyczyć wspomnianych już modułów. Będzie i teoretycznie i praktycznie, z obowiązkowym przykładem.

W dzisiejszym odcinku rozmawiamy z Marcinem m.in. o:

• decyzjach wpływających na kształt subdomen biznesowych i bounded contextów,
• modułach i ich roli w projekcie,
• organizacji kodu i struktury aplikacji w pakiety.

Materiały dodatkowe:

• Tacking Complexity in the Heart of Software, Eric Evans, rozdział poświęcony modułom,
• Modules in DDD, artykuł podsumowujący wspomniany powyżej rozdział,
• DDD Starter DotNet, przykład organizacji kodu w repozytorium Marcina,
• Modular Monolith with DDD, przykład organizacji kodu w repozytorium Kamila Grzybka,
• Modularization of domain models, darmowy rozdział książki Functional and Reactive Domain Modeling,

Kod często można zmienić relatywnie łatwo. Jednak zupełnie inaczej jest z własnymi nawykami czy podejściem. Dziś na czynniki pierwsze rozkładamy kilka typowych "dev-grzeszków", które z perspektywy osób odpowiedzialnych za całe piony IT mogą przeszkadzać w karierze. Ponieważ technologia to niestety nie wszystko...

Moim gościem jest dziś ponownie Wojtek Ptak, Executive Engineering Director oraz Head of Development w Revolut Business. A jakich tematów dotkniemy podczas rozmowy? Choćby tego, że błędem jest nieposiadanie planu. Nasza kariera nie musi się "wydarzać" i podążać od przypadku do przypadku. Ten proces może być znacznie bardziej świadomy, wsparty różnymi ćwiczeniami i działaniami. Jakimi dokładnie? Polecam posłuchać mojego gościa.

Materiały dodatkowe:

• Developer Community Keynote: The thing about burnout,
• Principles, Ray Dalio, 2017
• To Sell is Human: The Surprising Truth About Moving Others, Daniel H. Pink, 2012
• The Secrets of Consulting: A Guide to Giving and Getting Advice Successfully, Gerald M. Weinberg, Virginia Satir, 1985 - klasyka gatunku, wielokrotnie wspominana w poprzednich odcinkach

Odcinek ukazuje się przy okazji 3 edycji szkolenia Legacy Fighter. Jeśli chcesz nauczyć się tworzyć nowy kod ściśle dopasowany do wymagań biznesowych, odporny na erozję, a także skutecznie naprawiać już istniejące legacy tymi samymi technikami, zapraszam!

Cały kod jest dostępny w kilku technologiach jest dostępny na GitHubie.

Do dziś pamiętam pierwsze wydanie pewnego projektu... 30 sekund po zakończeniu procedury rozdzwoniły się telefony i jasne już było, że choć wdrożenie może i się udało, to wydanie już niekoniecznie. Jakiś czas później sterowaliśmy zmianami w zachowaniu kodu na produkcji bez konieczności jego aktualizacji, już całkowicie bezstresowo.

Jedną z zastosowanych tam technik były Feature Toggles i właśnie na ten temat rozmawiamy z moim dzisiejszym gościem, Mateuszem Kwaśniewskim. Ponieważ jeśli na ten temat z kimś rozmawiać, to najlepiej z osobą, która pracuje przy jednym z najbardziej znanych systemów do zarządzania flagami w kodzie.

W tym odcinku rozmawiamy z Mateuszem m.in. o:

• rozdzielaniu wdrożeń od wydań projektu,
• różnego rodzajach Feature Toggle'ach i ich przeznaczeniu,
• sposobach i miejscach osadzania toggli w kodzie,
• dobrych i złych praktykach stosowania tej techniki w projekcie,
• testowaniu kodu wyposażonego we flagi.

Zapraszam!

Materiały dodatkowe:

• Feature Toggles a.k.a Feature Flags, świetny artykuł Pete Hodgsona na temat różnego rodzaju toggli, ich przeznaczenia i cykli życia
• The most expensive bug in history..., poruszona już w podkaście historia firmy Knights Capital, zakończona m.in. błędnym wykorzystaniem feature flagi
• Feature Toggles - Why and How to Add to Your Software, 2-godzinny tutorial na temat stosowania toggli z użyciem Unleasha
• Unleash Quickstart, skrócona wersja tutoriala
• FeatureFlags.pl, małe kompendium wiedzy na temat Feature Flags i podejścia Trunk Based Development

Istnieją trzy rodzaje dokumentacji. Przy czym pierwszy rodzaj to taki, który… nie istnieje. A o dwóch pozostałych dowiesz się z tego odcinka.

Dziś moim gościem jest Marcin Markowski, a rozmawiać będziemy o dokumentacji i sposobach na utrzymanie jej aktualności. Bo niestety, mało co tak przeszkadza podczas pracy jak dokumentacja, na której nie można polegać.

W tym odcinku rozmawiamy z Marcinem m.in. o:

• co i dlaczego warto dokumentować podczas prac nad projektem,
• typowych problemach z dokumentacją, w tym
• koncepcie Living Documentation autorstwa Cyrille Martraire,
• strategiach i konwencjach pozwalających utrzymać aktualność dokumentacji wbudowanej w projekt,
• założeniach modelu P3 i różnych perspektywach dokumentacji.

Nie mogło oczywiście zabraknąć wątku związanego z utrzymywaniem wiedzy projektowej na Confluence… A w kilku miejscach wodze fantazji zostaną delikatnie puszczone.

Materiały dodatkowe:

• Living Documentation: Continuous Knowledge Sharing by Design, 2015, wspomniana w odcinku książka Cyrille Martraire
• Leaving Documentation, or Living Documentation?, prezentacja na wspomniany temat autorstwa Cyrille'a z konferencji SoCraTes
• Documenting Software Architectures: Views and Beyond, Felix Bachmann, Len Bass, David Garlan, 2002
• P3 Model, strona projektu Marcina i Łukasza Szydło na GitHubie, na ten moment informacyjnie o projekcie
• Dokumentacja, która sama się pisze, prezentacja Marcina z Boiling Frogs i 4Developers 2023
• marcin@twitter, profil Marcina na Twitterze

Zapraszam!

Wytwarzanie oprogramowania, zwłaszcza tego złożonego, to gra zespołowa. A gdy w projekcie udział bierze wiele zespołów, musimy zatroszczyć się choćby o komunikację pomiędzy nimi, czy przypisanie właściwych odpowiedzialności w projekcie.

Dziś moim gościem jest Piotr Kacała, CTO i członek zarządu Displate, a rozmawiać będziemy o podejściu zwanym Team Topologies. W myśl Manuela Paisa i Matthew Sheltona, autorów książki Team Topologies, w organizacji produktowej poszczególnym zespołom można przypisać bardzo jasno określone role, co z kolei pozwala określić modele komunikacji pomiędzy nimi. Na koniec dnia, nie każdy rodzaj komunikacji w organizacji jest pomocny i właściwy...

W tym odcinku rozmawiamy m.in. o:

• o tym, co tworzy dobry zespół,
• idei Team Topologies,
• modelach współpracy pomiędzy zespołami i rolami samych zespołów,
• realiach zespołowych przy rozwoju projektu Displate.

Materiały dodatkowe:

• Team Topologies, książka autorstwa Manuela Paisa i Matthew Skeltona, 2019
• Empowered: Ordinary People, Extraordinary Products, Marty Cagan, Chris Jones, 2020
• Product Blocks, rozwijany przez Piotra katalog "klocków", narzędzi i technich pomocnych przy zarządzaniu zespołami, który mocno polecam

Projektowanie systemu rozproszonego, opartego np. o architekturę mikroserwisową, zwykle nie jest trywialne. Pojawia się tu choćby problem komunikacji poszczególnych części systemu i właściwego sposobu jej testowania...

Wspólnie z moim dzisiejszym gościem, Rafałem Maciakiem, przyglądamy się idei testowania kontraktowego, które świetnie rozwiązuje problem testowania poprawności komunikacji pomiędzy konsumentami i producentami. Co istotne, w izolacji, bez konieczności używania kosztowych środowisk i testów integracyjnych.

W tym odcinku rozmawiamy m.in. o:

• idei testowania kontraktowego,
• przykładowej budowie kontraktów,
• lokalizacji tego rodzaju weryfikacji w piramidzie testów,
• narzędziach wspierających testowanie kontraktowe,
• różnicach pomiędzy Consumer Driven Contract i Producer Driven Contract,

Materiały dodatkowe:

• Contract Testing - Spring Cloud Contract, artykuł Rafała na blogu SoftwareMill przedstawiający praktyczną stronę testowania kontraktowego z użyciem Springa,
• Save your friday's evening with Contract Testing, prezentacja Rafała z Allegro Tech Meetings
• Spring Cloud Contract in a polyglot world, artykuł Marcina Grzejszczaka na blogu Spring, pokazujący praktyczne użycie SCC,
• How Pact Works, krótkie wprowadzenie do zasady działania jednego ze wspomnianych w odcinku narzędzi
• Can I Deploy, jedno z narzędzi wchodzących w skład Pacta, wspomagające proces wdrożenia systemu
• Introducing Contact Testing with PactFlow, playlista kilku ciekawych filmów przedstawiających użycie Pacta w omawianym w odcinku kontekście

Zapraszam Cię także do odwiedzenia moich innych miejsc w internecie:

• https://twitter.com/mariuszgil
• https://instagram.com/mariuszgil_dev/
• https://youtube.com/c/MariuszGil

CQRS, czyli Command Query Responsibility Segregation, jest wzorcem wyjątkowo popularnym i powszechnie stosowanym w wielu systemach. Mało kto jednak sięgnął po oryginalny dokument autorstwa Grega Younga, który opisuje założenia tego konceptu architektonicznego i z czasem obrósł on kilkoma mitami.

Dziś w podkaście ponownie gości Oskar Dudycz, z którym na tapet weźmiemy zarówno mity jak i fakty dotyczące wzorca CQRS. A gdy przy drugim mikrofonie pojawia się Oskar, to wiadomo, że będzie do bólu pragmatycznie...

W tym odcinku rozmawiamy m.in. na temat:

• czym jest wzorzec CQRS i jaki ma związek z językiem Eiffel i ideą CQS Bertranda Meyera,
• związku z wzorcem Command & Command Handler,x
• szeregu mitów, którymi CQRS obrósł na przestrzeni lat, np. koniecznością stosowania asynchroniczności,
• różnych możliwych sposobach, w jaki CQRS może zostać zaimplementowany w systemie.

Materiały dodatkowe:

• CQRS, oryginalny dokument Grega Younga, opisujący koncept CQRS
• CQRS Bliki, artykuł na bliki Martina Fowlera o omawianym wzorcu
• CQRS facts and myths explained, artykuł na blogu Oskara na poruszony w rozmowie temat
• Od CRUD do CQRS w praktyce, prezentacja Oskara z konferencji bITconf 2022

Zapraszam Cię także do odwiedzenia moich innych miejsc w internecie:

• https://twitter.com/mariuszgil
• https://instagram.com/mariuszgil_dev/
• https://youtube.com/c/MariuszGil

Mylić się to rzecz ludzka, propagować automatycznie te błędy to DevOps... Tym razem na tapet bierzemy historie o tym, jak to produkcja płonęła i jakie wnioski zostały z tego wyciągnięte.

Dziś moimi gośćmi w podkaście są Jarek Pałka i Wojtek Ptak, a w takim gronie nie wypada zamiatać spraw pod dywan. A że warto uczyć się na błędach, a najlepiej tych popełnianych przez innych, wyciągniemy parę naszych błędów z przeszłości. Oprócz tragikomicznych aspektów niektórych z przytoczonych tu sytuacji, będzie to bardzo dobry wstęp do znacznie ważniejszych wątków.

W tym odcinku rozmawiamy m.in. o:

• naszych błędach i wyciągniętych wnioskach,
• różnych źródłach problemów i ich typach, od błędów ludzkich po limity infrastrukturalne,
• mierzeniu rzeczy, by określić wpływ fuckupu na otaczający nas świat,
• przygotowywaniu się na incydenty, bo to nie kwestia czy wystąpią, tylko kiedy,
• jakie działania podejmować w trakcie problemu,
• kulturze postmortems, lessons-learned i upewnianiu się, że wnioski,
• jak i kiedy komunikować o problemach,
• co zrobić, gdy fala sztormu odpłynie w dal...

Będę bardzo zobowiązany za wypełnienie krótkiej ankiety na temat tego odcinka.

Materiały dodatkowe:

• Death March - Edward Yourdon
• The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win - Gene Kim, Kevin Behr, George Spafford
• Normal Accidents: Living with High-Risk Technologies - Charles Perrow
• The Idealcast with Gene Kim by IT Revolution - rozmowa z dr. Ronem Westrumem m.in. na tematy związane z problemami w złożonych systemach (od 34:45)
• The Facebook Outage - postmortem problemu Facebooka
• Root Cause Analysis: A Quick Guide - opracowanie na temat wspomnianego w odcinku RCA
• Software Testing Lessons Learned From Knight Capital Fiasco - analiza przypadku Knight Capital i utraty ponad 400M USD