W kwietniu 2019 rozpocząłem udział w kursie „Droga Nowoczesnego Architekta”. Po pewnych perturbacjach (szczegóły niżej), udało mi się go właśnie skończyć, więc tradycyjnie napiszę podsumowanie moich wrażeń.

Opis kursu

O kursie dowiedziałem się z podcastów devstyle.pl, których intensywnie słuchałem na początku zeszłego roku stojąc w warszawskich korkach. Wtedy okazało się że pierwsza edycja została zakończona ale mogę przystąpić do kolejnej. Okazało się również, że jeden z moich kolegów z pracy uczestniczył w pierwszej edycji i pozytywnie zarekomendował ten kurs, choć wspomniał że „trochę mu się wydłużyło” – wtedy jeszcze nie wiedziałem co to znaczy 🙂 . Niemniej jednak czułem się przekonany do wydania trochę ponad 2000 zł.

Kurs jest prowadzony przez uznane osobowości polskiej branży IT znane z wielu konferencji, tj. Jakuba Pilimona, Jakuba Kubryńskiego i Łukasza Szydło – więcej o nich można przeczytać na stronie kursu.

Formuła kursu jest relatywnie prosta: uczestnicy otrzymują dostęp do platformy online, gdzie co tydzień, przez 20 tygodni (5 miesięcy!), są udostępniane bloki tematyczne (patrz „2” na poniższym screenshocie) składające się z filmów-prezentacji („1”) o długości od około 5 do 60 minut):

Do bloku są opcjonalne zadanie do wykonania i linki do dalszych materiałów („3”). Ponadto uczestnicy otrzymują dostęp do kilku repozytoriów przykładowego kodu oraz do komunikatora Slack, gdzie można zadawać pytania prowadzącym. Materiały do poszczególnych bloków można sobie pobrać w postaci plików PDF i MP3 („4”), np. do odsłuchania „w drodze”.

Plusem powyższego rozwiązania jest możliwość uczestnictwa, w zależności od możliwości czasowych i chęci zaangażowania, na jednym z kilku poziomów:

1. Oglądanie + ćwiczenia + materiały referencyjne + dyskusje na Slack
2. Oglądanie + ćwiczenia + materiały referencyjne
3. Oglądanie + ćwiczenia
4. Tylko oglądanie

Oczywiście intencją autorów było zaangażowanie uczestników na poziomie 1. Obserwując Slacka faktycznie widziałem, że były sporo pytań, a prowadzący szybko i rzetelnie odpowiadali.

Moja opinia, czyli dlaczego warto

Podsumowując jednym słowem, to kurs jest warty uczestnictwa. Trzej prowadzący wykonali kawał dobrej roboty kondensując olbrzymi obszar wiedzy w przyswajalnej ilości i formie. Oczywiście nie była to jakaś wiedza tajemna i każdy, kto jest odpowiednio zdeterminowany, mógłby sobie ją znaleźć w internecie i książkach, ale tutaj otrzymaliśmy wszystko „na tacy”. Z ciekawości na koniec policzyłem, i w materiałach pojawiło się 31 linków (!) do książek w samym Amazonie, więc pewnie jeszcze kilkanaście kolejnych do stron poszczególnych wydawców. Przekazywana wiedza była uzasadniana doświadczeniem praktycznym prowadzących, często w nieco żartobliwej formule znanej z konferencji, z typowym „w pewnym dużym serwisie aukcyjnym na A.”…

Z kolei organizator dostarczył wygodne narzędzia i formułę: nagrania i dźwięk były bardzo dobrej jakości. Slajdy, sposób nagrania i prezentacji oraz nawet ubrania prowadzących 😉 były spójne, mimo tworzenia materiałów przez trzy różne osoby.

Najważniejsze rzeczy, które ja wyniosłem z tego kursu

Jedną z najważniejszych dla mnie rzeczy było uporządkowanie i „odczarowanie” określenia „Architekt”, ponieważ zrozumiałem, że jest ono błędnie lub nieprecyzyjnie stosowane, zarówno przeze mnie, jak i przez wiele osób, które znam. W praktyce oznacza 3 różne, tylko częściowo zazębiające się, role:

• Architekt przedsiębiorstwa (ang. Enterprise Architect) – człowiek, który przedstawia ogólne wytyczne dla IT i ewentualne ograniczenia, np. w dotyczące wyboru narzędzi, oczekiwanych poziomów bezpieczeństwa, sposobów integracji, zalecanych lub odradzanych platform uruchomieniowych, itp. na poziomie wielu zespołów lub nawet całej firmy – taka osoba na ogół nie ogląda kodu źródłowego.
• Architekt rozwiązania (ang. Solution Architect) – człowiek, który analizuje konkretne problemy biznesowe i przekłada to na wymagania techniczne, m.in. wybierając konkretne sposoby integracji i podziału logicznego aplikacji, weryfikuje rekomendowane rozwiązania techniczne, w razie potrzeby ogląda kod źródłowy ale raczej sam go nie tworzy.
• Architekt aplikacji (ang. Application Architect) – człowiek, który kodując podejmuje decyzje techniczne, dzieli aplikacje na komponenty logiczne i programistyczne, wybiera niezbędne biblioteki, analizuje możliwości zmian i konieczność powiązanych refaktoringów, najczęściej zaangażowany programista.

Powyższy podział jest dla mnie osobiście przełomowy, bo dowiedziałem się, że niemal od zawsze pełniłem rolę architekta aplikacji 😉 , podobnie jak wielu moich kolegów i koleżanek, nazywanych najczęściej kierownikami zespołu czy liderami technicznymi. A osoby nazywane u nas w firmie architektami okazały się właściwie „Architektami rozwiązania”. Można by uznać, że nie ma w tym wiele odkrywczego, jednak z mojej perspektywy okazało się to mieć znaczenie, bo stawia to wyraźniejsze granice: „architekt aplikacji” musi z jednej strony pracować z kodem, ale z drugiej strony widzieć i rozumieć całą architekturę oraz cykl wytwórczy tworzenia oprogramowania, w razie potrzebny także w obszarze zbierania wymagań z klientem. Z kolei od „architekta rozwiązania” należy oczekiwać znajomości funkcjonalności, ale nie samodzielnego kodowania. Taki podział sprawił, że dla mnie osobiście rola „architekta aplikacji” nagle stała się atrakcyjna, w przeciwieństwie do niekodującego „architekta rozwiązania”.

Skrót innych ciekawych informacji, które zwróciły moją uwagę:

• opis rodzajów architektur i sposobów integracji
• sposób wyboru architektur i narzędzi, uwzględniając potrzeby biznesowe i różne ograniczenia, nazywane ogólnie „driverami architektonicznymi” – w skrócie sprowadzające się do sformułowania „to zależy” 🙂
• zalecenie sceptycznego podejścia i niepodleganiu bezkrytycznie współczesnym trendom, np. pchanie się na siłę w architekturę mikro-usługową, bez znajomości możliwych negatywnych konsekwencji i tylko dlatego że wszyscy tak robią
• „odczarowanie” projektów typu „legacy” (określanych też jako „Big Ball Of Mud”) jako sytuacji, która jest standardowym typem pracy i należy sobie z nią radzić, w szczególności poprzez odkrywania architektury, zaplanowanie oraz przeprowadzenie jej dużych usprawnień i koniecznych powiązanych refaktoringów w kodzie.

Minusy, czyli na co zwrócić uwagę

• Do uczestnictwa potrzeba olbrzymiej własnej dyscypliny (w przeciwieństwie do typowego tygodniowego szkolenia stacjonarnego) – wypadnięcie z tygodniowego trybu jest praktycznie niemożliwe do nadgonienia, a wtedy traci się wartość wynikającą z uczestniczenia w dyskusjach na Slacku.
• Uruchomienie mojego terminu kursu w kwietniu, przez co trwał przez część wakacji, wydaje mi się teraz, że było błędnym pomysłem. Trudno mi sobie wyobrazić uczestnika, który zrezygnuje z wypoczynku i z równym zaangażowaniem będzie uczyć się wieczorami i w weekendy w lipcu. Tutaj oczekiwałbym normalnego cyklu akademickiego, zaczynającego się pod koniec września. Domyślam się jednak, że wtedy dla organizatora biznesowo ważniejsze było „kucie żelaza póki gorące”…
• Trochę dziwny jest sposób zapisania się na kurs, bo wymaga zapisania się na mailing marketingowy i „czekania” bez znajomości choćby prawdopodobnego terminu rozpoczęcia. Tu z kolei domyślam się, że organizator czeka na wystarczająco dużą pulę chętnych żeby uruchomić kolejną edycje, bo wymaga ona zaangażowania czasowego prowadzących do wsparcia i pewnie też odświeżenia niektórych materiałów.
• Trochę irytuje styl marketingowy „kup teraz, później będzie już tylko drożej” i wielokrotne zapewniania o niesamowitej wartości, co bardziej kojarzy mi się z telewizją typu „tele-mango”, ale można się przyzwyczaić 😉 i całość materiału jednak jest tego warta.

Podsumowanie

Powtórzę kolejny raz (sorry…), że warto poświęcić swój czas i pieniądze na uczestnictwo w tym kursie, w szczególności przez programistów myślących o poziomie seniora lub chcących sobie uporządkować wiedzę oraz dowiedzieć się jak robią podobne rzeczy inne firmy. Właśnie teraz, gdy siedzimy w domach, a przez ograniczenia covidowe dostęp do szkoleń stacjonarnych i konferencji jest praktycznie niemożliwy, wydaje się to bardzo wygodna forma rozwoju zawodowego (ang. Continuous Learning, z rzadko kojarzonym polskim tłumaczeniem „Kształcenie ustawiczne” 😉 ).