Sytuacja kobiet w IT w 2024 roku
12.04.20216 min
Allen Helton

Allen HeltonSoftware Engineering ManagerTyler Technologies

Jak być dobrym Architektem Rozwiązań po pracy jako Developer

Sprawdź, jak zmienić swój sposób myślenia, aby stać dobrym Architektem Rozwiązań, pracując wcześniej jako Developer.

Jak być dobrym Architektem Rozwiązań po pracy jako Developer

“No i co z tego?” Kiedy po raz pierwszy zadano mi to pytanie na Sprint Review, nie miałem pojęcia, co odpowiedzieć. Byłem wtedy juniorem i to mnie zniszczyło. Zacząłem się jąkać i wiercić. Spojrzałem na mojego szefa wzrokiem proszącym o pomoc. Naprawdę zabrakło mi słów. Skończyłem właśnie demo mojego projektu. Naprawdę byłem z niego dumny. Ale kiedy jeden z interesariuszy zapytał mnie “no i co z tego?”, nie wiedziałem, co powiedzieć.

Wiedziałem, jak mój projekt działał. I to wszystko. Nie wiedziałem jednak jaką rolę odgrywał w całym systemie. Nie wiedziałem nic o kontekście. W ogóle nie zdawałem sobie sprawy, że to może być w jakiś sposób istotne. Przekazano mi wcześniej wymagania, a ja spełniłem je przy pomocy kodu. Nie miałem pojęcia, że pisanie kodu to tylko mała część software developmentu. 

Jeśli chcesz stać się Architektem Rozwiązań, musisz brać pod uwagę kontekst. Trzeba widzieć szerszy obraz - bo nie chodzi tylko o pisanie kodu. Chodzi o to, w jaki sposób systemy wchodzą ze sobą w interakcję. Początek podróży w świecie architektury może być ciężki. Gdzie należy zacząć? W jakim kierunku w ogóle rozwijać umiejętność tak, aby ruszyć się z miejsca?

To nie aż takie trudne, jak może się wydawać.

Trzeba pójść o krok do tyłu

Twoim zadaniem jako software developera jest pisanie kodu do rozwiązania konkretnych problemów. W zależności od tego, jak napisane są Twoje stories, możesz się zderzyć z kontekstem biznesowym wokół zmian, które wprowadzasz. Aby zmienić swój mindset z Developera na Architekta, trzeba pójść o krok do tyłu. Zadaj sobie następujące pytanie: jaki wpływ na całą aplikację będzie miała moja zmiana?

Zastanów się nad tym, jakie elementy sprawiają, że Twoja aplikacja działa. Czy składa się ona z kilku modułów, które ze sobą współgrają? Czy to aplikacja typu klient-serwer? Czy jest wielowarstwowa? Twoim celem jest zrozumienie, jak elementy te komunikują się ze sobą. Jak już na to wpadniesz, postaraj się cofnąć jeszcze o krok.

Jak Twoja aplikacja zachowuje się w danym ekosystemie? Jeśli Twoja firma oferuje wiele produktów, czy Twoja aplikacja jest częścią większej grupy? Czy wchodzi ona w interakcję z innymi aplikacjami? Jak się ją konsumuje i jakie jest jej przewidywane zachowanie. Wyobraź sobie, że Twój kod to tłok w silniku samochodowym. Ma on swoją funkcję, która pomaga temu silnikowi w działaniu. Sam tłok jest jednak bezużyteczny. Gdy połączymy go jednak z innymi elementami, to ma niesamowitą wartość.

Twoja aplikacja to właśnie taki silnik. Ma ruchome części, które polegają na sobie w działaniu, tak aby całość funkcjonowała jak należy. Sam silnik nie robi jednak zbyt wiele dobrego.

Ekosystem oraz szereg produktów oferowanych przez Twoją firmę to cały samochód. Twoja aplikacja to jego silnik. To tylko jeden element całości, niemniej jednak jest on niezwykle istotny dla działania całej reszty. Cofanie się do momentu, w którym widzi się cały kontekst, to kluczowa część całej podróży, aby zostać Architektem Rozwiązań. Rozszerzaj swoje pole widzenia, dopóki nie zobaczysz całości.

Naucz się pytać dlaczego?

Jeśli jesteś software developerem to na pewno lubisz wiedzieć jak i dlaczego coś działa. Jeśli tak, to świetnie, ponieważ jest to niezbędna cecha świetnego Architekta Rozwiązań.

Widzieliście pewnie kiedyś taki film, w którym jakieś dziecko zamęczało swoich rodziców nieustannymi pytaniami “dlaczego, dlaczego, dlaczego?”. Jeśli tak, to już wiesz, co robić. Rozumienie tego, jak coś działa to jedna rzecz. Inną rzeczą jest zrozumienie, dlaczego zdecydowano się to zrobić.

Dlaczego tłok jest tak ważny dla działania całego silnika? Dlaczego posiada taki kształt i dlaczego został umieszczony akurat w takim, a nie innym miejscu w silniku? Pytanie się, dlaczego, to klucz do przejścia od zrozumienia do pojmowania czegoś w całości. 


Jeśli spojrzysz na system, który został zaprojektowany przez Architekta Rozwiązań, który rozumiał rzeczy tylko na podstawowym poziomie, to to, co napisałem powyżej, stanie się oczywiste. Rozumienie tego, dlaczego dane elementy do siebie pasują, da Ci wystarczającą wiedzę do naprawienia problemu. Weźmiesz elementy, które widzisz i połączysz je ze sobą. Stworzysz złożone rozwiązanie ze złożonego problemu.

Jeśli jednak naprawdę rozumiesz wszystkie szczególiki komponentów i elementów, to pojmiesz i będziesz o wiele lepiej wiedzieć, jak projektować lepsze systemy. Pojmowanie rzeczy w całości otwiera Cię na kreatywne, ale proste rozwiązania. 

Połącz problemy z popularnymi rozwiązaniami

Bycie Architektem Rozwiązań nie polega już tylko na kodowaniu. Nie masz już tego komfortu polegającego na projektowaniu rozwiązań, implementowaniu ich i przechodzeniu do następnego. Kiedy skończysz design, to musisz go wszystkim wytłumaczyć. Developerom, interesariuszom, ludziom, którzy pracują nad danym produktem, wsparciu i tak dalej - wszyscy oni muszą go rozumieć.

Skoro już to wiemy, to można się domyślić, czy przydadzą się tutaj umiejętności miękkie. Umiejętność pewnego wyrażania swoich myśli to Twoje najpotężniejsze narzędzie. Osobiście najlepiej tłumaczyło mi się moje projekty przy użyciu metafor. Porównywanie swoich pomysłów do jakiejś prostej koncepcji, która jest zrozumiała dla innych, to dobry sposób na uchwycenie swoich myśli. 

Jeśli możesz w efektywny sposób zakomunikować jakieś techniczne rozwiązanie dla nietechnicznych odbiorców, to znaczy, że jesteś stworzony do tej roboty. W porównywaniu danych problemów z powszechnymi rzeczami nie chodzi tylko o komunikację - chodzi o zapożyczenie pomysłów od rzeczy, które widzi się codziennie. 

Nie trzeba na nowo odkrywać Ameryki. Istnieje mnóstwo wzorców projektowych i przykładów, które możesz wykorzystać w swoim projekcie. Jeśli tworzysz aplikację, która zarządza ładowaniem i utrzymywanie plików, dlaczego nie przyjrzeć się bardziej Google Drive i sprawdzić, czy nie ma tam funkcji, których można użyć jako porównania. 

Lub jeśli projektujesz system, który tworzy harmonogram pracy dla pracowników, dlaczego nie poszukać inspiracji na Outlook i Lotus Notes? Są to aplikacje, które odniosły duży sukces i na pewno Ci pomogą, jeśli pożyczysz stamtąd kilka wzorców projektowych. 

Świetną rzeczą w byciu Architektem Rozwiązań jest to, że nie każdy pomysł musi być oryginalny. Możesz spójnie połączyć ze sobą różne elementy pochodzące z wielu rozwiązań, a to oznacza bycie bardzo dobrym w swojej pracy.  

Inspiracji szukaj wszędzie.

Patrz w przyszłość

Dobry Architekt Rozwiązań żyje w przyszłości. Tworzy on system, który zapewni firmie sukces w przyszłości. Uważaj na decyzje, których nie da się odwrócić. Jeśli teraz ich dokonasz, to będziesz się z nimi męczyć w przyszłości. Jeśli możesz, odłóż takie decyzje na ostatni moment. Gdy projektujesz system, ustal, w jaki sposób się pozycjonujesz. Czy pozwalasz na to, aby Twoja praca była w przyszłości modularna. Czy myślisz, że utkniesz w scenariuszu bez wyjścia?

Wróćmy tutaj jeszcze do metafory samochodu - chcesz zbudować Matiza, czy Ferrari? Pamiętaj, że kiedy starasz się zrobić przejście z Developera na Architekta, znajomość planu to rzecz kluczowa. Jaki jest Twój cel?

Jakie Twoja firma ma cele na następny rok, następne 5, czy 10 lat?

Nie pozwól, aby obecne defekty miały wpływ na Twój plan w przyszłości. Nie pozwól im wpłynąć na projekt. Ucz się na błędach, ale przede wszystkim upewnij się, że otwierasz drogę dla nowych możliwości dla firmy.

Ćwiczenie czyni mistrza

Najlepsze w software developerach jest to, że kochają swoje rzemiosło. Nigdy nie spotkałem developera, który nie miałby zawsze chociaż jednego projektu na boku. Kochamy pracę. Kochamy uczyć się nowych rzeczy.

Mając to na uwadze, jeśli chcesz ćwiczyć tworzenie rozwiązań architektonicznych, rób to w wolnym czasie. Weź jakiś system, który już istnieje (np. Twoja ulubiona strona internetowa) i zacznij tworzyć diagramy na temat tego, czym według Ciebie może być dana architektura. Idź za każdym razem o krok do tyłu. 

Jeszcze lepiej, jeśli nie masz odpowiedniej dokumentacji, dokonaj diagramu aplikacji, nad którymi pracujesz w swojej pracy. Zostaną one natychmiastowo skonsumowane przez Twoją firmę, co pomoże Ci w pełnym ich zrozumieniu. 

Masz też inne opcje, aby nauczyć się, jak być Architektem Rozwiązań. Możesz zdać certyfikowany egzamin od AWS i uzyskać tytuł Architekta Rozwiązań. Certyfikat nie tylko sprawia, że jesteś o wiele bardziej wartościowy jako developer, ale utrwala też Twoją wiedzę na temat tego, jak wykonywać tę pracę. 

Łap każdą okazję do nauki. Znajdź sobie mentora. Na świecie znajdą się ludzie, który pomogą stać Ci się najlepszym w swoich fachu. A co najważniejsze - baw się dobrze. Projektowanie systemów to niesamowicie kreatywne zajęcie, które daje w życiu sporo radości. Jestem pewny, że u Ciebie będzie tak samo. 

Powodzenia!


Oryginał tekstu w języku angielskim możesz przeczytać tutaj

<p>Loading...</p>