Как архитектор программного обеспечения, я должен сосредоточиться на анализе журналов и исправлении ошибок других?

После выпуска (в конце 2005 года) я работал в той же компании, что и инженер по программированию на С ++. Год назад меня повысили до должности архитектора программного обеспечения, но я все больше и больше занимаюсь квалификацией и исправлением ошибок, поддержкой уровня 2.

50% моего времени провел в Notepad ++, анализируя журналы программного обеспечения и пытаясь выяснить, что пошло не так. 30% исправление чужих ошибок и оставшаяся (если таковая имеется) проверка кода разработчиков спагетти.

Я начал ненавидеть этот продукт и думать о стратегии выхода из этой компании.

Как вы думаете, что я могу сделать в этой ситуации? другой архитектор программного обеспечения все еще исправляет ошибки в коде?

Большинство людей в целом согласны с тем, что архитектор программного обеспечения должен в основном участвовать в разработке высокого уровня, установлении стандартов, выборе инструментов или сред, оценке продуктов, реализации прототипов и Proof Of Concepts, а также обучении и наставничестве разработчиков

Однако реальность такова, что название часто может быть политическим назначением для разработчика, специальным названием, назначаемым для ведущих разработчиков проектов, или даже чем-то столь простым, как обходной путь управления-HR для найма крайне необходимого разработчика по зарплате или по ставке, которая Управление персоналом или высшее руководство сочли бы неприемлемым звание разработчика программного обеспечения или разработчика программного обеспечения.

Другими словами, названия в основном бессмысленны.

Статья Википедии определяет архитектора программного обеспечения как:

компьютерный программист , который делает выбор высокого уровня дизайна и диктат технические стандарты , в том числе программного обеспечения кодирования стандартов, инструментов и платформ ...

Учитывая вышесказанное, ваши оценки «50% моего времени, потраченного ... на анализ журналов программного обеспечения ... 30% на исправление ошибок других» , далеко ушли от того, что обычно ожидается от разработчика программного обеспечения.

• Я бы сказал выше, делает название, которое они дали вам о 50+30=80%подделке.

Обратите внимание, что сами по себе такие действия, как анализ журналов или исправление ошибок других, могут на законных основаниях занимать часть времени архитектора - при условии, что они служат основной цели этой роли - то есть, делая выбор проекта высокого уровня и устанавливая технические стандарты. На самом деле, это относится к любому виду деятельности по разработке / сопровождению / тестированию программного обеспечения.

Например, если анализ журналов привел вас к пониманию того, как сделать это проще - улучшив дизайн, инструменты или стандарты кодирования, - это было бы совершенно оправданным усилием для архитектора. Точно так же, для архитектора вполне может быть нормальным исправлять конкретные ошибки, если это приведет к конкретным улучшениям дизайна / процесса, что приведет к снижению частоты ошибок и т. Д.

_{На более позитивной ноте ваш вопрос демонстрирует, по крайней мере, один навык, который очень важен для архитектора: способность классифицировать различные виды деятельности и отслеживать усилия, затраченные на них. Подумайте о том, чтобы добавить в свой «инструментарий» дополнительные навыки, чтобы обобщить ваши наблюдения и оценки и четко изложить их, особенно на уровне руководства. :)}

Как архитектор программного обеспечения, я должен сосредоточиться на анализе журналов и исправлении ошибок других?

Предполагается, что? и да и нет. Вы отвечаете за все качество продукции и пути ее развития - сделайте так, чтобы она работала завтра, но и заставьте ее работать в следующем году.
Означает ли это, протянуть руку помощи, чтобы решить сложные проблемы? Абсолютно - по крайней мере, я делаю. Вы не можете заставить продукт работать завтра, если ваши клиенты оставят вас.
Значит ли это, что вы должны посвятить ВСЕ свое время этому? Точно нет. Вы отвечаете за ПОЛНОСТЬЮ качества и эволюции. Посвящение так много времени погоне за проблемами контрпродуктивно.

Вы должны быть активными:

1. Инициируйте учебные планы, чтобы другие люди (разработчики / поддержка) могли снять нагрузку. "научи человека ловить рыбу" и все такое в джазе.
2. Придумайте способы и разработайте инструменты для поддержки более быстрого и простого анализа дефектов и изоляции первопричин. Если вы находите это скучным, другие, возможно, менее талантливые или опытные разработчики находят это не просто скучным, но также трудным и, возможно, даже пугающим. Помогите им преодолеть это с помощью технологий.
3. Начните работу над повышением качества продукта - упростите, модульные, создайте фреймворки для тестирования - подайте пример, а не скулите и угрожайте выйти.
4. Убедитесь, что разработчики знают, что вы делаете, - но также и ваши менеджеры. Роль архитектора гораздо больше связана с отношениями с другими людьми, чем с программированием и анализом. Как бы вы ни ненавидели это, политика играет здесь ключевую роль. Если ваши сверстники увидят ваши достижения, вам будет легче убедить их в том, что вы правы. Если вы еще не там, подкрепите свои претензии исследованиями и POCs.
5. Если ничего не помогает, и только после того, как вы потратите время на улучшение ситуации, поговорите с вашим менеджером. Скажите, что ваши навыки лучше использовать на этапах планирования и проектирования, и посмотрите, что можно сделать, чтобы изменить текущую ситуацию. Ваш продукт может быть в крайнем случае, и ваш менеджер может ответить: «Вы нужны нам для этого прямо сейчас, прямо сейчас». Хотя я бы настаивал на долгосрочном плане - как мы собираемся изменить текущую ситуацию.

Я вижу роль архитектора в привилегии. Вы можете влиять на продукт так, как не многие другие люди - только теоретически более влиятельный, чем вы, он - менеджер по исследованиям и разработкам (и, возможно, по маркетингу), - но он очень занят управлением.

Роль архитектора программного обеспечения традиционно не позволяет им исправлять ошибки. Архитекторы программного обеспечения действительно помогают решать проблемы проектирования в программном обеспечении, поэтому, если под ошибкой вы подразумеваете основной способ, которым было разработано программное обеспечение, допускает большую хрупкость или трудности в расширении / обслуживании, то задача СА состоит в том, чтобы предложить или изменить аспекты аспекта программное обеспечение для решения этой проблемы.

Учитывая то, что вы сказали:

50% моего времени провел в Notepad ++, анализируя журналы программного обеспечения и пытаясь выяснить, что пошло не так. 30% исправление чужих ошибок и оставшаяся (если таковая имеется) проверка кода разработчиков спагетти.

Это не роль настоящего SA, а скорее то, с чего я бы хотел, чтобы наши программисты уровня 1 и 2 начинали вместе со старшим разработчиком. Я говорю это, в частности, потому что нахожу, что это действительно помогает новым разработчикам в нашей компании войти в продукт и код, работая на этом уровне над вопросами качества кода. Вы новый SA в своей компании, и они заставляют вас делать эту работу, чтобы войти в систему? Если так, то, возможно, это нормально на короткое время. Если это ваша ежедневная работа, которая длилась более года, то вполне возможно, что пришло время искать другую роль.

Я понимаю ваше разочарование, но понимаю, что если вы написали код или были последними, кто его коснулся, времени мало, и они могут связаться с вами, многие менеджеры будут обращаться к вам, чтобы исправить это, независимо от вашего названия.

Подсчитав, что у вас еще есть друзья в группе разработчиков, которая находится в кризисе, вы поможете. Проблема в том, что когда они и, что еще важнее, их руководство привыкли к тому, что вы помогаете, они продолжают возвращаться. Как говорится, «ни одно доброе дело не остается безнаказанным». Если они могут рассчитывать на то, что вы исправите проблемы, независимо от вашего звания, вы просто еще один разработчик и кто-то еще, кого они могут использовать.

Это сложная проблема, но мой совет:

1. Спросите номер платы за проект в это время проекта, не относящееся к архитектору программного обеспечения Я считаю, что руководители проектов не так стремятся просить вашего времени, если они должны нести ответственность за это.

2. Поговорите со своим менеджером о том, сколько времени теряется и на какие группы или проекты. Ваш менеджер может сказать вам, чтобы не помогать им, и сосредоточиться на своих проектах. Если так, то приходит другая группа и просит помощи, вы говорите, что ваш начальник сказал, что не слишком.

3. Организуйте свою работу, сохраняя свои приоритеты, и не будьте так чутки к внешним архитектурным проектам.

4. Действуйте как архитектор, пусть ваши коллеги видят в вас архитектора, а не разработчика, которым вы были все эти годы. У вас есть привычка относиться к вам как к разработчику.

Удачи.

Нет, ты здесь, чтобы управлять общей картиной.

У вас есть проблема с управлением: исправление ошибок и улучшение качества кода - это задача разработчиков, как архитектор, вы должны выпускать руководства и реальную архитектуру (UML или что-то еще, что не соответствует вашей лодке), а затем регулярно проверять код, чтобы убедиться, что эти рекомендации выполняются правильно. ,

Вы можете, однако, реализовать и исправить ошибки в базовой архитектуре.

Пример: вы будете работать с PRISM, MEF и т. Д. В проекте WPF / C #, но вы не будете работать с XAML для отображения заставки.

Вы бы работали над дизайном БД, но не писали бы хранимые процедуры для операций CRUD.

и т.п.

Часть ответа будет найти инженера, который готов взять на себя эту нагрузку.

Конечно, причина этой проблемы в том, что вы считаете эту работу нежелательной, поскольку она не посылает сообщение о том, что она привлекательна для других инженеров, поэтому они не хотят ее поднимать.

Я вижу две возможности.

1. Вам дали должность архитектора, чтобы вы могли работать над более крупными элементами изображения.
   В этом случае вы должны указать руководству, что вы не можете работать с этими более крупными элементами изображения, потому что никто не подошел к роли поддержки более низкого уровня. Это то, что их проблема, чтобы решить.

2. Название в значительной степени церемониальное - кость, брошенная вам, чтобы держать вас рядом.

В этом случае руководство может быть не очень заинтересовано в облегчении вашей поддержки.

-

Одна вещь, которая определенно не будет полезна для вашей цели, - это проявление презрения к другим разработчикам и инженерам, которое я вижу в вашем вопросе. Вы хотите, чтобы эти люди подошли и уверенно справились с этими проблемами, чтобы вам не пришлось (возможно, делать некоторые ошибки в процессе). Если они знают, что вы просто оскорбляете их решения и впоследствии исправляете их, они, вероятно, никогда не собираются повышаться.

50% моего времени провел в Notepad ++, анализируя журналы программного обеспечения и пытаясь выяснить, что пошло не так. 30% исправление чужих ошибок и оставшаяся (если таковая имеется) проверка кода разработчиков спагетти.

Это определенно тип работы, которую вы НЕ должны выполнять для этой роли. Согласно моему опыту / наблюдениям, архитектор должен быть вовлечен в разработку приложений, улучшения, разъяснения технических требований и потенциальные проблемы с производительностью (не проверять журналы каждый день, а в первую очередь анализировать серьезные проблемы / ошибки), которые необходимо устранить или избежать.

Другими словами, моя точка зрения № 1 заключается в том, что архитекторы - это дизайнеры высокого уровня и системные интеграторы, обладающие практическим опытом того, как внутренние технологии работают / применяются и должны использоваться.

Если у вас есть возможность назначать и управлять качеством кода, ваши навыки управления работой должны быть улучшены. Таким образом, планирование работы должно быть вашим приоритетом на подходе «как сделать работу».

Пункт № 2 : если вы один из немногих разработчиков этих приложений - тогда этот заголовок является еще одной сахарной глазурью со стороны руководства компании, чтобы вы могли оставаться в той же роли «исправить это» с новым причудливым названием .

Роль архитектора программного обеспечения намного больше, чем то, что вы делаете в вашей нынешней компании. Он отвечает за определение стандартов проектирования программного обеспечения, разработку дизайна высокого уровня, стандартов кодирования и т. Д., А исправление ошибок может считаться лишь малой частью, хотя на самом деле это не так. Но, как вы уже сказали, вы работаете над продуктом, это означает, что вы, будучи архитектором программного обеспечения, ожидаете от вас высокой надежности продукта, и в таком случае ваше участие в таких вещах будет не только помочь продукту, но и компании, так как вы достаточно опытны в этом. Но вам также следует предоставить некоторую информацию о разработке новых функций и новых задачах, которые пробудят в вас интерес к вашей нынешней организации.

Как архитектор программного обеспечения, я должен сосредоточиться на анализе журналов и исправлении ошибок других?

Говоря «Да».

Вот как я могу квалифицировать свой ответ:

1. По умолчанию вы должны позволить разработчикам программного обеспечения анализировать журналы и исправлять ошибки.
2. Однако ... Вы должны знать о дефектах, которые привели к потере данных, требуют обременительного отката базы данных, занимают много времени для разработчиков или требуют извинений клиентов.
   1. Как правило, ваши прямые отчеты должны сообщать вам о таких дефектах.
   2. Вы должны создать культуру , в которой ваши подчиненные чувствуют себя уполномоченную рассказать вам о таких дефектах, но не принуждены сказать вам о тривиальных.

Больше на # 2:

1. Эти типы дефектов обычно подразумевают архитектурный недостаток. Когда они это сделают, вы должны понять точную природу дефекта и разработать исправление.
   1. Таким образом, вы должны быть готовы, готовы и иметь возможность просматривать журналы и исправлять ошибки других людей (даже если вы не вносите код непосредственно в репозиторий исходного кода).

Ответ, вероятно, нет. Почему вы тратите так много времени на устранение неполадок и поддержку? Кто-то поручает вам эту работу?

Похоже, вам нужно уточнить, что вы должны делать. Возможно, вам придется исправить ошибки; это, вероятно, не должно быть большую часть вашего времени.