Jak zostać architektem oprogramowania w 2022 r.

Widzieliśmy już wiele nazw stanowisk związanych z architekturą oprogramowania. Architekci rozwiązań, architekci systemowi, architekci chmury, architekci aplikacji, architekci informacji, architekci korporacyjni, itd...

Bardziej formalny tytuł czy też nie, to jednak zawsze powinieneś mieć w swojej organizacji ludzi, którzy:

• Podejmują i wprowadzają długotrwałe decyzje co do architektury i wytycznych
• Stale analizują i unowocześniają architekturę oprogramowania, mając na uwadze dług technologiczny
• Są mentorami dla programistów
• Sprawują nadzór nad tym, co ważne dla firmy, mając na uwadze politykę firmy
• Poszerzają, pogłębiają i odnawiają zasób własnej wiedzy, ponieważ branża rozwija się w zawrotnym tempie

Ja nazywam takich ludzi architektami oprogramowania, ale nazywaj ich, jak chcesz. W 2021 roku byłem skoncentrowany tylko na tym, aby stać się świetnym architektem oprogramowania. W tym artykule dam ci kilka wskazówek i pokaże ci czego się nauczyłem. Roku 2022! Przybywaj!

Upewnij się, że przede wszystkim jesteś programistą

Czy widziałeś kiedyś sędziego, który nie był wcześniej prawnikiem? Architekci to w głębi serca dobrzy i doświadczeni programiści. Są przyzwyczajeni do problemów, z którymi wielu innych programistów boryka się na co dzień.

Architekt nie może tracić kontaktu z tym, co programiści uważają za ważne. Musi mówić ich językiem. Łatwość utrzymania jest najważniejszym czynnikiem wpływającym na koszty IT, dlatego musisz projektować z myślą o programistach.

Architekci, którzy zapominają o swoich korzeniach, tracą szacunek u zespołu. Skutecznie stają się oni wychwalanymi kierownikami projektów, a nikt już nie potrzebuje kolejnego kierownika.

Aby nie stać się architektem bez serca, należy poświęcić trochę czasu na:

• Wypróbowanie z programistami nowych lub innych technologii
• Czytanie treści związanych z tworzeniem oprogramowania. W formie kursów, filmów na YouTube, konferencji, webinarów itp.
• Tworzenie hobbystycznych projektów rozwoju

Uniż się w pokorze

Może ci się wydawać, że jesteś najbystrzejszym programistą, który kiedykolwiek przyłożył ręce do klawiatury. I masz umiejętności, aby to zaprezentować. Świetna robota, zdobyłeś złoto na Olimpiadzie największego Ego! No i co teraz?

Istnieje kilka subtelnych różnic pomiędzy programistami a architektami. Jedną z najważniejszych umiejętności, które muszą posiadać architekci, jest Komunikacja, przez duże K. Możesz posiadać eleganckie lub sprytne rozwiązanie problemu, ale czy potrafisz to przekazać interesariuszom i programistom w sposób przyjemny i jednocześnie skuteczny? Twój zespół gardzi Tobą, zazdrości Ci, czy może cię podziwia? Ten nowy inżynier w Twoim zespole, czy nadąża za tempem? Powinieneś stale zadawać sobie te pytania.

Niektóre wskazówki, których mogę ci udzielić to:

• Pozwól na włączenie się innych do głównych decyzji architektonicznych. Staraj się doprowadzić do konsensusu wśród deweloperów w kwestii decyzji technicznych.
• Pozwól programistom na samodzielność, podejmowanie własnych decyzji i popełnianie błędów. Zachowaj równowagę między ryzykiem a możliwościami nauki.
• Nadejdzie taki dzień, kiedy programista będzie od Ciebie lepszy w jakimś aspekcie. Zaakceptuj to. Pomóż im dostać się na szczyt!
• Mów z entuzjazmem o swojej pracy. I ich pracy!
• Bierz więcej odpowiedzialności, dawaj więcej pochwał

Jeśli coś zaprojektujesz, powinieneś być w stanie to zbudować

Pisanie odpowiedniej ilości dokumentacji to dobra umiejętność, którą warto posiadać. Zbyt mało specyfikacji i nikt poza Tobą nie zrozumie systemu. Zbyt dużo specyfikacji i zmiana systemu staje się kosztowna. Znalezienie punktu optymalnego zależy od projektu i zespołu, jednak jako architekt powinieneś o tym wiedzieć.

Bardzo łatwo jest dać się ponieść wymyślnym narzędziom i technikom diagramowania. Koniec końców nie ma to znaczenia, chyba że masz coś rzeczywiście do zaprezentowania. Wolę stosować praktyki wyszczuplonej dokumentacji, takie jak te zalecane w Modelu C4. Firmy pełne energicznych, zdolnych inżynierów również wydają się tutaj zgodne.

Jedną z kluczowych zasad, do której powinieneś się stosować: jeśli coś zaprojektujesz, powinieneś być w stanie to zbudować. A przynajmniej te najważniejsze fragmenty. Głupotą jest projektowanie systemu, którego nie jesteś w stanie zaimplementować. Twoim zadaniem, jako architekta, jest zrozumienie następstw podejmowanych decyzji technicznych i wytycznych, które stworzyłeś. Być może wiedza teoretyczna pozwoli Ci zajść daleko, to jednak nic nie pobije kogoś, kto jest w stanie praktycznie wykonać swoją pracę. Jeśli nie wiesz, czy jesteś w stanie to zrobić: Krok 1. Stwórz prototyp…

Pobrudź sobie ręce

Badania wykazały, że architekci powinni być praktyczni i powinni też pisać kod. Wielu ekspertów również zgadza się w tej kwestii. Myśląc o projekcie oprogramowania, sugeruję, aby architekci zaangażowali się w projekt. Może to oznaczać:

• W przypadku projektów typu greenfield należy wspierać zespoły przy pomocy Spacerującego Szkieletu
• Napisz testy jednostkowe architektury lub inne funkcje fitness dla swoich projektów
• Uczestnictwo we wzajemnych ocenach
• Refaktoryzacja kodu dla lepszego designu
• Napisz kilka nowych funkcji

Nie tylko polepsza to Twoje własne umiejętności, ale także pomaga budować lepsze relacje z programistami. Zamiast kierować ludźmi przez autorytet, kieruj nimi, dając przykład.

Wnioski

W tym artykule omówiłem kilka porad, które udało mi się zebrać w ciągu ostatniego roku. Głównymi punktami były: doskonalenie swoich umiejętności technicznych oraz bycie pokornym i pomocnym liderem. Mam nadzieję, że te wskazówki okażą się dla Ciebie pomocne, a także, że uda mi się to robić raz do roku.

Oryginał tekstu w języku angielskim przeczytasz tutaj.