Architekt oprogramowania – pytania rekrutacyjne + odpowiedzi

Na fali zjawiska inflacji stanowisk nietrudno o to, aby definicje, zadania i obowiązki, ale też warunki zatrudnienia poszczególnych stanowisk, zwłaszcza kierowniczych w IT się zacierały. Dziś na tapet weźmiemy Architekta Oprogramowania – specjalizację, której charakterystyka w zależności od organizacji może się różnić, ale zawsze powinna mieć szereg wspólnych mianowników. Te z kolei przekładają się na przebieg rekrutacji oraz najczęściej zadawane pytania. Te publikujemy wraz z odpowiedziami.

Architekt oprogramowania – kim jest?

Jedną z rzeczy, którą z całą pewnością możemy (lub powinniśmy, bo z implementacją stanowiska w rzeczywistych procesach już w konkretnych firmach może bywać różnie) jest ta, że jest to wymagające dużej odpowiedzialności stanowisko kierownicze. Nie będzie przesady w twierdzeniu, że w procesie produkcji oprogramowania odpowiedzialność architektowi oprogramowania można przypiąć w zasadzie za wszystko.

Oczywiście przede wszystkim wymagane jest od niego możliwie jak największe i – co kluczowe – jak najbardziej zróżnicowane doświadczenie w programowaniu. Najczęściej zdarza się, że na stanowisko Architekta oprogramowania poszukiwani są doświadczeni team leadzie o specyficznej cesze – nie są ekspertami w swoim stosie technologicznym, lecz mają szerokie doświadczenie pracy z różnymi językami programowania, bazami danych, frameworkami i innymi narzędziami deweloperskimi.

Architekt oprogramowania – wymagania

Takie wymagania są determinowane przez to, że to właśnie na Architekcie oprogramowania spoczywa między innymi ten obowiązek, aby dokonać możliwie jak najlepszego doboru technologii do konkretnego przedsięwzięcia. Oczywiście zakres podejmowanych projektów najczęściej wynika ze specjalizacji określanych przez sam zespół czy w ogóle software house, ale w przypadku Architekta, im większe doświadczenie w im większej liczbie stosów, tym lepiej. 

By zostać dobrym Architektem, nie wystarczy być świetnym seniorem np. tylko w Javie. Ba, nie wystarczy nawet duże doświadczenie na front-endzie czy back-endzie. Od Architekta wymaga się na ogół więcej, myślenia holistycznego o całym projekcie i to nie tylko od strony technicznej, ale też biznesowej. Kompetencje techniczne to bowiem dopiero początek, a w zasadzie jeden z filarów umiejętności Architekta oprogramowania. Nie mniej ważne jest doświadczenie i wysokie kwalifikacje w umiejętności identyfikowania potrzeb klienta.

Osobną kwestię stanowi umiejętność zarządzania. I choć obowiązki bezpośredniego zarządzania zespołem programistycznym spoczywają zazwyczaj na team leadach czy tech leadach, tak Architekt oprogramowania często stoi przed trudnym zadaniem przekonania programistów, że wybrane przez niego technologie będą odpowiednie dla danego projektu. Bez wysokich kompetencji w zakresie zarządzania i rozwiniętych umiejętności się więc nie obędzie.

Dobrego podsumowania, opartego zresztą na własnym doświadczeniu dokonał swojego czasu na łamach Readme dokonał Nikolay Ashanin. Zwrócił on uwagę, że do obowiązków architekta należy nie tylko wspominane już identyfikowanie potrzeb i wymagań biznesowych, ale przede wszystkim projekt całego systemu, wybór architektury i technologii z dokładnością w zasadzie do jednego jej elementu wysokopoziomowego. Co ważne, obok standardowego code review, Architekt dokonuje także, i to jest dla niego charakterystyczne, architecture review.

Architekt oprogramowania – pytania rekrutacyjne + odpowiedzi

Jeśli uważasz, że spełniasz te warunki i wykazujesz wspominane cechy, to czas przejść do przebiegu rozmowy rekrutacyjnej. Rzecz jasna, nie inaczej niż w przypadku innych stanowisk IT, jest ona podzielona na etapy. Ich liczba i charakter będą się zapewne różniły w zależności od organizacji, jednak podobnie jak w przypadku zakresu samych obowiązków, tak i tutaj możemy wskazać dwa etapy, których spodziewać można się zawsze.

Pierwszym z nich będzie ogólna rozmowa, która w przypadku Architekta oprogramowania, może mieć znacznie większe znaczenie, niż w przypadku innych specjalizacji. To podczas niej sprawdzane będą, jak już sobie wyjaśniliśmy, kluczowe dla tej roli umiejętności interpersonalne, umiejętność negocjacji i nastawienie do pracy zespołowej. Drugi etap to weryfikacja kompetencji technicznych, przy czym nie należy się spodziewać, że będziemy tu już mieli do czynienia z pytania o cechy poszczególnych języków czy charakterystykę frameworków, z jakimi do czynienia można mieć w przypadku rekrutacji na stanowiska stricte developerskie. Czego się więc spodziewać?

Czym jest SOLID?

Nie jest to jedna rzecz, lecz pięć – akronim ma tu funkcję taką, że za każdą literą stoi jedno pryncypium. I tak: S jest od single-responsibility. Oznacza to tyle, że nie powinno być sytuacji, kiedy wprowadzenie jednej klasy ma więcej niż jedno uzasadnienie. O z kolei oznacza otwartość na rozszerzalność, przy czym mowa o rozszerzalności, a nie o możliwości zmieniania. L nawiązuje do Barbary Liskov, które zauważyła, że funkcje wykorzystujące wskaźniki, muszą wykorzystywać obiekty wyższych klas, nie znając ich. I to interfejs – użytkownicy nie muszą się przecież na tym znać, więc powinni polegać na tych interfejsach, które już znają. I w końcu D – od odwrócenia zależności.

W jakich przypadkach warto wciąż korzystać z architektury monolitycznej?

Przede wszystkim dlatego, że łatwo w porównaniu do mikorusług ją rozwijać. W przypadku mikrousług każdą z nią trzeba znać, a to niekiedy wymaga to angażowania w projekt kolejnych developerów. W monolicie zaś sprawy mają się inaczej. Całość aplikacji funkcjonuje w ramach jednej bazy kodu, nie ma potrzeby polegania na czymkolwiek zewnętrznym. Ta zaleta może się w części przypadków okazać ważniejsza, niż duża wielkość kodu, utrudnienia w implementacji nowych funkcji czy to, że pojedynczy błąd może zaszkodzić stabilności bazy kodu i przełożyć się na „wywracalność” całej aplikacji.

Czym jest i jakie zalety ma architektura SN?

SN to skrót od shared-nothing. To zagadnienie związane już bardziej związane ze sprzętem, mimo to warto je znać, jest wykorzystywane przez największe korporacje w branży.  Chodzi tutaj o rozproszenie – workloady są tu odseparowane od siebie. Każdy proces dysponuje własnym CPU, pamięcią operacyjną i masową. Taka architektura pozwala, aby jakiekolwiek zmiany zachodziły niezależnie między sobą pomiędzy poszczególnymi węzłami architektury. Celem jest eliminacja tzw. single point of failure (SPOF), czyli takich sytuacji, kiedy stabilność całego systemu jest uzależniona od stabilności pojedynczego punktu. 

Jakie są zalety stosowania architektury bazującej na komponentach?

Zaletą stosowania architektury bazującej na komponentach jest to, że poszczególne elementy będą przydatne niezależnie od aplikacji. W skrócie – mogą się przydać na przyszłość. W odróżnieniu od wspomnianego już monolitu, mamy tu do czynienia z zasobami wielokrotnego użytku, nie ma potrzeby pisania zawsze wszystkiego od nowa. Korzyści są także po stronie klienta – wycena jego zlecenia może być obniżona właśnie przez ten czynnik, że software house czy zespół developerski już dysponuje elementami niezbędnymi do zrealizowania danego projektu. 

W czym może się okazać przydatne dependency injection?

Dependency incjetion, czy też wstrzykiwanie zależności, to rzecz wynikająca bezpośrednio z omawianych już zasad SOLID, ale też związana z modułowością architektury. Jest to taka architektura, która możliwie jak najbardziej eliminuje bezpośrednie zależności pomiędzy poszczególnymi komponentami. W praktyce oznacza to, że wszystkie obiekty przekazują metody i właściwości niżej. Podejście to można porównać do Brzytwy Ockhama – nie należy tworzyć bytów ponad potrzebę. Jeśli można coś przekazać, to należy to przekazać, a nie tworzyć nowe parametry niezależnie, w różnych komponentach.

Bonus

Zamiast podsumowania, zachęcamy do lektury ciekawego artykułu, który na praktycznym, życiowym przykładzie wyjaśnia jak zostać Software Architektem.