Co musi umieć Architekt?

1

Były już tematy co musi umieć Junior/Senior, zastanawia mnie jednak co musi umieć architekt? Czy obecni na forum architekci mogą podzielić się jakie obowiązki pracy do nich należą? Jak wygląda ich dzień pracy? Z jakich głównie narzędzi korzystają? Na czym należy się skupić jeżeli chce się iść w tym kierunku?

3

Tylko o jakiego architekta chodzi? Data Architect? Software Architect? Network Architect? Landscape Architect :E?

0

Tu konkretnie chodziło mi o Software Architect, ale jeżeli ktoś ma doświadczenie w innych dziedzinach to też może się wypowiedzieć.

4

Definicja
Software Architekt - to idiotyczny tytuł wymyślony w idiotycznych korpo żeby ustawiać ludzi w ich idiotycznych drabinkach.

**Co musi umieć? **
To co napisane w idiotycznych wymaganiach na dane stanowisko w danym idiotycznym korpo.

Ogólnie przy tworzeniu software liczy się KOD. Nie ważne czy pisze ten kod osoba z przedrostkiem software architekt czy junior developer. Liczy się wiedza i umiejętności tej danej osoby.

Każdy programista powinien rozwijać się tak, aby bardziej rozumieć proces tworzenia oprogramowania. Pisać lepszy i skuteczniejszy kod. Jednak tak samo jak nie można porównywać junior developera z Comarchu i Netflixa. Tak samo nie ma jednej definicji Software Architekta.

W dobrej firmie nie ma głupich drabinek i wszyscy programiści kodzą. W średnich firmach drabinki są, ale architekt kodzi razem z zespołem. W idiotycznych korpo architekt nie kodzi i siedzi w wieży, ale jakie są wymagania pytaj HR tego korpo.

1

W dobrej firmie nie ma głupich drabinek i wszyscy programiści kodzą. W średnich firmach drabinki są, ale architekt kodzi razem z zespołem. W idiotycznych korpo architekt nie kodzi i siedzi w wieży, ale jakie są wymagania pytaj HR tego korpo.

A w najgorszych firmach( projektach) architekt znowu kodzi, ale w wieży. I niestety do tego samego repo co zespół.

10
nie100sowny napisał(a):

Definicja
Software Architekt - to idiotyczny tytuł wymyślony w idiotycznych korpo żeby ustawiać ludzi w ich idiotycznych drabinkach.

**Co musi umieć? **
To co napisane w idiotycznych wymaganiach na dane stanowisko w danym idiotycznym korpo.

Ogólnie przy tworzeniu software liczy się KOD. Nie ważne czy pisze ten kod osoba z przedrostkiem software architekt czy junior developer. Liczy się wiedza i umiejętności tej danej osoby.
W dobrej firmie nie ma głupich drabinek i wszyscy programiści kodzą. W średnich firmach drabinki są, ale architekt kodzi razem z zespołem. W idiotycznych korpo architekt nie kodzi i siedzi w wieży, ale jakie są wymagania pytaj HR tego korpo.

Sorry, raczej nie masz pojęcia na czym polega praca architekta.

Nieprawdą jest, że liczy się wyłącznie KOD. To tak jak napisać, że przy budowie domów liczą się wyłącznie cegły. Doświadczenie pokazuje, że są domy drewniane, domy z prefabrykatów, nawet możesz sobie zaadaptować do potrzeb mieszkania przyczepę albo zamieszkać w wigwamie i być zadowolonym. Wszystko zależy od potrzeb klienta. Do architekta należy stworzenie rozwiązania problemu, który tego klienta zadowoli - czyli wybór czy ma to być dom mały, duży, przenośny czy stabilny, czy stoi na obszarach aktywnych sejsmicznie, czy w ogóle ma stać, a nie latać, pływać albo jeździć, czy ma znosić silne wiatry, albo wysoką temperaturę.

Do podobnych rzeczy sprowadza się praca architekta oprogramowania. Ma znaleźć techniczne rozwiązanie problemu, cokolwiek by to nie znaczyło. Jak architekt jest słaby, to od razu bezmyślnie zapędzi wszystkich do KODZENIA. A jak jest dobry, to może się okazać, że rozwiązanie można uzyskać bez napisania linijki kodu, bo wszystkie komponenty potrzebne do rozwiązania problemu istnieją w postaci bibliotek, frameworków albo gotowych rozwiązań biznesowych, które trzeba jedynie spiąć w kupę z minimalną adaptacją. Ale do architekta należy też ocena czy te rozwiązania są są wystarczająco szybkie, skalowalne, odporne na ataki, na problemy zewnętrzne, i czy nie wygenerują problemów w przyszłości. Architekt decyduje, z czego warto skorzystać, a co stworzyć samodzielnie, a jeśli stworzyć to w jaki sposób - w jakim języku, jaką architekturę zastosować, jakie technologie. Dopiero jak odpowie się na te pytania, można przystąpić do KODZENIA, jeśli ma to w ogóle sens. A sam architekt, nie musi kodzić, taka jak nie musi osobiście kłaść cegieł przy budowie domu, który zaprojektował. Ma natomiast służyć pomocą w rozwiązywaniu problemów programistów, którzy nie mają całościowego oglądu problemu, a jedynie rozumieją jakąś tam swoją działeczkę.

2
Mateusz napisał(a):

Były już tematy co musi umieć Junior/Senior, zastanawia mnie jednak co musi umieć architekt? Czy obecni na forum architekci mogą podzielić się jakie obowiązki pracy do nich należą? Jak wygląda ich dzień pracy? Z jakich głównie narzędzi korzystają? Na czym należy się skupić jeżeli chce się iść w tym kierunku?

architekt musi umiec przyjsc na rozmowe rekrutacyjna i zaptac kandydata na juniora czy te petle foreach to na pewno tak dzialaja w javie, bo jak on zaczynal to nie bylo czegos takiego

historia autentyczna

7

Nie jestem architektem, ale mamy świetnego architekta i jego zadania polegają na tym aby:

  • projektować / dobierać architekturę do rozwiązywanego problemu (ok, na to było trudno wpaść)
  • wiedzieć, co się dzieje w każdym komponencie produktu, ogarniać całość, bez szczegółów, ale wystarczająco szczegółowo, aby rozumieć co się da zrobić, a czego nie
  • pomagać w planowaniu i organizacji pracy, aby nie było sytuacji, że jeden zespół buduje dach, podczas gdy sypią się fundamenty
  • pomagać w wyborze technologii / frameworków / bibliotek wpływających na cały projekt
  • pomagać przy podejmowaniu decyzji mogących mieć długofalowy wpływ na projekt i ubijać głupie pomysły w zarodku (np. "użyjmy Springa", albo "przepiszmy to na Mongo")
  • służyć doświadczeniem w rozwiązywaniu trudnych problemów na styku różnych zespołów
0
nie100sowny napisał(a):

Ogólnie przy tworzeniu software liczy się KOD. Nie ważne czy pisze ten kod osoba z przedrostkiem software architekt czy junior developer. Liczy się wiedza i umiejętności tej danej osoby.

Oczywiście, że nie jest ważne, jaki tytuł ma człowiek który napisał dany kawałek kodu o ile tylko spełnia on założenia.
Ale jest pewien problem tutaj. Mianowicie liczba wymagań niefunkcjonalnych rośnie wraz z wielkością firmy oraz stopniem skomplikowania projektu. Przy czym zdarzają się właśnie takie wymagania, które OD POCZĄTKU trzeba spełniać, bo w innym wypadku twój software nie jest nic warty. Ot, np. budujesz typowego CRUDa biznesowego.
Polityka bezpieczeństwa zabrania wysyłać wrażliwe dane klientów poza backend. Jakiś junior tego nie wiedział i wysyła np. numer PESEL do przeglądarki gdzie jest on wykorzystywany do szeregu rzeczy.
Przy wdrażaniu apka nie przechodzi audytu bezpieczeństwa, trzeba przerobić wszystko. I wtedy "beknie" w pierwszej kolejności software architect. Takich rzeczy, które wpływają na kod ale o których dobry programista wiedzieć nie musi jest multum.

W dobrej firmie nie ma głupich drabinek i wszyscy programiści kodzą. W średnich firmach drabinki są, ale architekt kodzi razem z zespołem. W idiotycznych korpo architekt nie kodzi i siedzi w wieży

Dużo zależy od typu architekta.

0

Wejdź sobie na portal z ogłoszeniami i poszukaj ofert dla architektów z zakresem obowiązków. Najbardziej 'architektowy' to solution architect po części opisany w postach wyżej.

3

Nie jestem architektem, ale mamy świetnego architekta i jego zadania polegają na tym aby:

  • projektować / dobierać architekturę do rozwiązywanego problemu (ok, na to było trudno wpaść)

Mi by było trudno na to wpaść, bo niestety mam takich architektów i dobierają mi innym architektury do problemów. Niedowidzi, niedosłyszy, ostatni raz kodował XML w javie 1.3, ale usłyszał, że teraz modna kafka i wszystko trzeba robic streamowo i eventowo.
Przez to muszę teraz z sąsiednim zespołem wymieniać dane przez JMS na Websphere MQ (bo jednak kafki się przepchnąć nie udało przez dział infrastukrury). Do tego komunikaty lecą przez dwie kolejki - z jednej nasłuchuję, na drugiej puszczam ACK... Albowiem, w tym przypadku biznesowo i technicznie, proces który obśługujemy jest czysto synchroniczny i trzeba zaczekać na odpowiedź ...(TADAAAM!!!).
(Przynajmniej mieliśmy trochę śmiechu z kolegą z drugieg teamu, jak przeczytaliśmy specyfikację i ogarnęliśmy nonsens tego rozwiązania)
Dla odmiany mamy też dużo komunikacji gdzie przydały by się asynchroniczne kolejki, ale tam akurat mamy SOAPa - bo drugi architekt nie był na tej konferencji, gdzie o tych eventach mówili.

Wole zasadę - nie koduje, to się nie wpie....
Wolę jak architekt służy jako recenzent - niech powie gdzie widzi wady i zalety rozwiązania i jakie są cele. Ale to zespół kodujący powinien podejmować pewne decyzje (i je zmieniać w razie problemów). Jak mu jakieś rozwiązanie przeszkadza (często) to ma powiedzieć dlaczego i jaki cel to psuje - wtedy może da się znaleźć kompromis w miarę akceptowalny dla wszystkich.

W praktyce, najczęściej jednak, taki architekt po zapytaniu dlaczego odsyła mnie do wyższej instancji... itd. itd. czasem udaje się zatoczyć nawet kółko.

W reszcie punktów w zasadzie się zgadzam.

1

Prawda jest taka, że KOD jest na ostatniom miejscu u ziomków typu "nie programista". To raczej naturalne, bo inni mają inne zmartwienia niż programiści :-)
Doświadczony życiem architekt^W człowiek to wie i nie przywiązuje wagi do tego jak nazywa się rola, którą pełni.

Role można sobie nazywać wedle uznania: architekt, doświadczony projektant programista, uber-ninja, masta-fulstack, wiodący programista itd.
Chciałoby się powiedzieć: "Pokaż mi efekty swojej pracy, a powiem Ci kim jesteś."

Co jest produktem pracy osoby pełniącej rolę "architekta oprogramowania"? Subiektywnie:

  • projekt systemu osadzony w szerszym kontekście (lub jak kto woli rozwiązanie End-2-End, albo żeby "produkt był później używalny")
  • decyzje (np. dobór technologii, zdjęcie z młodego programisty zmartwienia "Jr: malujemy na zielono, czy na czerwono? Architekt/senior/lead/whatever: na żółto!" )
  • kadłubek/szkielet kodu
  • rozwiązanie klasy "proof of concept"
  • plan etapów pośrednich ( "milestony", "architektury pośrednie", "roadmapy")
  • konwencje różnej maści (formatowania kodu, nazewnictwa komponentów, wersjonowania, releasów, ... )

Co powinien umieć:

  • rozmawiać z ludźmi
  • rozumieć problemy, które chcą rozwiązać
  • upraszczać rozwiązanie i umieć powiedzieć "NIE!" (i uzasadnić to)
  • proponować różne warianty, wraz z analizą "na plus/minus" (pros/cons)
  • być pośrednikiem między różnymi grupami zainteresowanych
  • prezentować problemy/rozwiązania na różnym poziomie szczegółowości (odpowiednio dobranym do grupy docelowej)
  • zarządzać wymaganiami i produktami zespołu programistów
  • znać technologie i ich mocne/słabe strony
0

Z moich obserwacji:

  • obsługiwać wiki, worda i excela
  • wysyłać maile
  • malować wykresy i diagramy
  • organizować spotkania i chodzić na spotkania (czasem on-line)
  • gadać z ludźmi
  • gadać na czatach on-line
  • w sumie programować już nie musi umieć, bo i tak tego nie robi

Po obserwacji tego, czym zajmują się architekci, których do tej pory poznałem, powiem szczerze, że jest to chyba taka korpo-rola i średnio miałbym ochotę coś takiego robić. Plusem może być to, że taki architekt pewnie więcej zarobi, niż jakiśtam zwykły developer w tej samej firmie.

2
GutekSan napisał(a):
nie100sowny napisał(a):

Definicja
Software Architekt - to idiotyczny tytuł wymyślony w idiotycznych korpo żeby ustawiać ludzi w ich idiotycznych drabinkach.

**Co musi umieć? **
To co napisane w idiotycznych wymaganiach na dane stanowisko w danym idiotycznym korpo.

Ogólnie przy tworzeniu software liczy się KOD. Nie ważne czy pisze ten kod osoba z przedrostkiem software architekt czy junior developer. Liczy się wiedza i umiejętności tej danej osoby.
W dobrej firmie nie ma głupich drabinek i wszyscy programiści kodzą. W średnich firmach drabinki są, ale architekt kodzi razem z zespołem. W idiotycznych korpo architekt nie kodzi i siedzi w wieży, ale jakie są wymagania pytaj HR tego korpo.

Sorry, raczej nie masz pojęcia na czym polega praca architekta.

Nieprawdą jest, że liczy się wyłącznie KOD. To tak jak napisać, że przy budowie domów liczą się wyłącznie cegły. Doświadczenie pokazuje, że są domy drewniane, domy z prefabrykatów, nawet możesz sobie zaadaptować do potrzeb mieszkania przyczepę albo zamieszkać w wigwamie i być zadowolonym. Wszystko zależy od potrzeb klienta. Do architekta należy stworzenie rozwiązania problemu, który tego klienta zadowoli - czyli wybór czy ma to być dom mały, duży, przenośny czy stabilny, czy stoi na obszarach aktywnych sejsmicznie, czy w ogóle ma stać, a nie latać, pływać albo jeździć, czy ma znosić silne wiatry, albo wysoką temperaturę.

Do podobnych rzeczy sprowadza się praca architekta oprogramowania. Ma znaleźć techniczne rozwiązanie problemu, cokolwiek by to nie znaczyło. Jak architekt jest słaby, to od razu bezmyślnie zapędzi wszystkich do KODZENIA. A jak jest dobry, to może się okazać, że rozwiązanie można uzyskać bez napisania linijki kodu, bo wszystkie komponenty potrzebne do rozwiązania problemu istnieją w postaci bibliotek, frameworków albo gotowych rozwiązań biznesowych, które trzeba jedynie spiąć w kupę z minimalną adaptacją. Ale do architekta należy też ocena czy te rozwiązania są są wystarczająco szybkie, skalowalne, odporne na ataki, na problemy zewnętrzne, i czy nie wygenerują problemów w przyszłości. Architekt decyduje, z czego warto skorzystać, a co stworzyć samodzielnie, a jeśli stworzyć to w jaki sposób - w jakim języku, jaką architekturę zastosować, jakie technologie. Dopiero jak odpowie się na te pytania, można przystąpić do KODZENIA, jeśli ma to w ogóle sens. A sam architekt, nie musi kodzić, taka jak nie musi osobiście kłaść cegieł przy budowie domu, który zaprojektował. Ma natomiast służyć pomocą w rozwiązywaniu problemów programistów, którzy nie mają całościowego oglądu problemu, a jedynie rozumieją jakąś tam swoją działeczkę.

Do architekta należy
Jak architekt jest słaby
Ale do architekta należy
A sam architekt, nie musi kodzić

@GutekSan

Porównanie oprogramowania do domu jest jak kamieniem w płot.
W budowlance klient nie przychodzi Ci co drugi dzień i nie prosi o przestawienie pierwszego piętra z siódmym.

To co napisałeś brzmi tak jakby architekt miał z góry jak wyrocznia dobierać rozwiązania. Typowy korpo waterfall.
Dobre systemy powstają przez CIĄGŁĄ współpracę ZESPOŁU DEVELOPERSKIEGO z BIZNESEM przy procesie sterowanym METRYKAMI i szybkim FEEDBACKU. Jak widzisz architekt do niczego z powyższych nie jest potrzebny. Jak nie walczy z zespołem na linii frontu i nie uczestniczy w codziennej pracy to lepiej niech zniknie. Zakładam również, że nowoczesny zespół developerski posiada wszystkie kompetencje i wiedzę potrzebną do decydowania o rozwiązaniach oraz posiada swobodę w działaniu.

Widocznie piszesz o firmie gdzie jakaś banda juniorów jest rządzona przez guru z latami doświadczenia w projekcie fixed price.

1

GutekSan
Jak architekt jest słaby, to od razu bezmyślnie zapędzi wszystkich do KODZENIA. A jak jest dobry, to może się okazać,
że rozwiązanie można uzyskać bez napisania linijki kodu, bo wszystkie komponenty potrzebne do rozwiązania problemu
istnieją w postaci bibliotek, frameworków albo gotowych rozwiązań biznesowych, które trzeba jedynie spiąć w kupę z minimalną adaptacją.

Ale to o czym piszesz to chleb codzienny normalnego developera (a przynajmniej od mida w górę, bo może junior jeszcze tego nie ogarnie), żeby czasem przystanąć i zobaczyć czy nie da się zrobić czegoś prościej, czy nie można użyć czegoś, co już jest.

Czyli co, architekt to taki po prostu mid/senior developer?

Ale do architekta należy też ocena czy te rozwiązania są są wystarczająco szybkie, skalowalne, odporne na ataki,
na problemy zewnętrzne, i czy nie wygenerują problemów w przyszłości.

Czyli taki senior developer.

Dopiero jak odpowie się na te pytania, można przystąpić do KODZENIA, jeśli ma to w ogóle sens.

To się nazywa zdrowy rozsądek, żeby najpierw myśleć a potem robić (pomijając eksperymenty czy prototypy). Sugerujesz, że architekt to jedyna osoba w zespole, który posiada zdrowy rozsądek? Coś słabe muszą być to zespoły.

0

Gdy nad projektem pracuje jeden, może dwa zespoły to rzeczywiście może się wydawać że architekt jest nie potrzebny i zespół samo ogarnie wszystkie decyzje. Gdy jest ich więcej, to jest potrzebny ktoś z poza kto będzie podejmować decyzje (decydujący głos, gdy zespoły mają różne pomysł itp.). W mojej firmie to architekci decydują z jakich technologi mamy korzystać, pilnują aby każda część projektu nie rozjechała się z resztą (technicznie), pilnują standardów jak i je ustanawiają jeśli trzeba. Jeśli ktoś ma pomysł na jakąś zmianę, która by wpłynęła również na resztę to architekt musi wyrazić zgodę na to jak i później pilnować tego aby wszyscy dokonali odpowiednich zmian.

Podsumowując, w mojej opinii czym większy projekt, tym architekt jest bardziej potrzebny, przy czym przy małych nawet nie potrzebny. Różni ludzi wpadają na różne pomysły i ktoś musi to kontrolować.

P.S.
Określenie "zespół ogarnie" również jest ciekawym określeniem, moje doświadczenie pokazuje że i tak to osoba lub dwie z największym doświadczeniem podejmują takie decyzje, a nie cały zespół. Co najwyżej wszyscy przytakną na propozycje. Demokracja działa tylko w przypadku gdy wszyscy mają to samo zdanie.

3

Pracowałem w wielkim korpo przez 3 lata jako Software Architect (.Net). Do moich zadań należało:

  • budowanie prototypów (design i wybór i test technologii)
  • implementacja szkieletu projektu
  • koordynacja teamó(w), np.1den team front w JS, 2gi backaned w C#, w różnych miastach
  • częściowa implementacja z teamem
  • organizowanie meeintgów do omawiania problemów i szukania rozwiązań architektonicznych
  • prowadzenie szkoleń, typu 1en nowy wzorzec projektowy w tyg, czy praktyki clean code, TDD
  • odp maile od managmentu, typu nowy klient zyczy sobie featureX, co musimy zrobić by nie przewróciło całej architektury do góry nogami i na kiedy
  • odpowiedzialność za zależności modułów, komponentów systemu i ich rozwój, baza kodu miała ok 4mln linii kodu, ponad 400dll
  • tworzenie wewnętrzych i zewnętrzych API i ich wersjonowanie
  • dokumentacja architektury w UML
  • ogarnianie klilu projektów jak powyżej

Teraz dla klienta na b2b robię podobne rzeczy, tylko mniej biurokracji i więcej kodowania samemu, bo mniejsza firma.

1

Polecam artykuł, choć są rzeczy, z którymi się nie zgadzam.
https://www.yegor256.com/2018/06/26/are-you-an-architect.html

1

Co musi umiec architekt?

Dobry architekt to taki architekt, który nie wie wszystkiego i nie boi sie zapytać ludzi, którzy wiedzą lepiej. Programistów, team leadów, sieciowców, adminów, itd. Dodatkowo musi umieć rozmawiać wspolnym językiem z biznesowymi stakeholderami i z ludzmi technicznymi, rozumieć co robi biznes i jak dostarczyć wartość przy użyciu dostępnych środków technicznych.

W skrócie, 60% skille miękkie, 40% techniczne.

2

Architekt niczego nie musi umieć. Jak już kiedyś napisałem.

Są trzy rodzaje architektów

  • dobrzy programiści, którzy awansowali w uznaniu za swoją wiedzę i umiejętności;
  • słabi programiści, którzy awansowali aby wreszcie przestali psuć kod;
  • ludzie z nominacji prezesa czy innego szefa, który obsadził wyższe stanowiska swoimi ludźmi.

Ci pierwsi nie muszą - oni po prostu umieją. Tym drugim umiejętności by tylko przeszkadzały w awansie. Trzeci nie potrzebują z definicji.

Ogólnie archiekt to taki wytrych słowny, który znaczy mniej niż senior. W zależności od firmy, klienta i projektu może to oznaczać skrajnie różny zestaw odpowiedzialności i zadań. Do tej pory w życiu pracowałem w takich kombinacjach:

  1. Jeden programujący architekt lat 26 na jednego programistę. Pomysły architekta: mapowanie ORM przez XML, wszystkie klasy statyczne.
  2. Trzech programujących architektów grubo poniżej trzydziestki na ok 40 programistów. Ich pomysły to: cała logika w kontrolerach, modelbidner wstawiający przychodzące requesty od razu do sesji NHibernate. Podczas przygotowań do wdrożenia okazało się, że mimo iż w założeniach każdy z 6 modułów miał działać na parze zloadbalancowanych serwerów, w praktyce nie miało to szans zadziałać przez niezbalansowanego serwice busa oraz zahardcodowane urle na localhost.
  3. Jeden architekt na 8 programistów. Czasami programował jakieś rzeczy infrastrukturalne, albo PoCe. Ten był bardzo ogarnięty i miał wiedzę zarówno technologiczną jak i projektową. Decydował o technologii, biblitekach i wyglądzie dosłownie wszystkiego, np. mówił programistom jakie mają być klasy i co w nich ma się znajdować. Programiści właściwie nie wykonywali pracy twórczej w tym projekcie, klepali tylko wg wytycznych architekta.
  4. Ta sama firma, podobne proporcje. Zadania architekta to głównie rozmowy z ludźmi po stronie klienta i uczestnictwo w planowaniu sprintu. Czasami robili jakieś PoCe, ale to i tak bez sensu. Nie mieli żadnej władzy ani w kwestii projektu ani doboru technologii, bo cała czternastowarstowa architektura i stos zostały zatwierdzone przez klienta.
  5. Firma porównywalna wielkością z Allegro, archiektów kilku (od mobile, od weba, od backendu, od integracji). Narzucają jakiś bardzo ogólny podział na mikroserwisy dla głównych ficzerów, dobór technologii na wysokim poziomie, czuwają nad eksperymentalnymi PoCami w nowych technologiach, ale generalnie nie ma potrzeby kontaktu z nimi. Programiści w zespołach sami dzielą na mikroserwisy, dobierają sobie stos i generalnie robią co chcą.
0
nie100sowny napisał(a):
GutekSan napisał(a):
nie100sowny napisał(a):

Definicja
Software Architekt - to idiotyczny tytuł wymyślony w idiotycznych korpo żeby ustawiać ludzi w ich idiotycznych drabinkach.

**Co musi umieć? **
To co napisane w idiotycznych wymaganiach na dane stanowisko w danym idiotycznym korpo.

Ogólnie przy tworzeniu software liczy się KOD. Nie ważne czy pisze ten kod osoba z przedrostkiem software architekt czy junior developer. Liczy się wiedza i umiejętności tej danej osoby.
W dobrej firmie nie ma głupich drabinek i wszyscy programiści kodzą. W średnich firmach drabinki są, ale architekt kodzi razem z zespołem. W idiotycznych korpo architekt nie kodzi i siedzi w wieży, ale jakie są wymagania pytaj HR tego korpo.

Sorry, raczej nie masz pojęcia na czym polega praca architekta.

Nieprawdą jest, że liczy się wyłącznie KOD. To tak jak napisać, że przy budowie domów liczą się wyłącznie cegły. Doświadczenie pokazuje, że są domy drewniane, domy z prefabrykatów, nawet możesz sobie zaadaptować do potrzeb mieszkania przyczepę albo zamieszkać w wigwamie i być zadowolonym. Wszystko zależy od potrzeb klienta. Do architekta należy stworzenie rozwiązania problemu, który tego klienta zadowoli - czyli wybór czy ma to być dom mały, duży, przenośny czy stabilny, czy stoi na obszarach aktywnych sejsmicznie, czy w ogóle ma stać, a nie latać, pływać albo jeździć, czy ma znosić silne wiatry, albo wysoką temperaturę.

Do podobnych rzeczy sprowadza się praca architekta oprogramowania. Ma znaleźć techniczne rozwiązanie problemu, cokolwiek by to nie znaczyło. Jak architekt jest słaby, to od razu bezmyślnie zapędzi wszystkich do KODZENIA. A jak jest dobry, to może się okazać, że rozwiązanie można uzyskać bez napisania linijki kodu, bo wszystkie komponenty potrzebne do rozwiązania problemu istnieją w postaci bibliotek, frameworków albo gotowych rozwiązań biznesowych, które trzeba jedynie spiąć w kupę z minimalną adaptacją. Ale do architekta należy też ocena czy te rozwiązania są są wystarczająco szybkie, skalowalne, odporne na ataki, na problemy zewnętrzne, i czy nie wygenerują problemów w przyszłości. Architekt decyduje, z czego warto skorzystać, a co stworzyć samodzielnie, a jeśli stworzyć to w jaki sposób - w jakim języku, jaką architekturę zastosować, jakie technologie. Dopiero jak odpowie się na te pytania, można przystąpić do KODZENIA, jeśli ma to w ogóle sens. A sam architekt, nie musi kodzić, taka jak nie musi osobiście kłaść cegieł przy budowie domu, który zaprojektował. Ma natomiast służyć pomocą w rozwiązywaniu problemów programistów, którzy nie mają całościowego oglądu problemu, a jedynie rozumieją jakąś tam swoją działeczkę.

Do architekta należy
Jak architekt jest słaby
Ale do architekta należy
A sam architekt, nie musi kodzić

@GutekSan

Porównanie oprogramowania do domu jest jak kamieniem w płot.
W budowlance klient nie przychodzi Ci co drugi dzień i nie prosi o przestawienie pierwszego piętra z siódmym.

Primo: prawidłowy związek frazeologiczny to "kulą w płot"
Secundo: To, że rozwój oprogramowania jest bardziej dynamiczny niż rozwój projektu w budownictwie nie stoi w sprzeczności z tym co napisałem o roli architekta. Wręcz przeciwnie, dowodzi że jego rola jest istotna, bo musi przewidywać tego typu zmiany i dobierać rozwiązania tak, by "przestawianie pięter" było możliwie sprawne.

To co napisałeś brzmi tak jakby architekt miał z góry jak wyrocznia dobierać rozwiązania. Typowy korpo waterfall.
Dobre systemy powstają przez CIĄGŁĄ współpracę ZESPOŁU DEVELOPERSKIEGO z BIZNESEM przy procesie sterowanym METRYKAMI i szybkim FEEDBACKU.

Jeśli dla Ciebie "systemem" jest serwis www, przy tworzeniu której udział bierze jeden zespół, a roboty jest na 3 miesiące, to tak - można to ogarnąć bez architektów. Tylko, że to nie jest żaden "system". Ja mówię o systemach składających się z kilku - kilkunastu podsystemów, które same również składają się z różnych elementów, które są rozproszone, są tworzone w różnych technologiach i językach. W takich sytuacjach zespoły deweloperskie nie współpracują z biznesem, bo to nie ma sensu, bo oczekiwania klienta wykraczają poza kompetencje jednego zespołu, tzw. "biznes" i zespół mówią innym językiem i nie doszliby do porozumienia. Rolą architekta jest analiza jakie podsystemy należy zmodyfikować aby zrealizować zamówienie klienta, podzielić zadanie na kawałki strawne przez zespoły i udzielać wsparcia tam, gdzie zadania się przenikają.

Jak widzisz architekt do niczego z powyższych nie jest potrzebny. Jak nie walczy z zespołem na linii frontu i nie uczestniczy w codziennej pracy to lepiej niech zniknie. Zakładam również, że nowoczesny zespół developerski posiada wszystkie kompetencje i wiedzę potrzebną do decydowania o rozwiązaniach oraz posiada swobodę w działaniu.

I to jest właśnie błędne założenie.

Widocznie piszesz o firmie gdzie jakaś banda juniorów jest rządzona przez guru z latami doświadczenia w projekcie fixed price.

Nie, piszę o firmach, które nie bawią się w "Mickey Mouse projects" typu serwis www, tylko poważne zadania wymagające kompetencji z odległych obszarów - w praktyce nierealne do zrealizowania przez 1 zespół, nawet składający się z samych wymiataczy.

1
LukeJL napisał(a):

GutekSan
Jak architekt jest słaby, to od razu bezmyślnie zapędzi wszystkich do KODZENIA. A jak jest dobry, to może się okazać,
że rozwiązanie można uzyskać bez napisania linijki kodu, bo wszystkie komponenty potrzebne do rozwiązania problemu
istnieją w postaci bibliotek, frameworków albo gotowych rozwiązań biznesowych, które trzeba jedynie spiąć w kupę z minimalną adaptacją.

Ale to o czym piszesz to chleb codzienny normalnego developera (a przynajmniej od mida w górę, bo może junior jeszcze tego nie ogarnie), żeby czasem przystanąć i zobaczyć czy nie da się zrobić czegoś prościej, czy nie można użyć czegoś, co już jest.

Czyli co, architekt to taki po prostu mid/senior developer?

Wszystko zależy od skali zadania. Mid/senior i architekt mogą zadawać sobie podobne pytania tylko w innej skali. Senior będzie zastanawiał się jak zaprojektować jakiś tam serwis, architekt będzie myślał jak zaprojektować system, w którym ten serwis jest zaledwie trybikiem, mającym swoją rolę, ale o istnieniu którego większość ludzi pracujących w projekcie może nawet nie wiedzieć.

Dopiero jak odpowie się na te pytania, można przystąpić do KODZENIA, jeśli ma to w ogóle sens.

To się nazywa zdrowy rozsądek, żeby najpierw myśleć a potem robić (pomijając eksperymenty czy prototypy). Sugerujesz, że architekt to jedyna osoba w zespole, który posiada zdrowy rozsądek? Coś słabe muszą być to zespoły.

Oprócz zdrowego rozsądku potrzeba jeszcze wiedzy i szerszego spojrzenia, którego zespołom, skupionym na implementacyjnych detalach, brakuje. I to nie oznacza, że te zespoły są słabe, jak sugerujesz, tylko że pracują nad obszernymi zagadnieniami.

0

Dla mnie wcześniej istniał taki oczywisty podział, że ktoś zaczyna jako junior i później staje się albo architektem (idąc w wiedzę specjalistyczną), albo staje się menadżerem (idąc w wiedzę z zarządzania). Ten wątek mnie oświecił, że to tylko z d**y wzięte etykietki, a wszystko brzmiało tak ładnie :(

0

GutekSan
Jeśli dla Ciebie "systemem" jest serwis www, przy tworzeniu której udział bierze jeden zespół, a roboty jest na 3 miesiące, to tak - można to ogarnąć bez architektów.
Tylko, że to nie jest żaden "system". Ja mówię o systemach składających się z kilku - kilkunastu podsystemów, które same również składają się z różnych elementów,
które są rozproszone, są tworzone w różnych technologiach i językach

No to zgoda - w takich super-projektach pewnie potrzebna by była pewna osoba, która ogarnie to całościowo (czy raczej zespół osób? Nie sądzę, żeby przy takich dużych projektach jedna osoba by sobie ze wszystkim poradziła).

Tylko, że etykietka to kwestia względna. Stawiam, że taki korporacyjny "architekt" to w jakimś startupie może być CEO a w jakimś średnim projekcie może to być jakiś PM / lead / CTO / team leader / szef / koordynator jakkolwiek go tam nazwą.

Jak dla mnie ten cały "architekt" to bardziej rola w firmie, a nie jakiś konkretny zawód. Nazwa "architekt" sugeruje pewien etos, powagę zawodu (że niby jak prawdziwy architekt tylko od software'u) a to po prostu taki ogarniacz całości, taki jak w każdej innej branży.

Tylko tak - w teorii to potrzebne, ale w praktyce? Nie pracowałem nigdzie, gdzie byłby wydzielony ktoś z etykietką "architekt", ale z tego co czytam z relacji innych to są to często ludzie, którzy nie zawsze są kompetentni w tym co robią oraz często się wywyższają i traktują programistów jak bezmyślne pionki na zasadzie "jestem architektem, jestem mądrzejszy".

Somekind:
Jeden architekt na 8 programistów. Czasami programował jakieś rzeczy infrastrukturalne, albo PoCe. Ten był bardzo ogarnięty
i miał wiedzę zarówno technologiczną jak i projektową. Decydował o technologii, biblitekach i wyglądzie dosłownie wszystkiego,
np. mówił programistom jakie mają być klasy i co w nich ma się znajdować. Programiści właściwie nie wykonywali
pracy twórczej w tym projekcie, klepali tylko wg wytycznych architekta.

To czemu sam nie napisał tych klas? Przecież trudniej/więcej czasu spędza się na projektowaniu rozwiązań, a samo napisanie jak już wiesz, co chcesz zrobić (szczególnie jak ktoś już pisał PoCe) to raczej chwila.

0

Jak dla mnie praca architekta to taka praca projekt managera przepuszczona przez techniczne filtry. I projekt manager i architekt są potrzebni - oczywiście nie we wszystkich organizacjach. Po co architekt w projekcie, gdzie jest 10 developerów, a cała organizacja to 200 osób ? Pewnie nie jest potrzebny. W organizacji są trzy bazy na krzyż i jakaś szyna integracyjna pod serwisy i to wszystko.
Ale jak taka organizacja zacznie rosnąć i będzie miała 200 baz i 40 systemów, to pewnie stanie się potrzebny, nieprawdaż ?

Jednocześnie jestem przekonany, że praca architekta oraz praca project managera są o wiele trudniejsze niż praca szeregowego programisty.

1 użytkowników online, w tym zalogowanych: 0, gości: 1