Изображение пути в виде лестницы просто для наглядности

Привет, дорогой читатель! Если ты решил идти именно по карьерной лестнице архитектора, то, надеюсь, эта статья поможет тебе сделать это самым оптимальным способом, без отклонений от прямого пути. Вероятно, есть и другие оптимальные способы стать хорошим архитектором, но, на мой взгляд, это те самые 20% усилий по принципу Паретто, для охвата 80% всего необходимого.

Изнутри наружу

Часто в процессе обучения программированию уделяется большое внимание алгоритмам и структурам данных. Иногда фреймворкам и языковым конструкциям. Безусловно, это важно для выполнения разработческих задач, но для архитектора намного важнее знания принципов построения систем, интеграций, признанных технологий и принципов их работы. Почему принципы работы важны? Когда выйдет очередная технология, а это произойдет довольно скоро, тебе достаточно будет выяснить, а что у нее под капотом. И если это что-то знакомое, тогда тебе сразу же станет понятно, как в целом она работает.

Что делать:

Посмотри на технологии, применяющиеся на твоем проектепродукте, Изучи, как они устроены.

Вообще, смотри вширь! Будь любопытным, изучай все, что окружает код твоего проекта/продукта.

Интеграции

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

Синхронная передача небольших объемов данных
Асинхронная передача небольших объемов данных
Передача больших объемов данных

Что делать:

Изучи уровни передачи данных между физическими устройствами. (модель Oci, Основы построения сетей).
Изучи современные общепризнанные прикладные протоколы (например: Rest, Graphql, Websocket).

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

Архитектуры систем

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

Что делать:

Изучи, какие есть архитектуры.
Посмотри на структуру проекта/продукта, в котором работаешь, как разбит код, как происходит выпуск в продуктив, как продукт работает в рантайме.
Попробуй определить, какая из типовых архитектур используется. Почему выбрали именно ее.
Где Какие используются интеграционные паттерны? (например: Repeater, Circuit, Breaker, Service, Discovery, Sidecar и др. ).

_{Стараюсь писать максимально порусски, но в Ит, на мой взгляд, английские слова стали именами нарицательными, и переводить это на русский, только запутает читателя.}

На мой взгляд, все в одну кучу. Но просто для кругозора - нормально.

Типовые архитектуры, ссылка 1

Типовые архитектуры, ссылка 2

Технологии и области их применения

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

Что делать:

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

Хранение данных

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

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

Что делать:

Посмотри типовые архитектуры с хранилищами данных (пулл соединений, промежуточный кэш, шардирование, primary-stand. by).
Изучи типы систем для хранения данных, какой для чего нужен, какие ограничения (например: векторные базы данных, графовые, timeseries).
Прочитай про аналитические хранилища и организацию обработки данных (ETL, витрины).
Узнай, почему была выбрана именно эта система хранения данных в твоем продуктепроекте. Какие рассматривались еще решения.

Фронтенд (если ты бэкенд разработчик)

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

Что делать:

Если ты не фронтенд разработчик, пообщайся с ними. Посмотри, как сделано получение информации из API и в какой момент. (например: lazy loading, предзагрузка).
Узнай о способах композиции UI (iframe, Web Components).

Кибербезопасность

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

Что делать:

Попробуй узнать, как организована защита систем в вашей компании (например: шифрование, файерволлы, списки разрешенных адресов, обратные прокси).
Чем сканируются системы и анализируются логи (например: сканирование Docker образов и библиотек перед загрузкой в реестр или периодические penetration test на системы).
Как хранятся данные и разделяется доступ к ним. Какие есть регламенты по доступу к данным.

Вот здесь и здесь написано самое основное.

Отказоустойчивость и время восстановления

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

Что делать:

Попытайся выяснить архитектуру развертывания вашего продукта. Саппорт должны знать.
Поищи план восстановления (DRP план), чтобы было хотя бы представление, какой есть способ восстановления систем при отказе.
Поинтересуйся, какие есть системы мониторинга и алертинга (например: Grafana, Zabbix).

Основные моменты можно глянуть здесь.

Коммуникации и презентации

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

Что делать:

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

Дополнительные советы

Не обязательно быть экспертом во всем

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

Практический опыт

Теоретические знания - это хорошо, но без практического опыта стать архитектором невозможно.

Эксперименты: "Играйся" с различными технологиями, создавай простые приложения, изучай их поведение.
Участие в проектах: Принимай участие в проектах различной сложности, чтобы получить опыт работы с различными архитектурными подходами и технологиями.

Постоянное развитие

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

Из ресурсов по технологиям могу порекомендовать:

Люди, к кому стоит прислушиваться:

Роберт Мартин
Мартин Фаулер
Крис Ричардсон
Нил Форд

Заключение

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

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

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

Как джуниор разработчику стать архитектором