IТ-архитектор — это опытный разработчик, который разбирается в устройстве продукта, предлагает решения для его развития и несёт ответственность за их внедрение. Он может заниматься только проектированием или выполнять и другие задачи: например, самостоятельно писать код. 

Академия Яндекса поговорила о работе IT-архитекторов с Костей Крамлихом, руководителем разработки виртуальной сети Yandex.Cloud. Кроме того, мы расспросили его о работе в новосибирском офисе Яндекса, преподавании в Computer Science Center и обучении проектированию сервисов.

Путь из разработки в проектирование

В 2013 году я работал в Movavi и создавал софт для плееров и конвертеров файлов, но в какой-то момент почувствовал, что пора менять работу и расти дальше. Один из моих коллег-разработчиков тогда перешёл в только что открывшийся новосибирский офис Яндекса и много рассказывал о своих впечатлениях. Так я решил тоже попытаться туда попасть: откликнулся на вакансию разработчика, прошёл все собеседования и с октября 2013 года стал работать в Браузере. В команде я отвечал за отдельные компоненты сервиса, проектировал новые возможности и то, как они будут встраиваться в уже существующий код.

Год спустя на фестивале CodeFest нужно было рассказать о Браузере и представить новосибирский офис Яндекса. Я решил: «А почему бы мне не попробовать?» Потом я продолжил выступать на других мероприятиях — пока не стал рассказывать о Браузере везде. Говорят, что сначала ты работаешь «на зачётку», а потом она работает на тебя. Так и мои выступления не прошли незамеченными, и в 2017 году мне предложили читать лекции и оценивать практические занятия студентов в открывшемся новосибирском филиале Computer Science Center. 

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

Практика и преподавание

В 2019 в Computer Science Center срочно понадобился преподаватель по ООП (объектно-ориентированному программированию) и проектированию приложений. Мы подготовили курс вместе с коллегой по Браузеру и куратором из JetBrains: первый отвечал за практические задания, второй общался со студентами и помогал набирать людей, а я делал лекции. Нашей целью было не выпустить опытных проектировщиков, а заложить фундамент для будущей профессии, на который человек мог бы укладывать новые знания. Поэтому мы рассказывали студентам об объектно-ориентированном проектировании, его основных концепциях и паттернах, разбирали примеры архитектур реальных приложений. 

Было здорово, что люди приходили к нам за знаниями, а не просто отсиживались на занятиях, как это часто бывает в университете. Я чувствовал, что приношу пользу, и мне было от этого приятно. В тот же год я перешёл на руководящую позицию в Yandex.Cloud и стал заниматься частью инфраструктуры сервиса — связями между виртуальными машинами. В 2021 году на работе стало больше менеджерских задач, а дома — больше детей (теперь их трое), и поэтому лекции по проектированию я пока больше не веду, но по-прежнему проверяю практические задания студентов. 

Работа архитекторов и пути развития инженеров

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

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

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

Проектирование приложений и цена ошибки

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

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

Проектирование архитектуры должно состоять из нескольких этапов:

1. Определение проблем. Понимаем, какой продукт и для кого мы делаем. 

2. Сбор требований. Собираем информацию для того, чтобы принимать взвешенные решения о том, что мы будем делать. Анализируем проблемы пользователей, рынок и конкурентов.

3. Анализ компонентов для запуска. Обсуждаем, какие функции нужны для запуска MVP, а какие можно доработать в следующих версиях.

4. Построение архитектуры MVP. Находим критические компоненты, отказ которых может вывести продукт из строя (single points of failure). Определяем предельную нагрузку на сам сервис и на остальные компоненты, а также требования к оборудованию и его стоимость. Проектируем систему мониторинга.

5. Постановка и контроль задач. Определяем, кто и в каком порядке делает то, что мы придумали в предыдущем пункте. Оцениваем трудоёмкость задач и контролируем их выполнение.

Знания и навыки, необходимые архитектору

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

Проектирование — это как воспитание детей: сначала долго вкладываешься, а результат получаешь потом.

Поэтому архитектору очень важно быть терпеливым. Примеры изменений в архитектуре сложно уложить в несколько предложений: например, в Браузере мы переписывали отдельные компоненты целиком, а в Yandex.Cloud — переделывали реализацию сети.

Важно учиться всему понемногу. По-моему, роль образования в том, чтобы дать основу и показать предмет с разных сторон для того, чтобы человеку было на что опереться. А за деталями стоит идти на курсы к преподавателю-практику. Здорово, если разработчику во время учёбы дадут попробовать и объектно-ориентированное, и функциональное, и логическое программирование. Ещё полезно позаниматься созданием сайтов и разобраться, как работает ML.  

Самообучение следует начинать с паттернов проектирования. Посоветую книгу “Design Patterns: Elements of Reusable Object-Oriented Software”, которую написали разработчики Эрих Гамма, Ричард Хелм, Ральф Джонсон и Джон Влиссидес — их ещё называют «бандой четырёх». При написании они вдохновлялись книгой Кристофера Александера «Язык шаблонов. Города. Здания. Строительство», которая рассказывает об использовании шаблонов при проектировании домов. Получается, что в совершенно разных областях встречаются общие принципы и закономерности.

Важно читать статьи о том, что и как устроено в разных компаниях — от Netflix до LinkedIn. Стоит углубиться в СookBook, опубликованный на  GitHub, — это хранилище атрибутов, рецептов, шаблонов и файлов на тему проектирования. А инструкции в нём заточены на то, как проходить собеседования в больших компаниях, потому что на них всегда есть секции о проектировании систем.

И, конечно, архитектору нужна практика. Чем больше ты погружаешься во что-то, тем проще тебе наращивать знания и навыки дальше. Этот феномен называется эффектом Матфея. 

Удалёнка и поиск работы

Если говорить о поиске работы, то мне кажется, что сейчас неважно, откуда ты работаешь. Раньше было сложнее договориться с людьми об удалённой работе, а сейчас у меня в подчинении 10 человек, и четверо из них в Москве, трое в Екатеринбурге, а ещё трое — в Новосибирске. Есть ребята, которые не хотят уезжать из родного города. Одних держат семья и недвижимость, другим по душе природа Алтая. Наверное, я консерватор, но и мне в Новосибирске нравится больше, чем в Москве. 

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

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

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