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

В этой статье мы покажем, как стажировка проходит на практике и что она приносит самим IT-компаниям. В фокусе истории двух магистрантов института прикладных компьютерных наук ИТМО ― Федора Золотухина и Андрея Стояна.

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

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

• Научно-исследовательская работа (НИР) выполняется в течение семестра. Ее можно писать на базе действующих компаний, и зачастую это первый шаг к стажировке, поскольку часто представители бизнеса приглашают “проверенных в деле” студентов к себе. Как раз этим путем пошел наш первый герой статьи.

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

• Диплом также можно писать в рамках исследовательской задачи реальной IT-компании. 

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

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

Первый опыт в DevOps

Незадолго до начала стажировки, во втором семестре пятого курса (первого курса магистратуры), Федор Золотухин выполнял НИР в Azul Systems. Поскольку компания оказалась довольно открытой, и процессы в ней выстроены хорошо, когда встал вопрос стажировки, первым делом он обратился сюда.

Хотя в резюме у Федора не было опыта в DevOps, компания предложила прокачать компетенции в этом направлении. Дело в том, что команда DevOps в Azul Systems не справлялась с существующим объемом задач ― она была слишком маленькой, поскольку основные усилия перед запланированным выпуском продукта шли на разработку бэкенда. Так что Федор включился в работу на позиции джуна.

Во время стажировки он занимался рефакторингом существующей кодовой базы Azul Systems и выстраиванием процессов версионирования и выхода в релиз. Среди прочего подключил автоматический линтинг и переложил пайплайны, написанные в bash для Jenkins, под используемую в компании систему контроля версий. Кроме того, убрал из системы связи с использовавшимся ранее в компании Mercurial SCM. Незадолго до этого команда Azul Systems переехала на Git, однако все ссылки на старый инструмент убрать еще не успели. Так что перед Федором была поставлена задача вычистить их из системы.

Как правило, стажировка ―мероприятие на лето. А осенью Федор продолжил работать над процессами ежедневной доставки новых версий продукта другим командам. Здесь также потребовался перевод некоторых пайплайнов под систему контроля версий.

Продукт, в разработке которого принял участие Федор, в конце осени был выпущен на рынок. Это Azul Vulnerability Detection ― Saas-инструмент, который помогает бизнесу обнаруживать известные уязвимости в Java-приложениях. Он подключается к рантайму Java и на лету детектит уязвимости, даже не имея доступа к исходному коду.

Сам Федор о своей стажировке отзывается очень позитивно:

"Взаимодействие с Azul Systems дало мне понимание, как вообще идет работа в больших компаниях. До этого я сталкивался только со стартапами. Плюс до этой стажировки у меня в резюме не было навыков DevOps. Но теперь я понимаю, как это устроено, знаю, как в компаниях организуют CI/CD не только до конечного пользователя, но и до других команд, представляю, как идет работа в DevOps команде. Да и интересных практических задач было немало. Я, например,  плотнее столкнулся с bash ― пришлось переписывать скрипты на Groovy. В целом работа с Azul Systems продолжается, сейчас я в той же команде пишу диплом, устроившись к ним по срочному трудовому договору".

Разработка образовательной платформы на Haskell

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

Как Андрей поясняет свой выбор:

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

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

Как раз летом в Сириус.Курсах начинался внутренний проект по переносу разных форм настроек методических материалов на другую технологию. Ранее вид формы полностью описывался на фронте, и она отображала данные с бэкенда. Это размывало зоны ответственности фронтенда и бэка, требовалось прикладывать дополнительные усилия на поддержание согласованности между разными командами по каждой форме. Вместо этого было решено сообщать фронту внешний вид формы с бэка и уже на фронте рендерить UI формы некоторым обобщенным образом. Для этого с бэка нужно отдавать одновременно json-схему, которая задаёт компоненты формы, данные для отображения в ней и дополнительную информацию для рендеринга компонент по их json-путям. Фокус в том, что всю эту информацию необходимо было как-то описывать на бэкенде, чтобы используемый для этого доменный язык контролировал происходящее ― следил за тем, чтобы компоненты формы, их опции и данные для отображения были согласованы.

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

DSL на Haskell

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

Описать нужно было три вещи:

• json-схему ― по описанной в ней иерархии компонент на фронте рендерится UI. Для этого используется стандартная json-schema и генераторы форм для неё;

• данные в формате json для заполнения формы, которые должны удовлетворять схеме;

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

  У тривиального решения были бы очевидные проблемы:

  • сложно контролировать валидность json-путей;

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

  Поэтому решено было дополнить описание композитного типа данных (record’a) метаданными UI компонент прямо в типах полей, а также использовать систему вывода инстансов классов типов языка Haskell для автоматической генерации json-путей к нужным компонентам по соответствующей метке доступа к полю record'a.

  Чтобы хранить информацию на уровне типов Андрей использовал идиому phantom types. В Haskell она представлена типом Tagged. Для него Андрей завел синоним и, используя пары уровня типов, обозначил, что именно требуется сохранить в дополнение к данным (ключ имени компоненты для отображения ее названия пользователю в UI и её вид):

В результате композитную компоненту общих настроек модуля можно описывать следующим образом:

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

Решение задачи требует, чтобы у каждой метки доступа рекорда компоненты был инстанс этого класса типов. Haskell такие инстансы сможет вывести автоматически (при этом json-путь до вложенной компоненты дополняется корректно):

Чтобы json-пути выводились для компонент произвольной вложенности, а не только уровня один и два, Андрей создал класс типов вложенной компоненты (у одной компоненты может быть только один родитель, что обозначается с помощью механизма functional dependencies):

Этот класс типов реализован для каждой вложенной композитной компоненты вручную через указание её имени.

А чтобы для каждой вложенной компоненты выводился инстанс класса типов Component с валидным json-путём к ней, необходимо:

Так в любом месте кода можно получить всю информацию о компоненте по метке доступа к ней, например, componentPath generalSettingsModuleType.

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

Сейчас реализованная Андреем библиотека используется в разных местах платформы:

“Кажется, мне удалось добиться разумного баланса между статическими гарантиями, которые дает библиотека, и сложностью ее использования. Читать новым её пользователям спецкурс о том, как создать простейшую форму, не придется”.

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

“А еще мне понравилось работать с тимлидом Сашей. Он очень внимательный, всегда помогает разобраться с постановкой задачи и всегда готов прийти на помощь в процессе решения. Его всегда можно о чем-то спросить. В команде Сириус.Курсов ценят сотрудников, собирают фидбэк о работе, всегда открыты к новым предложениям и решениям. Это очень приятно и создаёт отличную рабочую атмосферу взаимопомощи и поддержки”.

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