Od ukończenia studiów (pod koniec 2005 r.) Pracowałem dla tej samej firmy, co inżynier oprogramowania c ++. Rok temu awansowałem jako architekt oprogramowania, ale coraz bardziej angażuję się w kwalifikacje i naprawianie błędów, wsparcie na poziomie 2.
50% mojego czasu spędziłem w Notepad ++ analizując logi oprogramowania i próbując dowiedzieć się, co poszło nie tak. 30% naprawia błędy innych, a pozostałe (jeśli w ogóle) recenzują kod spaghetti dla programistów.
Zacząłem nienawidzić tego produktu i myślałem o strategii wyjścia z tej firmy.
Jak myślisz, co mogę zrobić w tej sytuacji? czy inny architekt oprogramowania nadal naprawia błędy w kodzie?
architecture
teamwork
software
cpp81
źródło
źródło
Odpowiedzi:
Większość ludzi ogólnie zgadza się, że Architekt Oprogramowania powinien być głównie zaangażowany w projektowanie na wysokim poziomie, ustanawianie standardów, wybieranie narzędzi lub struktur, ocenę produktów, wdrażanie prototypów i Proof Of Concepts oraz szkolenia i mentoring dla programistów
Rzeczywistość jest jednak taka, że tytuł często może być politycznym spotkaniem z deweloperem, specjalnym tytułem nadawanym wiodącym deweloperom projektów, a nawet czymś tak prostym jak obejście menedżersko-kadrowe, aby zatrudnić bardzo potrzebnego dewelopera za wynagrodzenie lub stawkę, która Kierownik działu kadr lub wyższego szczebla uznałby za niedopuszczalny tytuł programisty lub inżyniera oprogramowania.
Innymi słowy, tytuły są w większości bez znaczenia.
źródło
Artykuł w Wikipedii definiuje architekta oprogramowania jako:
Biorąc pod uwagę powyższe, twoje szacunki „50% mojego czasu ... analizy dzienników oprogramowania ... 30% naprawiania błędów innych” odsuwa cię daleko od tego, czego zwykle oczekuje się od architekta oprogramowania.
50+30=80%
podróbce.Należy pamiętać, że działania takie jak analiza dzienników lub naprawianie błędów innych osób mogą zgodnie z prawem zajmować część czasu architekta - pod warunkiem, że służą one pierwszemu celowi tej roli - to jest dokonywaniu wyborów projektowych na wysokim poziomie i ustanawianiu standardów technicznych. W rzeczywistości dotyczy to wszelkiego rodzaju działań związanych z programowaniem / konserwacją / testowaniem oprogramowania.
Na przykład, jeśli analiza dzienników doprowadziła cię do wglądu, jak to ułatwić - poprzez ulepszenie projektu, narzędzi lub standardów kodowania - byłby to całkowicie uzasadniony wysiłek dla architekta. Podobnie architekt może całkowicie zabrudzić sobie ręce naprawiając określone błędy (błędy) - o ile spowodowałoby to określone ulepszenia projektu / procesu prowadzące do niższego wskaźnika błędów itp.
Z nieco bardziej pozytywnych uwag, twoje pytanie pokazuje co najmniej jedną umiejętność, która jest dość ważna dla architekta: umiejętność klasyfikowania różnego rodzaju działań i śledzenia wysiłków włożonych w nie. Zastanów się nad dodaniem do swojego „zestawu narzędzi” umiejętności uzupełniających, aby podsumować swoje spostrzeżenia i szacunki oraz jasno je przekazać, zwłaszcza po drabinie zarządzania. :)
źródło
Podobny? tak i nie. Odpowiadasz za całość jakości produktu i ścieżkę ewolucji - spraw, aby działał jutro, ale także w przyszłym roku.
Czy to oznacza pomoc w rozwiązywaniu trudnych problemów? Oczywiście - przynajmniej tak. Nie możesz sprawić, by produkt działał jutro, jeśli klienci cię opuszczą.
Czy to oznacza, że powinieneś poświęcić temu cały swój czas? Absolutnie nie. Odpowiadasz za CAŁOŚĆ jakości i ewolucji. Poświęcenie tyle czasu na pogoni za problemami przynosi efekty.
Powinieneś być proaktywny:
Uważam rolę architekta za przywilej. Możesz wpływać na produkt w sposób, w jaki niewiele osób może - jedyny teoretycznie bardziej wpływowy niż ty, to kierownik działu badań i rozwoju produktu (i ewentualnie marketingu) - ale jest on zbyt zajęty zarządzaniem.
źródło
Rola architekta oprogramowania tradycyjnie nie powoduje naprawiania błędów. Architekci oprogramowania pomagają w rozwiązywaniu problemów projektowych w oprogramowaniu, więc jeśli przez błąd rozumiesz, że główny sposób, w jaki oprogramowanie zostało zaprojektowane, jest bardziej niestabilny lub trudny w rozszerzaniu / utrzymywaniu, wówczas zadaniem SA będzie zaproponowanie lub przeprojektowanie aspektów oprogramowanie do rozwiązania tego problemu.
Biorąc pod uwagę to, co powiedziałeś:
To nie jest rola prawdziwego SA, a raczej to, co chciałbym, aby nasi programiści na poziomie programisty 1 i programisty 2 rozpoczęli pracę wraz ze starszym programistą. Mówię to w szczególności, ponieważ uważam, że naprawdę pomaga nowym programistom w naszej firmie wejść w produkt i kod, pracując na tym poziomie nad kwestiami jakości kodu. Czy jesteś nowym SA w swojej firmie i każą ci wykonać tę pracę, aby dostać się do systemu? Jeśli tak, to może przez krótki czas będzie OK. Jeśli jest to twoja codzienna praca i trwa już ponad rok, być może nadszedł czas, aby poszukać innej roli.
źródło
Rozumiem twoją frustrację, ale rozumiem, jeśli napisałeś kod lub byłeś ostatnim, który go dotknął, czas jest krótki i mogą cię dosięgnąć, wielu menedżerów pójdzie do ciebie, aby go naprawić, niezależnie od twojego tytułu.
Pomyśl, że nadal masz przyjaciół w grupie rozwojowej, która jest w kryzysie. Problem polega na tym, że oni, a co ważniejsze, ich zarząd przyzwyczajają się do pomocy, ciągle wracają. Jak powiedziano: „żaden dobry uczynek nie pozostanie bezkarny”. Jeśli mogą liczyć na to, że rozwiążesz problemy, niezależnie od twojego tytułu, jesteś tylko kolejnym programistą i kimś innym, z czego mogą skorzystać.
Jest to trudny problem do rozwiązania, ale moja rada to:
Poproś o numer opłaty za projekt w tym czasie, który nie jest architektem oprogramowania. Uważam, że menedżerowie projektów nie są tak chętni, aby poprosić o Twój czas, jeśli muszą być za to odpowiedzialni.
Porozmawiaj ze swoim menedżerem o tym, ile czasu tracisz oraz do jakich grup lub projektów. Twój menedżer może ci powiedzieć, żebyś im nie pomagał i koncentrował się na swoich projektach. Jeśli tak, to druga grupa przychodzi i prosi o pomoc, mówisz im, że twój szef też nie powiedział.
Uporządkuj swoją pracę, utrzymując jasne priorytety i nie reaguj tak bardzo na projekty zewnętrzne.
Działaj jak architekt, spraw, aby twoi rówieśnicy postrzegali cię jako architekta, a nie jako tego samego programistę, którego byłeś przez te wszystkie lata. Przełamałeś nawyk traktowania cię jak programistę.
Powodzenia.
źródło
Nie, jesteś tutaj, aby zarządzać całym obrazem.
Masz problem z zarządzaniem: naprawianie błędów i poprawianie jakości kodu jest zadaniem programistów, jako architekt powinieneś wydawać wytyczne i rzeczywistą architekturę (UML lub cokolwiek, co płynie łodzią), a następnie regularnie przeglądać kod, aby upewnić się, że te wytyczne są przestrzegane .
Możesz jednak zaimplementować i naprawić błędy w architekturze podstawowej.
Przykład: pracowałbyś nad PRISM, MEF itp. W projekcie WPF / C #, ale nie pracowałbyś na XAML, aby wyświetlić ekran powitalny.
Pracowałbyś nad projektem DB, ale nie zapisywałbyś procedur przechowywanych dla operacji CRUD.
itp.
źródło
Częścią odpowiedzi byłoby znalezienie inżyniera, który byłby skłonny podjąć się tego obciążenia.
Oczywiście przyczyną tego problemu jest to, że praca ta jest niepożądana, co nie wysyła wiadomości o tym, że jest atrakcyjna dla innych inżynierów, dlatego też nie są chętni do jej odebrania.
Widzę dwie możliwości.
Otrzymałeś stanowisko architekta, abyś mógł pracować nad większymi obrazami.
W takim przypadku należy wspomnieć kierownictwu, że nie można pracować nad większymi elementami obrazu, ponieważ nikt nie wystąpił w roli wsparcia na niższym poziomie. To jest ich problem do rozwiązania.
Tytuł jest w dużej mierze ceremonialny - kość rzucona, aby utrzymać cię przy sobie.
W takim przypadku zarządzanie może nie być szczególnie zainteresowane zmniejszeniem obciążenia wsparcia.
-
Jedną z rzeczy, która na pewno nie pomoże twojemu celowi, jest przyjęcie pogardy dla innych programistów i inżynierów, których ujawnienie przeniknęło twoje pytanie. Chcesz, aby ci ludzie przyspieszyli i pewnie poradzili sobie z tymi problemami, abyś nie musiał (prawdopodobnie popełnił jakieś błędy po drodze). Jeśli wiedzą, że po prostu badmouth ich rozwiązania i naprawić je później, prawdopodobnie nie będzie nigdy więcej.
źródło
Jest to zdecydowanie rodzaj pracy, której NIE powinieneś wykonywać dla tej roli. Zgodnie z moim doświadczeniem / obserwacjami architekt musi być zaangażowany w projektowanie aplikacji, ulepszenia, wyjaśnienia wymagań technicznych i potencjalne problemy z wydajnością (nie sprawdzanie dzienników codziennie, ale przede wszystkim analiza poważnych problemów / błędów), które należy rozwiązać lub których należy unikać.
Innymi słowy, moim punktem nr 1 jest - architekci to projektanci wysokiego szczebla i integratorzy systemów z praktycznym doświadczeniem w tym, jak działają wewnętrzne zastosowania / zastosowania i muszą być stosowane.
Jeśli masz możliwość przypisania i zarządzania jakością kodu, musisz poprawić swoje umiejętności zarządzania pracą. Dlatego planowanie pracy powinno być twoim priorytetem w podejściu „jak wykonać pracę”.
Punkt # 2 : jeśli jesteś jednym z niewielu programistów w tych aplikacjach, to ten tytuł jest po prostu kolejną polewą cukrową ze strony kierownictwa firmy, aby utrzymać cię w tej samej roli „napraw to” z nowym wymyślnym tytułem .
źródło
Rola architekta oprogramowania to znacznie więcej niż to, co robisz w swojej obecnej firmie. Odpowiada za definiowanie standardów projektowania oprogramowania, projektowanie na wysokim poziomie, standardy kodowania itp. Naprawianie błędów może być uważane za niewielką jego część, choć tak naprawdę nie jest. Ale jak już powiedziałeś, pracujesz nad produktem, oznacza to, że będąc architektem oprogramowania, twoje oczekiwania dotyczące niezawodności produktu będą dość wysokie, w takim przypadku twoje zaangażowanie w takie rzeczy będzie nie tylko pomóż produktowi, ale także firmie, ponieważ masz w tym dość doświadczenie. Ale powinieneś także mieć dostęp do nowych funkcji i nowych zadań, które podsycą twoje zainteresowanie obecną organizacją.
źródło
Mówiąc „tak”.
Oto jak kwalifikowałbym moją odpowiedź:
Więcej na temat # 2:
źródło
Odpowiedź brzmi prawdopodobnie nie. Dlaczego spędzasz tyle czasu na debugowaniu i obsłudze problemów? Czy ktoś przypisuje ci tę pracę?
Wygląda na to, że musisz wyjaśnić, co powinieneś robić. Może być konieczne naprawienie błędów; to prawdopodobnie nie powinna być większość twojego czasu.
źródło