Кодер -> Программист -> Архитектор?

Предыстория

В одном из докладов на небольшой it-конференции однажды была описана градация развития программиста по уровню решения задач (по памяти формулировка неточная):
  1. Написание кода - когда руководитель дает четкое описание, которое нужно перевести в код, со входными и выходными данными
  2. Решение небольших задач - когда необходимо самому продумывать способ решения данной задачи (это может быть метод, модуль и т.п.)
  3. Решение задач бизнеса - когда нужно спроектировать решение проблемы бизнеса, взаимодействовать с людьми вовлеченными в это, на выходе может получиться не просто модуль, а отдельный проект со своими правилами
  4. Решение задач пользователей - планирование развития программного продукта, взаимодействие с большей аудиторией.
  5. Решение глобальных задач - то, что "меняет мир", написание инструментария, платформы для решения более широкого списка задач

Из этого выходит, что если уровень "написания кода" обозначает кодера, уровень "решения задач" - "программиста", то следующий уровень - "решение задач бизнеса" - будет соответствовать "архитектору".
Является ли переход программист-архитектор последовательным профессиональным ростом?

Как происходит это развитие? Некоторые советуют часто менять работу, чтобы пробовать разные проекты в разных предметных областях, изучать их и черпать понимание архитектуры оттуда. Но этот способ не для всех.
Также очевидно, что только хорошей технической подготовки не хватит для построения с нуля архитектуры ИС для бизнеса.
Какие нужны дополнительные знания для этого и где/как их эффективнее всего получить? В какую сторону гуглить, с чего начинать?
  • Вопрос задан
  • 4074 просмотра
Решения вопроса 1
saboteur_kiev
@saboteur_kiev Куратор тега Карьера в IT
software engineer
Архитектор - в первую очередь опыт работы, в идеале в разных проектах, чтобы понимать на практике разницу между реализацией разных SDLC.

Название Waterfall или Scrum - это просто названия без конкретной реализации. Можно реализовать отличный Waterfall и все будут довольны, можно реализовать ужасный Scrum и все развалится. Поэтому опыт разных проектов помогает увидеть именно разные реализации.

Архитектор, бизнес-аналитик и менеджер - три звена, которые создают основу работы проекта, каждый со своей стороны.
Бизнес-аналитик - должен максимально разбираться в бизнесе заказчика, чтобы понимать значение требований и переводить их для исполнителей.
Архитектор - должен как минимум немного разбираться в бизнесе, но его основная задача - решить как воплощать требования бизнеса. Определять железо, технологии, требования. Говорить, что "вот для этого нужно использовать 10 этого и 20 этого, и использовать вот такие языки, библиотеки, платные решения". Техническое hi-level видение проекта.
Менеджер - по согласованию с бизнес-аналитиком и архитектором должен решать кадровые вопросы. Количество людей, качество людей, работу команды, тайминги, офис и оборудование - все денежные вопросы. Отчеты. Договариваться, убеждать заказчика о ценах и сроках. Выбивать новые задачи и развивать проект. Следить за настроением в команде.

Переход программист-архитектор не всегда последователен. Он должен быть инициирован программистом.

Программист может остаться просто сеньор программистом, может стать тим-лидом, тратя часть времени на менджмент команды но все-равно основную часть времени оставляя на кодинг.

Но кодить крутые штуки и одновременно быть архитектором, который тратит приличное время на митинги - это сложно. Поэтому программист - архитектор это связано, но не всегда последовательно.
Ответ написан
Пригласить эксперта
Ответы на вопрос 5
@Ambrosian
Кодер - это просто джун.
Ведомое существо, которого ни в коем случае нельзя пускать на свободную от контроля область, а то он такого накодит, что потом перекодивать заново.

Архитектор - не знаю где вы начитались. Любой разработчик с опытом - в той или иной мере архитектор. В современном высококонкурентном мире держать себе выделенных архитекторов могут позволить немногие конторы. В подавляющем большинстве случаев архитектор - это такой же разработчик.
Ответ написан
Комментировать
@Krava
В последние 2 года только и вижу отсутствие архитектора в команде, а для меня это ключевое звено без которого творится часто хаос., многие компании пренебрегают архитекторами пытаясь сэкономить.
Ответ написан
xmoonlight
@xmoonlight
https://sitecoder.blogspot.com
Является ли переход программист-архитектор последовательным профессиональным ростом?
Да.
В сторону понимания процессов и создания баз данных. (это в самом начале)
Затем - создание схем движения данных по узлам инфраструктуры.
И расчёты нагрузок и узких мест в системе.
После - уже к построению классов и изучению паттернов проектирования.
Ответ написан
Комментировать
@asd111
Обычно должности именно архитектора нет и его обязанности выполняют senior программисты совместно когда они приходят на митинг и обсуждают архитектуру. Самый умный делает начальный план проекта, а потом на совместном обсуждении можно что то добавить или убрать. И такие совместные обсуждения в больших проектах бывают каждую неделю чтобы все были в курсе архитектуры, а не только архитектор.
Т.е. программист редко становится именно архитектором, поскольку такая вакансия большая редкость и обычно рост происходит по двум вариантам:
1. программист, старший программист(senior), директор тех. отдела.
2. программист, менеджер проекта, директор продукта.
В первом варианте больше технической работы, во втором варианте больше финансов и бизнеса. При этом в обоих вариантах на топ должностях очень много общения с людьми.
Ответ написан
Комментировать
lexxpavlov
@lexxpavlov
Программист, преподаватель
У меня есть личное описание уровней программиста, похожее на указанную градацию:
- Джуниор пишет код так, как понял задачу заказчика
- Миддл пишет код так, чтобы хорошо и правильно решить задачу заказчика
- Синьор пишет так, чтобы сделать будущую задачу заказчика (чтобы код проекта был готов к будущим задачам, без переписывания всего проекта с нуля)

Синьор имеет опыт и понимает, что в дальнейшем понадобится в проекте (если нужно - спросит, если нет, то догадается). Именно синьор может быть архитектором, который занимается инфраструктурой проекта, чтобы другие программисты переиспользовали уже готовые части проекта.
Миддл тоже имеет развитые навыки проектирования архитектуры, но часто работает со средними и большими фичами (частями), а не с системными вещами.
Джуниор делает маленькие задачки, его навыки архитектуры относятся к одному или нескольких связанных классов для текущей задачи. Хороший менеджер подбрасывает задачи чуть сложнее, чтобы дать возможность попрактиковаться в архитектуре.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы