Software architecture

Słyszałeś o pojęciu “wąskie gardło”? Nie wiem jakie masz skojarzenia, natomiast wyobraź sobie typową sytuację w pracy gdzie jest zespół kilku developerów, oraz architekt i/lub tech leader.

W projekcie, jak to w projekcie są proste zadania i są też takie mega trudne i krytyczne dla całego projektu. Architekt bierze na siebie ten mega trudny task i nad nim pracuje. Przecież jest architektem to musi robić najtrudniejsze rzeczy, a jak ma przerośnięte ego to tym bardziej. Kto to zrobi lepiej niż on?

Z trudnymi taskami jest zazwyczaj tak, że są trudne, bardzo trudne (nawet bardzo bardzo) i potrzeba dużo czasu aby je wykonać, a problem jaki pojawia się w pracy architekta nadzwyczaj często jest taki, że on nie może na te trudne zadanie poświęcić sto procent czasu, ponieważ ma też inne obowiązki (często kilka projektów).

Właśnie tutaj pojawia się pułapka, którą nazwałem “wąskie gardło”. Czas leci, inni czekają aż architekt skończy to co zaczął, bo to co robi blokuje innych. Frustracja narasta u każdego i robi się nerwowo. Nie jest to oczywiście sytuacja bez wyjścia, kiedyś w końcu to dowiezie, pomimo tego po co tyle stresu? Czy nie można tego zrobić jakoś inaczej?

---

Zaufanie do zespołu developerskiego

Architekt nie jest w zespole po to żeby się wymądrzać, tylko po to żeby pomagać (tzn nie przeszkadzać i nie blokować pracy). Ewolucja od developera do architekta jest trudna i ma kilka aspektów. Jednym z nim jest coś takiego:

To, że byłeś super programistą i rozwiązywać najtrudniejsze problemy już się nie liczy. Odkąd jesteś architektem, jesteś oceniany pod kątem tego jaką wartość (i jakość) dostarcza zespół z którym pracujesz, a nie pod kątem tego co potrafisz zrobić w pojedynkę.

Podsumowując, architekt zamiast siedzieć nad czymś dniami i nocami staje się konsultantem i mentorem dla swojego zespołu i pomaga im się rozwijać tak aby mogli dostarczyć projekt spełniający wymagania biznesowe oraz atrybuty jakościowe.

Nie będę tutaj poruszał tematu, czy taki model pracy ma sens bo to temat na osobny artykuł, natomiast jest to powszechny model pracy spotykany w firmach technologicznych.

Gdy architekt zaufa zespołowi i stworzy im środowisko do pracy, a z czasem zespół zobaczy, że to naprawdę pomaga w pracy to znika problem wąskiego gardła, a praca jest bardziej efektywna i przyjemna.

Czy architekt w ogóle programuje?

Możesz sobie pomyśleć, że taki architekt to już w ogóle nie programuje, bo zajmuje się innymi rzeczami. Poniżej pokażę Ci jak architekt w dalszym ciągu ma szansę programować, nie blokująć przy tym zespołu.

Architekt, który nie programuje, traci kontakt z rzeczywistością. Nie możesz do tego dopuściuć.

Proof of concepts

Tak zwane POCe czyli pisanie kodu po to, żeby zwalidować decyzje architektoniczne, w których trzeba napisać konkretny kod  są idealne dla architektów żeby coś zaprogramować, Dobrym podejściem przy robieniu POCów jest to, aby kod był wysokiej jakości (w zasadzie production-ready), udokumentowany i pokryty testami. Taki POC wnosi wtedy konkretną wartość do projektu.

Walka z długiem technicznym

Jeśli w projekcie jest jakiś dług techniczny to jest to świetny obszar dla architekta, aby wziąć na warsztat jakiś konkretny problem, wymyślić rozwiązanie i od razu to poprawić.

Code review

Może na code review architekt nie napiszę kodu, pomimo tego przeglądanie czyjegoś kodu jest angażujące i pozwala być bliżej kodu i zespołu.

Pair programming

Programowanie z kimś w parze pozwala architektowi programować, a zarazem uczyć tą drugą osobę i pokazywać swój sposób pracy(przy okazji nauczyć się czegoś od tej drugiej osoby). Ma to też dodatkowy plus polegający na tym, że wspólna praca świetnie integruje ludzi.

Automatyzacja developmentu

Tworzenie narzędzi typu CLI, które w jakiś sposób mogą przyspieszyć pracę programistów i ułatwić im życie to kolejna rzecz, którą może robić architekt.

---

Podsumowanie

To, czy architekt jest wąskim gardłem w zespole, zależy głównie od niego, ale również od innych czynników. Jednym z takich czynników jest dostępność narzędzi i technologii, które umożliwiają szybsze i bardziej efektywne projektowanie.

Innym ważnym czynnikiem jest zrozumienie wymagań projektowych i biznesowych przez cały zespół, a nie tylko przez architekta. Współpraca między deweloperami i architektami może być kluczowa dla sukcesu projektu, ponieważ pozwala na wymianę wiedzy i doświadczeń, a także na wzajemne zrozumienie i zaufanie.

Dlatego warto inwestować w budowanie dobrych relacji między członkami zespołu i tworzenie warunków do efektywnej pracy.

Efektywny architekt oprogramowania

Rób te rzeczy aby być efektywnym archiektem opgrogramowania:

• Działaj jako konsultant i mentor dla zespołu, pomagając mu rozwijać się i dostarczać projekt zgodny z wymaganiami biznesowymi i jakościowymi.

• Zaufaj zespołowi i stwórz im środowisko pracy, które pozwoli im zobaczyć korzyści z Twojej pomocy.

• Weź odpowiedzialność za spłacanie długu technicznego.

• Przeprowadzaj regularnie code review.

• Organizuj pair programming, aby pokazywać swój sposób pracy oraz aby wspólna praca integrowała zespół.

• Twórz narzędzia ułatwiające pracę programistom.

• Weryfikuj decyzje architektoniczne poprzez pisanie kodu.

• Dbaj o dokumentację i przepływ wiedzy