Cześć!

Przez okno mojej sypialni widzę efekt dobrych planów, ale kiepskiej realizacji. W zamierzeniu eleganckie budynki w stylu śródziemnomorskim stoją i niszczeją. Termin oddania? Na papierze: półtorej roku temu. Rzeczywisty? Coraz bardziej niewiadomy.

W zeszłym tygodniu miałem dyskusję na temat tego, że tworzenie architektur opartych na zdarzeniach jest łatwiejsze gdy używa się Event Sourcing. Argumenty były słuszne, że skoro już się publikuje zdarzenia i napędza nimi działanie systemu, to trzymanie również w stanu jako zdarzenia ułatwia sprawę. Mamy wtedy źródło prawdy, z którym możemy skonfrontować efekty działającego systemu. Prawda, tylko dobór słów jest co najmniej nieszczęśliwy. Dlaczego? Bo jest to faktycznie łatwiejsze, o ile już znamy Event Sourcing.

Wielu ludzi ze społeczności DDD twierdzi, że najważniejsze to dobrze podzielić system na fragmenty (tzw. “Bounded Contexts”). Reszta jest już wtórna i się sama ułoży. Na pewno.

Wielu doświadczonych programistów, mówi podobnie o nowych technologiach. Sam zbijałem się nie raz, że SPA to nowe Win.Forms. Twierdzą, że dzięki doświadczeniu w technologiach z przeszłości są w stanie przełożyć to sobie na nowe. Faktycznie, zrozumienie i skojarzenie ogólnej zasady działania przychodzi łatwiej. Czy jednak nie jest to buńczuczne, by nie powiedzieć naiwne, założenie l, że spec z Win.Forms raz, dwa nauczy się Reacta?

Efekt końcowy prac budowlanych, może się bardzo różnić od założeń pierwotnych. Widziałem planu tych budynków koło mnie. Teraz widzę efekt wykonania. A w zasadzie jego brak.

Uważam, że powinnismy bacznie obserwować nie tylko punkt widzenia naszych autorytetow, ale też punkt siedzenia tych osób. Jeżeli chcemy się dowiedzieć jak wymurować ścianę to pytamy się architekta czy majstra? Architekt może to wiedzieć, ale z teorii, czasem potrzebna jest nam praktyka. Z drugiej strony jeśli chcemy wiedzieć, czy most obciążenia to raczej wolelibyśmy mieć pewność, że architekt to dobrze przeliczył. “Będzie pan zadowolony” usłyszane od majstra nie zawsze wystarczy.

Jak naderwałem więzadło w kolanie poszedłem do dwóch dobrych ortopedów. Jeden powiedział, że trzeba operować i robić rekonstrukcję. Drugi, że nie trzeba operować, wystarczy rehabilitacja dobra i wzmocnienie mięśni. Zgadnij, który miał specjalizację z chirurgii, a który z rehabilitacji?

Ludzie dają nam zwykle porady patrząc z punktu, w którym są obecnie. Mają prawo mieć skrzywiony pogląd. Architekt, który nie programuje, lub robi to rzadko będzie miał tendencje do bagatelizowania wartości implementacji na korzyć projektu. “Mid” czy “Senior” developer będzie skupiał się na wzorcach implementacyjnych, zamiast globalnej wizji i spójności systemu. Zarządzający zespołem czy konsultant będzie uwypuklał wagę umiejętności miękkich. Specjalista będzie skupiał się na aspektach twardych.

Józef Pilsudzki podobno zwykł mawiać: “Racja jest jak dupa, każdy ma swoją”.

Dlatego też apeluję, gdy coś czytamy, analizujemy to zwróćmy też na to uwagę z jakiej perspektywy ktoś to mówi i jak daleka jest od naszej. Może to nam pomóc w ocenie czy rada jest adekwatna do pozycji, w której my się znajdujemy. Warto patrzeć nie tylko na ludzi z piedestału, ale też na historie osób, które były w tym miejscu, gdzie my byliśmy. Relacje osób, które nie są daleko od nas.

Dla mnie osobiście, jest to też ważne, żeby przy moim obecnym stanowisku zachować kontakt z rzeczywistością. Nie chciałbym, żeby moje przemyślenia były oderwane od szarej rzeczywistości programistycznej. Jeśli zauważysz takie symptomy, w którymś mailu, to mam do Ciebie prośbę. Napisz do mnie: “Oskar, weź nie pierd…”.

Spokojnego tygodnia!

Oskar

P.S. Już po napisaniu tego newslettera zdałem sobie sprawę, że rok temu pisałem o bardzo podobnym temacie: “Wzorce strategiczne kontra wzorce taktyczne - które są ważniejsze?”. Do poczytania w archiwum link.

A oprócz tego jak co tydzień nowe Architecture Weekly: https://github.com/oskardudycz/ArchitectureWeekly#5th-april-2021