Czy jako architekt oprogramowania mam się tak bardzo koncentrować na analizie dzienników i naprawianiu błędów innych?

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?

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.

Artykuł w Wikipedii definiuje architekta oprogramowania jako:

programista komputerowy , który dokonuje wyborów na wysokim poziomie projektowania i dyktat standardów technicznych , w tym oprogramowanie do kodowania standardów, narzędzi lub platform ...

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.

• Powiedziałbym, że powyższy tytuł nadał ci o 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. :)}

Czy jako architekt oprogramowania mam się tak bardzo koncentrować na analizie dzienników i naprawianiu błędów innych?

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:

1. Inicjuj plany edukacyjne, aby inne osoby (deweloper / wsparcie) mogły podnieść ładunek. „naucz człowieka łowić ryby” i cały ten jazz.
2. Wymyślaj sposoby i opracowuj narzędzia wspierające szybszą i łatwiejszą analizę defektów oraz izolację przyczyn. Jeśli uważasz, że to nudne, inni, być może mniej utalentowani lub doświadczeni programiści uważają, że jest to nie tylko nudne, ale także trudne, a może nawet zniechęcające. Pomóż im przezwyciężyć to dzięki technologii.
3. Zacznij starać się podnieść jakość produktu - uprościć, zmodularyzować, stworzyć ramy testowe - dawaj przykład, nie marudząc i grożąc odejściem.
4. Upewnij się, że programiści wiedzą, co robisz - ale także swoich menedżerów. Rola architekta polega bardziej na relacjach z innymi ludźmi niż na kodowaniu i analizie. Choć można tego nienawidzić, polityka odgrywa tutaj kluczową rolę. Dopilnowanie, by twoi rówieśnicy zobaczyli twoje osiągnięcia, ułatwi później przekonanie ich, że masz rację. Jeśli jeszcze cię tam nie ma, poprzyj swoje roszczenia badaniami i POC.
5. Jeśli wszystko inne zawiedzie i dopiero po spędzeniu czasu na poprawianie sytuacji, porozmawiaj ze swoim menedżerem. Powiedz, że twoje umiejętności są lepiej wykorzystywane na etapie planowania i projektowania i zobacz, co można zrobić, aby zmienić obecną sytuację. Twój produkt może być w mgnieniu oka, a odpowiedź Twojego menedżera może brzmieć: „Potrzebujemy cię do tego właśnie tutaj, teraz”. Nalegałbym jednak na długoterminowy plan - w jaki sposób zamierzamy zmienić obecną sytuację.

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.

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ś:

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.

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.

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:

1. 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.

2. 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ł.

3. Uporządkuj swoją pracę, utrzymując jasne priorytety i nie reaguj tak bardzo na projekty zewnętrzne.

4. 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.

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.

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.

1. 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.

2. 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.

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.

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 .

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ą.

Czy jako architekt oprogramowania mam się tak bardzo koncentrować na analizie dzienników i naprawianiu błędów innych?

Mówiąc „tak”.

Oto jak kwalifikowałbym moją odpowiedź:

1. Domyślnie twórcy oprogramowania powinni analizować dzienniki i naprawiać błędy.
2. Jednak ... Musisz zdawać sobie sprawę z wad, które spowodowały utratę danych, wymagają uciążliwego przywracania bazy danych, rozwiązania problemów przez deweloperów lub przeprosin klienta.
   1. Z reguły bezpośrednie raporty powinny informować cię o takich wadach.
   2. Powinieneś stworzyć kulturę, w której twoje bezpośrednie raporty będą upoważnione do informowania cię o takich wadach, ale nie zmuszone do mówienia o trywialnych.

Więcej na temat # 2:

1. Tego rodzaju defekty na ogół oznaczają błędy architektoniczne. Kiedy to zrobią, musisz zrozumieć dokładną naturę wady i zaprojektować poprawkę.
   1. Dlatego też musisz być gotowy, chętny i zdolny do przeszukiwania dzienników i naprawiania błędów innych osób (nawet jeśli nie przekazujesz kodu bezpośrednio do repozytorium kodu źródłowego).

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.