Pojawiło się wiele pytań z dobrymi odpowiedziami na temat roli architekta oprogramowania (SA) w StackOverflow i Programmers SE . Staram się zadać nieco bardziej ukierunkowane pytanie niż te. Sama definicja SA jest szeroka, dlatego na potrzeby tego pytania zdefiniujmy SA w następujący sposób:
Architekt oprogramowania kieruje ogólnym projektem projektu, angażuje się w kodowanie, przeprowadza przeglądy kodu i wybiera technologie, które zostaną zastosowane.
Innymi słowy, nie mówię o odpoczynku kierowniczej i kamizelka na grzbiecie (dalej rymowanych słów pomijana) rodzaje skojarzeń. Gdybym miał realizować dowolny typ pozycji AF nie chcę być z dala od kodowania. Mogę poświęcić trochę czasu na komunikację z klientami i analitykami biznesowymi itp., Ale nadal jestem technicznie zaangażowany i nie jestem tylko świadomy tego, co dzieje się podczas spotkań.
Z tych punktów na uwadze, co powinno SA wnieść na stół? Powinni przyjść z mentalnością „ustanawiające prawa” (że tak powiem) i egzekwowania korzystanie z niektórych narzędzi, aby dopasować „swoją drogę”, czyli wytycznych, kontroli źródła, wzorów dokumentacji UML itp kodowania? Czy powinny one określić początkowy kierunek i strategię następnie być wyluzowana i skok w miarę potrzeby skorygować kierunek statku?
W zależności od organizacji może to nie działać. SA, która polega na TFS w egzekwowaniu wszystkiego, może mieć trudności z wdrożeniem swojego planu u pracodawcy, który używa tylko StarTeam. Podobnie SA musi być elastyczna w zależności od etapu projektu. Jeśli jest to nowy projekt, mają większy wybór, podczas gdy mogą mieć mniej w przypadku istniejących projektów.
Oto kilka historii SA, których doświadczyłem jako sposób na podzielenie się pewnym doświadczeniem w nadziei, że odpowiedzi na moje pytania mogą rzucić nieco światła na te kwestie:
Pracowałem już z SA, którzy dosłownie każdy kod przeglądowi jednej linii kodu zespołu. SA byłoby to zrobić nie tylko dla naszego projektu, ale także w innych projektach w organizacji (wyobrazić sobie czas spędzony na ten temat). Początkowo było to użyteczne wymusić pewne standardy, ale później okazało się kalectwo. FxCop było jak SA znajdzie problemy. Nie zrozumcie mnie źle, to był dobry sposób, aby nauczyć młodszych programistów i zmusić ich do myślenia o konsekwencjach wybranego przez nich podejścia, ale dla starszych programistów było to postrzegane jako nieco drakońskie.
Jedna szczególna SA był przeciwko stosowaniu pewnej biblioteki, twierdząc, że była powolna. To zmusiło nas do pisania ton kodu do osiągnięcia rzeczy inaczej, podczas gdy druga biblioteka będzie już nam zaoszczędzić sporo czasu. Szybki skok do ostatniego miesiąca projektu i klientów narzekają wydajności. Jedynym rozwiązaniem była zmiana pewnych funkcji użyć pierwotnie ignorowane podejście mimo wczesnych ostrzeżeń ze strony deweloperów. W tym momencie dużo kodu został wyrzucony, a nie wielokrotnego użytku, co prowadzi do pracy w godzinach nadliczbowych i stresu. Niestety szacunki wykorzystywane na potrzeby projektu oparto na starym podejściu, które mój projekt został zakazany z użyciem więc to nie był odpowiedni wskaźnik dla oszacowania. Chciałbym usłyszeć PM powiedzenia „zrobiliśmy tego wcześniej”
SA, który wymusi użycie DTOs, DOS, BOS, warstw obsługa i tak dalej dla wszystkich projektów. Nowe deweloperów musiał nauczyć się tej architektury i AF stanowczo egzekwowane wytyczne użycia. Wyjątki wytycznych użytkowania zostały wykonane, kiedy to było absolutnie trudne do wskazówek. SA został uziemiony w swoim podejściu. Klasy dla DTO i wszystkie operacje CRUD zostały wygenerowane przez CodeSmith, a schematy bazy danych były kolejną podobną kulą wosku. Jednakże mając stosować tę konfigurację wszędzie SA nie była otwarta na nowe technologie, takie jak LINQ to SQL lub Entity Framework.
Nie używam tego posta jako platforma do odpowietrzania. Były pozytywne i negatywne aspekty moich doświadczeniach z opowiadań SA wymienionych powyżej. Moje pytania sprowadzają się do:
- Co powinno skojarzenie wnieść na stół?
- Jak mogą zachować równowagę w swoim procesie decyzyjnym?
- Czy należy podejść do zadania SA (jak zdefiniowano wcześniej) ze świadomością, że muszą one egzekwować określone podstawowe zasady?
- Masz jeszcze coś do rozważenia?
Dzięki! Jestem pewien, że te zadania pracy są łatwo rozszerzyć do ludzi, którzy są starsi deweloperów lub przewody technicznych, więc nie krępuj się odpowiedzieć w tym charakterze, jak również.
źródło
Odpowiedzi:
Architekt systemów powinien:
SA muszą wiedzieć, jak kodować, i powinni uczestniczyć w niektórych pracach związanych z kodowaniem, że tak powiem. To utrzymuje je w kontakcie z gestaltu nakładu rozwoju. Jak powiedział kiedyś wujek Bob Martin , architekt powinien sam wykonać część kodowania, aby dzięki swoim projektom mógł zobaczyć ból, jaki zadaje innym.
SA powinna mieć ostatnie słowo na temat wszystkich decyzji dotyczących projektowania, technologii i stylu kodowania. Ale, podobnie jak wszyscy menedżerowie, zadaniem SA jest oczyszczenie ścieżki dla jego ludzi, aby mogli być produktywni. W większości przypadków oznacza to, że programiści mogą decydować na swoim poziomie, w jaki sposób należy rozwiązać problemy. Oznacza to, że SA trzyma spiczastych szefów z dala od kabin deweloperów. A to oznacza, że Stanowiska SA w celu pomocy w razie potrzeby.
Jak wszyscy ludzie, SA mogą i robią błędy. Ci dobrzy uczą się na tych błędach i stają się lepszymi SA.
źródło
Nigdy nie spotkałem architekta, który byłby użyteczny, przede wszystkim dlatego, że nie był praktyczny.
Dla mnie największe problemy, które widziałem to:
rewrite from scratch
mentalnośćNajlepsze „Architekci” Pracowałem już z przyniósł do stołu:
Problemem jest dla mnie najlepsze „Architekci” Pracowałem już z nie mają „Architect w tytule. Były to najczęściej Software Engineers, którzy są uziemione w problemu i projektów konkretnego. Zrozumieli, że w większości firm to ISN” t praktyczne przepisać codebase pracę od podstaw. Robią decyzji projektowych lub udostępniają opcje i ich przyczyn lub uzasadnienia. oni nakreślić jak iteracyjne kodzie do nowej architektury w czasie i nadal utrzymać wszystko działa. dają konserwatywnych zalecenia zamiast polecając co jest Dejour lub znajomy. oni komunikować spójną wizję tego, jak wszystko powinno działać i dlaczego, ale co ważniejsze, oni nakreślić jak się tam dostać, a koszt.
źródło
1 Co SA powinien przynieść do stołu?
2 W jaki sposób mogą osiągnąć równowagę w podejmowaniu decyzji?
3 Czy należy podejść do zadania SA (jak zdefiniowano wcześniej) z myślą, że muszą one egzekwować określone podstawowe zasady?
Jest wiele więcej, myślę, że będziemy mieć kilka naprawdę dobrych odpowiedzi pochodzące z tego jeden.
źródło
1. Co SA powinien przynieść do stołu?
„Powinny one przyjść z mentalnością«ustanawiające prawa»... Albo powinni określić początkowy kierunek i strategię następnie być wyluzowana i skok w miarę potrzeby skorygować kierunek statku?”
Połączenie obu powiedziałbym. Decydując się na technologie i procesy, otwartość na opinie i sugestie może dostarczyć cennych informacji zwrotnych / wkładu w podejmowane decyzje i skłonić Cię do uczenia się od innych. Twój zespół jest (mam nadzieję) mądry; skorzystać z tego. Ale kiedy zostanie podjęta decyzja (Twoja decyzja), prawo zostało ustanowione. Zidentyfikuj tych, którzy będą narzekać na cokolwiek, co nie było ich wyborem, i tych, którzy po prostu wybiorą wszystko i ich to nie obchodzi - a następnie zignoruj ich.
Jeśli chodzi o technologie: praca z tym, co masz, jeśli firma korzysta StarTeam to jest to, czego używasz. Powiązanie się z jakimś konkretnym produktem / technologią / procesem nic dla ciebie nie zrobi.
2.Jak mogą osiągnąć równowagę w podejmowaniu decyzji?
Ważne jest słuchanie zespołu i wiedza, kiedy mają rację, a kiedy źle, a także posiadanie cojones, aby powiedzieć im, że się mylą i trzymać się swojej decyzji. Nie słuchanie przyniesie brak szacunku, podobnie jak podejmowanie decyzji.
3.Should zbliżyć się pracę SA (jak zdefiniowano wcześniej) z mentalnością, że muszą egzekwować pewne podstawowe zasady?
Zawsze. Jeśli nie, więźniowie ostatecznie będą ubiegać się o azyl, jawnie lub potajemnie. Decydując się na te podstawowe zasady, można jednak porozmawiać z zespołem. Pamiętaj, że jakikolwiek zespół może nie zawsze mieć tych samych członków, co teraz, więc ustępstwa dla niewielkiej grupy mogą utrudnić drużynie w przyszłości, gdy odejdą. Dotyczy to również SA.
4. Coś jeszcze do rozważenia?
źródło