Co należy przynieść do stołu jako architekt oprogramowania? [Zamknięte]

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:

1. Co powinno skojarzenie wnieść na stół?
2. Jak mogą zachować równowagę w swoim procesie decyzyjnym?
3. Czy należy podejść do zadania SA (jak zdefiniowano wcześniej) ze świadomością, że muszą one egzekwować określone podstawowe zasady?
4. 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ż.

Architekt systemów powinien:

1. Określ architekturę wysokiego poziomu
2. Weź udział w recenzjach kodu
3. Zatwierdź zastosowane technologie
4. Pomóż programistom w ich wysiłkach związanych z kodowaniem
5. Utrzymuj i monitoruj harmonogram rozwoju
6. Produkować SA artefakty, takie jak diagramy UML, wykresów Gantta i tym podobne.

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.

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:

• ślepe przestrzeganie procesu ze względu na proces
• ślepe nastawienie na technologię przed poznaniem problemu
• tworzenie i egzekwowanie reguł bez dobrego uzasadnienia
• rewrite from scratch mentalność

Najlepsze „Architekci” Pracowałem już z przyniósł do stołu:

• Pytania, na które pojechaliśmy do lepszego zrozumienia problemu i potencjalnych rozwiązań.
• Zaprojektować opcji / technologii oraz ich kompromisów.
• Jasne i racjonalnych wyjaśnień dla obu potępień i zatwierdzeń wzorów i technologii.

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.

1 Co SA powinien przynieść do stołu?

• Gruba skóra
• Dobre umiejętności negocjacyjne
• Dobre zrozumienie poszczególnych warstw oprogramowania (od whizzy AJAX dobroci niskim poziomie sieci I / O). Niekoniecznie musisz być ekspertem, ale będziesz musiał podejmować ważne decyzje dotyczące tego, jakie oprogramowanie powinno zostać uruchomione na poszczególnych warstwach.
• Chcąc ubrudzić sobie ręce kodem, wzory białego papieru po prostu go nie wycinają.
• Zachęcanie do kunsztu tworzenia oprogramowania - bądź cheerleaderką w robieniu rzeczy we właściwy sposób, gdy tylko jest to możliwe, i najlepszym sposobem, biorąc pod uwagę ograniczenia w innych przypadkach. Więc takie rzeczy jak kontrola źródła, TDD, kompilacja i CI, kodowanie DOJO, recenzje kodu, dobry system śledzenia problemów itp.

2 W jaki sposób mogą osiągnąć równowagę w podejmowaniu decyzji?

• Wiele z nich zależy od zespołu (-ów) i jak zdolne są.
• Twoje środowisko (możesz na przykład zostać zmuszony do korzystania z produktu konkretnego dostawcy)
• Ogólnie rzecz biorąc, najlepiej nie być architektem z kości słoniowej, być bezpośrednim, być częścią zespołu - ludzie zrozumieją twoje decyzje w ten sposób.

3 Czy należy podejść do zadania SA (jak zdefiniowano wcześniej) z myślą, że muszą one egzekwować określone podstawowe zasady?

• Tak, takie rzeczy kontroli wersji i systemu kompilacji są cholernie ważne i deweloperzy muszą z nich korzystać. Jednak najlepiej jest, aby stały się częścią rozwiązania.

Jest wiele więcej, myślę, że będziemy mieć kilka naprawdę dobrych odpowiedzi pochodzące z tego jeden.

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?

• W odniesieniu do drugiego przykładu: wydaje się, że zespół projektowy ściśle powiązał zależność z wewnętrznym podsystemem. Luźno sprzężone fasady nie służą tylko kodowi innej firmy. Utworzenie abstrakcji dla tego podsystemu mogłoby umożliwić łatwiejsze przejście do korzystania z tej biblioteki, gdyby wewnętrzne rozwiązanie nie powiodło się. Jest to logiczne rozwiązanie dla samego architekta oprogramowania, ale także jako forma Project Managera z obawami związanymi z wyrażaniem zespołu, powinno być podwójnie tak oczywiste.
• W nawiązaniu do swojej trzeciej przykład: To nie jest zły pomysł, aby mieć znaną architekturę lub procesu wytwarzania oprogramowania (choć, co prawda, zrobiłeś powiedzieć „wszystkie projekty”). Trzyma się tego, co działa. To powiedziawszy, muszą istnieć możliwości, w których można spróbować nowych technik, aby sprawdzić, czy przynoszą one dodatkową wartość. Oprogramowanie przeznaczone wyłącznie do użytku własnego lub projekty o mniejszym zakresie, w których można wypróbować te technologie, są idealnymi miejscami. Należy pamiętać jednak, że spoczywa również na deweloperskich (S), aby zapewnić zbadane i przekonujące manifestacje / Argumenty za przyjęciem technologii. I nie można oczekiwać, że SA pozna każdą konkurencyjną ORM oraz jej mocne i słabe strony w porównaniu do innych.