Architekt Programista? 6 pytań do przyszłego Ciebie

ArchitectKażdy chce szybko z programisty stać się architektem, aby oczywiście mieć więcej wyborów i pieniędzy.

Zanim jednak tym architektem zostaniesz warto odpowiedzieć sobie na te pytanie.

Oto 6 pytań dla przyszłych architektów oprogramowania.

1. Czy w programowaniu istnieje srebrna kula ?

Nie ma srebrnej kuli w oprogramowaniu. Mógłbyś dojść do wniosku, że po 63 latach po wynalezieniu COBOL-a nasze oprogramowanie powinno dojść do fazy, w której istnieje idealne rozwiązanie. Tak jednak nie jest. 

Z mojego doświadczenia techniki programistyczne można podzielić na dwie kategorię:

• Fatalne
• i dobre, ale to zależy. No właśnie "to zależy". 

Warto o tym pamiętać, gdy będziesz miał obsesje nad swoim młotkiem i będziesz nim próbował montować kafelki, bo dla Ciebie wszystko jest teraz gwoździem. 

2. Czy kwestionujesz Hype ?

Ten problem dotyka całego obszaru IT i został on nazwany już wieloma śmiesznymi skrótami jak:

• "Hype Driven Development",
• "Conference Driven Development",
• "Loudest Guy Driven Descisions"
• i ostatnie najważniejsze "Resume Driven Development",

...czyli to jak nasze dążenie do dodawania fajnych nowych technologi do CV wpływa na tworzenie aplikacji w korporacjach. 

Każdy chce dodać nową technologię do CV, aby zwiększyć swoją wartość, ale aby to zrobić z czystym sumieniem, to trzeba taką aplikację stworzyć w swojej obecnej firmie. Znaczy to, że marketingowe kręcenie pewnych rozwiązań technologicznych pociąga wiele sznurków w tym trendy w CV i  potem te trendy wypluwają nie koniecznie dobre programistyczne twory.

To, że coś jest nowe, nie znaczy automatycznie, że jest to lepsze. To, że  coś jest popularne, nie znaczy, że automatycznie, że jest to perfekcyjne narzędzie, które rozwiąże twój konkretny problem. Tworzymy oprogramowanie, aby rozwiązywać problemy, a nie po to, aby dopisać sobie technologię do CV.

Dlatego warto kwestionować każde rozwiązanie, zwłaszcza jeśli to rozwiązanie jest dopiero w swojej fazie "rozgłosu" i nie zostało tak naprawdę sprawdzone na dużą skalę, a to zajmuje zazwyczaj danej technologi 3-4 lata. Nie dziw się, więc jeśli twój architekt nie podziela entuzjazmu twojego nowym rozwiązaniem, bo ma do tego swoje powody.

3. Czy kwestionujesz wzorce projektowe ?

Gdy zaczynałem programować z 10 lat temu, to byłem przekonany, że wzorce projektowe są kluczem do czystego, czytelnego kodu i znajomość tych wzorcu będzie mi otwierało możliwości zabłyśnięcia na rozmowach kwalifikacyjnych. 

Gdy już pracowałem, to kupiłem sobie książkę za 300 zł i myślałem, że tę cenę kupuje wręcz święty Gral programistyczny. Ta książka nie tylko opisywała wszystkie wzorce projektowe z "Gang of Four", ale także pokazała ich użycie w poszczególnych warstwach aplikacji ASP.NET Web Forms. 

Po krótkiej analizie książki doszedłem do wniosku, że połowa tych wzorców projektowych jest albo beznadziejna, albo bardzo sytuacyjna, albo już ktoś wymyślił coś lepszego. Potem lata mijały w mojej karierze programisty i najczęściej używanym wzorcem projektowym był tylko dekorator.

Mogłem, też zobaczyć jak pewien architekt zrobił bardzo nieczytelny kod, ponieważ użył wzorca projektowego "State", który jest w porządku, dopóki logika nie jest zarządzana przez 30 oddzielnych klas, które mają reprezentować, jak sama nazwa wzorca wskazuje, oddzielny stan i akcje dla danego elementu w tym stanie.

Ja jednak by wolał jeden plik, gdzie mogę wzrokiem zrozumieć, co ja właściwie robię, gdy takie i takie stany danego elementu występują. Niby to antywzorzec, ale przynajmniej bym wiedział, co ja właściwie robię. Teraz też wiem, że dobrą alternatywą dla wzorca "State" jest maszyna stanów, która nie była opisana w wielu książkach. 

To mnie nauczyło kwestionować rozwiązania programistyczne nawet te poparte autorytetem i ceną książki. 

4. Czy znasz prawo Conway'a ?

Jako programista zauważyłeś, że ostatnio bardzo stały się popularne mikroserwisy  oraz mikro-frontendy. Tak jak mówiłem wcześniej to, że coś jest popularne, to automatycznie nie znaczy, że są to rozwiązania dla Ciebie.

Ich popularność można tłumaczyć "Prawem Conway'a", które nam mówi, że naszego oprogramowanie będzie dążyć do struktury, jaką mamy w naszych zespołach w firmie. 

Skoro mamy małe zespoły po 3-5 osób to nasze oprogramowanie też chce dążyć do małych aplikacji backend i frontend.

Nie dlatego, że jest to uniwersalnie dobre, ale dlatego, że takie mamy podziały zespołów.

Prawa Conway's nie da się oszukać. Jest jak prawo grawitacji.  Jeśli mamy złą komunikację w zespołach albo struktura zespołów  jest jak przyciśnięcie wzajemnie do siebie pistoletów do głowy, to te wszystkie problemy wyjdą w oprogramowaniu. 

Przykład zbyt dużego zespołu. Jak myślisz działa on wydajnie ?

Dlatego architekci nie tylko robią diagramy projektów z kodem, ale także robią mapę kontekstów i zespołów, które w jakiś sposób ze sobą muszą się komunikować, aby firma jako cały puzzel lub organizm jakoś funkcjonowała.

Fachowo mówi się na to "Context Map".

Ciekawe, że można znaleźć problem w oprogramowaniu nie w kodzie, ale w relacjach między zespołami i być może w niedalekiej przyszłości jako architekt twoim zadaniem będzie włożyć kij w mrowisko polityki firmy, aby przyszłe oprogramowania był lepsze.

5. Czy to się skaluje ?

Gdy już znasz najlepsze z najlepszych praktyk w architekturze w twojej głowie na nie jednym spotkaniu pojawi się pytanie "Czy to się skaluje ?".

No cóż, żeby, to zweryfikować to trzeba napisać prototyp albo mieć już doświadczenie z daną techniką.

Ostatnio jednak pojawiło się wiele alarmów o odwrotnym problemie. Nie każdy z nas będzie tworzył drugiego Facebooka, to znaczy, że wiele genialnych praktyk będzie przerostem formy nad treścią naszego rozwiązania.

Mówi się na to " Overengineering". 

Dlatego, zamiast zadawać sobie pytanie ", Czy to się skaluje?" warto także zadać sobie pytanie "A co jeśli tyle mi wystarczy?".

Dodatkowo warto zaznaczyć, że genialna technika to jedno, ale jej dobra implementacja to drugie.  Wiesz mi, każdy programista wolałby aplikację CRUD niż źle napisaną aplikację CQRS z Event Sourcing. Dlatego skup się na jak najprostszych rozwiązaniach dopasowanych do skali swojego problemu.

6. Czy masz swoje zdanie ?

Warto weryfikować każdą technikę i uważać, aby nie stać się papugą, która powtarza to, co usłyszała na konferencji albo od innego kolesia, który głośnio krzyczy.

Ciągle się uczymy i niestety nic nie zastąpi twojej weryfikacji danej techniki z prawdziwym projektem biznesowym.

TL;DR Zawsze możesz też obejrzeć filmik na YT na ten temat :)

;