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

**Предыстория**  

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

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

Как происходит это развитие? Некоторые советуют часто менять работу, чтобы пробовать разные проекты в разных предметных областях, изучать их и черпать понимание архитектуры оттуда. Но этот способ не для всех.  

Также очевидно, что только хорошей технической подготовки не хватит для построения с нуля архитектуры ИС для бизнеса.  
**Какие нужны дополнительные знания для этого и где/как их эффективнее всего получить? В какую сторону гуглить, с чего начинать?** 

 Архитектор - в первую очередь опыт работы, в идеале в разных проектах, чтобы понимать на практике разницу между реализацией разных SDLC.  
  

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

Архитектор, бизнес-аналитик и менеджер - три звена, которые создают основу работы проекта, каждый со своей стороны.  

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

Архитектор - должен как минимум немного разбираться в бизнесе, но его основная задача - решить как воплощать требования бизнеса. Определять железо, технологии, требования. Говорить, что "вот для этого нужно использовать 10 этого и 20 этого, и использовать вот такие языки, библиотеки, платные решения". Техническое hi-level видение проекта.  

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

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

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

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

 Кодер - это просто джун.  

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

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

 Между кодером и программистом разницы нет. Будет ли человек делать по готовому ТЗ, или будет думать своей головой - неважно, он остается программистом.  

Архитекторы не решают задач бизнеса. Это именно те люди. которые приносят кодерам ТЗ для работы. Задачи бизнеса решают менеджеры и немного тимлиды, причём первым вовсе необязательно уметь писать программы.  

Дополнительные знания для архитектора зависят от сферы работы. Если вы архитектор где-нибудь в SpaceX, то понятно, что вы должны знать науку физику и методы работы ваших устройств. А так ничего знать больше не надо, любой программист может стать архитектором, если у него есть пара собственных проектов, которые **необычны** и которые он **спроектировал сам** 

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

> **Является ли переход программист-архитектор последовательным профессиональным ростом?**

Да.  

В сторону понимания процессов и создания баз данных. (это в самом начале)  

Затем - создание схем движения данных по узлам инфраструктуры.  

И расчёты нагрузок и узких мест в системе.  

После - уже к построению классов и изучению паттернов проектирования. 

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

Т.е. программист редко становится именно архитектором, поскольку такая вакансия большая редкость и обычно рост происходит по двум вариантам:  

1. программист, старший программист(senior), директор тех. отдела.  

2. программист, менеджер проекта, директор продукта.  

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

 У меня есть личное описание уровней программиста, похожее на указанную градацию:  

- Джуниор пишет код так, как понял задачу заказчика  

- Миддл пишет код так, чтобы хорошо и правильно решить задачу заказчика  

- Синьор пишет так, чтобы сделать будущую задачу заказчика (чтобы код проекта был готов к будущим задачам, без переписывания всего проекта с нуля)  
  

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

Миддл тоже имеет развитые навыки проектирования архитектуры, но часто работает со средними и большими фичами (частями), а не с системными вещами.  

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