Хабрахабр

TypeScript и короткие спринты. Как мы делали инструмент вариативности интервью по фронтенду

Нас четверо. 17 ноября 2018 года. Он состоял из лекций и домашних заданий: осваивали разные фронтендерские и околофротендерские технологии, инструменты, Скрам. Настроение у всех приподнятое — прошли первый этап ШРИ, Школы разработки интферфейсов. Но одно дело знать, и другое — действительно реализовать этот проект за ближайшие 5 недель. Знали, что всё это придётся применять в боевом проекте на втором этапе.

Яндекс поселил нас сюда ещё перед первым этапом. Живём мы, кстати, все вчетвером в одном номере в хостеле Netizen. Хороший хостел, модный.

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

Нас впервые просят разбиться на команды: раньше каждый был сам за себя. Собираемся всем потоком ШРИ 2018 в зале, здесь все, кто допущен до второго этапа. Команду назвали Bundle. Мы вчетвером быстро совещаемся и решаем — раз живём вместе, то и делать проект будем вместе. Значит, у подразделений, откуда проекты поступили, есть стимул делать их интереснее для студентов, иначе можно остаться без исполнителей. Дальше нам рассказывают про доступные проекты, их больше, чем образовавшихся команд.

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

Два проекта, показавшиеся нам самыми интересными, по системе рандома забирают другие команды. 21 ноября, среда. Нам достаётся третий — инструмент для вариативности фронтендерских собеседований.

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

Но тогда перед каждым интервью нужно садиться и вручную собирать выдачу. Сложность в том, что хочется давать разным кандидатам разные наборы багов, варьировать их в зависимости от ожиданий собеседующего. В то же время сам вид ссылки не должен намекать кандидату, какие баги ему требуется найти. Лучше иметь под рукой инструмент, который бы сам её собирал, расставлял по ней баги и формировал ссылку на неё. Условно, адрес yandex.ru/search/?text=cats&bug=object мог бы вести на выдачу, где блок объектного ответа свёрстан некорректно. Это хоть и небольшая, но дополнительная сложность, ведь самый простой способ вставлять ошибки автоматически — передавать их через query-параметры в тексте ссылки. Требовалось «проксировать» страницу, показывая её по адресу, который невозможно интерпретировать. Таких намёков давать не хотелось.

Мы понимали — для написания админки собеседующего потребуется бэкенд и немного навыков в дизайне. Этот проект оказался в списке нашей команды потому, что он разносторонний.

Вообще-то по будням только продолжаются лекции (уже без домашних заданий, для общего развития), а для работы по проекту предусмотрена суббота. 22 ноября, четверг. Это называется шрикатон, он проходит в офисе. В субботу с утра весь поток снова собирается вместе, имея весь день на то, чтобы вместе с менеджером (сотрудником Яндекса) планировать процесс и кодить, и так каждую субботу до окончания ШРИ.

🙂 Это не очень большой чит — у нас четверых разный режим дня, работа помимо ШРИ. Но наша команда живёт вместе, так что мы начинаем пораньше. И всё же у нас есть возможность продвинуться по проекту и на неделе тоже.

У одного из нас, Вани, был опыт работы с MongoDB, это простая база с точки зрения интеграции, так что останавливаемся на ней. Выбираем базу данных для бэкенда. Для удобства работы с БД будем пользоваться библиотекой Mongoose — опишем основные сущности как схемы и модели Mongoose (c типизацией, взаимосвязями, валидацией). Яндекс.Облако предоставит нам кластер Managed MongoDB, чтобы можно было не думать об обслуживании базы. Чтобы базу можно было поднять локально, добавим ещё docker-compose.

Первый шрикатон. 24 ноября. Отвлекаешься только на обед. Каждая команда сидит за своим большим столом, у каждой есть доска — можно расклеить стикеры, смотреть статусы задач, проводить регулярные стендапы. Кураторы нам помогают: консультируют по технической составляющей, рассказывают, как организовать общение, как из нас, четырёх разных людей, создать команду, работать по Скраму, нарисовать канбан-доску, ставить задачи, в общем — начать превращать идею в продукт.

В Яндексе такой бэк называют backend for frontend — используем прослойку из сервера на Node.js. Распределяем роли: двое из нас займутся фронтендом админки, а другие двое — бэкендом. Для маршрутизации на сервере берём минималистичный, гибкий и функциональный веб-фреймворк Express. Сервер решаем писать на языке TypeScript — выбираем именно его для соблюдения строгой типизации и реализации концепции ООП в полной мере. Пишем документацию в сервисе Swagger к каждой HTTP-ручке, чтобы правильно интерпретировать заглушки и чтобы потом было достаточно достаточно все их убрать и схлопнуть фронт и бэк. Понимаем, что бэк и фронт должны разрабатываться независимо, поэтому вводим временные «заглушки» — вручную подготовленные данные для фронта, как если бы их формировал и передавал уже работающий бэк. Для этого готовимся писать REST API.

Определяем главную цель — реализовать четыре сущности:

  • сервер для админки,
  • клиентскую часть для админки,
  • инфраструктуру,
  • страницы с багами.

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

Зима и наш проект набирают обороты. Неделя с 26 ноября по 2 декабря. Обговорили и задокументировали API и контракты по обмену информацией между клиентом и сервером.

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

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

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

Очередной спринт. Неделя с 3 по 9 декабря. После шрикатонов, по воскресеньям, устраиваем ретро и составляем бэклог на следующий спринт. Определили, что оптимальная для нас длина спринта — 6 дней, начиная с понедельника и заканчивая шрикатоном в субботу.

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

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

Возник вопрос по редизайну. Мы реализовали дизайн, который нам в виде макетов Яндекс предоставил изначально, но количество фич возросло, в админке нужны изменения, в том числе визуальные. Общаемся с заказчиками, договариваемся о частичном редизайне, начинаем его делать.

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

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

Чтобы составить технический отчёт по проекту (это требуется от всех команд), пишем, почему выбрали тот или иной подход или инструмент:

Во-первых, SPA напоминает простые нативные приложения, разница лишь в том, что они исполняются в браузере, а не в собственном процессе операционной системы. Реализовали UI как Single Page Application из-за большого количества плюсов перед «классическими» многостраничными сайтами. Из-за того, что у нас всего одна веб-страница, построить насыщенный и функциональный пользовательский интерфейс гораздо проще. Во-вторых, у таких приложений всегда богатый UX. В-третьих, SPA исключает постоянные запросы к одному и тому же контенту при перемещении по сайту. При этом удобно хранить и обновлять состояние представлений, а также управлять им.

Когда собеседующий впервые откроет админку, ему потребуется загрузить чуть больше данных. Минусы у SPA тоже есть. В итоге сайт отрисовывается одинаково быстро. Однако в нашем проекте собранный bundle в сжатом виде (gzip) весит чуть более 100 КБ и разбивается на фрагменты (chunks). Наше приложение разрабатывалось для внутреннего использования, поэтому нам не нужно использовать серверный рендеринг или вообще как-то заботиться о SEO. К минусам SPA традиционно относят и то, что практически все поисковые роботы и социальные сети не видят контент таких сайтов.

В качестве библиотеки для разработки SPA-приложения был выбран React, так как:

  • многие новые проекты в Яндексе пишутся на React, а старые переписываются,
  • можно использовать библиотеку компонентов Лего,
  • все члены команды были знакомы с React,
  • у React 117 697 звездочек на GitHub, комьюнити состоит из миллионов разработчиков.

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

Ещё в техническом отчёте нужно перечислить, что каждый из нас узнал нового. Общее из четырёх списков:

Язык позволяет отловить ошибки при написании кода, делает рефакторинг и добавление фич приятнее. 1. Оценили всю мощь TypeScript. Познакомились с организацией проекта на основе нескольких конфиг-файлов.

2. Поработали в парадигме микросервисной архитектуры и монорепозитория.

Поняли, как организовывать компоненты, чтобы их было легче поддерживать и переиспользовать. 3. Узнали много нового про React (в том числе от друг друга).

4. Кто-то из нас открыл для себя, а кто-то доосвоил разные инструменты:

Научились устанавливать, базово конфигурировать и запускать контейнеры.
— Git. — Docker и Docker Compose. Доосознали важность этого процесса.
— Библиотека Moongose, админка mongo-express.
— Яндекс.Облако.
— Swagger.
— BitBucket. Закрепили на практике разбор, создание, вливание пул-реквестов.

5. Получили колоссальный скачок в развитии благодаря командной разработке.

В реальных условиях поняли, насколько продуктивнее вести разработку короткими циклами с постоянным фидбеком.
— Настроили CI через TeamCity.
— Увидели, что код-ревью полезно для всех участников. — Научились работать в команде по скраму.
— Поработали в Трекере задач, познакомились с канбан-доской, спринтами. Порой чтение чужого кода приносит больше пользы, чем написание.
— Поработали с менеджером проекта, это приближало разработку к «полевым» условиям.
— За счёт регулярных демо получили навыки публичных выступлений.

Доделываем сервис, выполняем комплексное тестирование, составляем документацию. Параллельно нужно готовиться к нашим собственным собеседованиям в Яндекс — часть из них пройдёт уже на следующий день после сдачи проекта! Это и плохая новость (потому что подготовка немного отвлекает от проекта), и хорошая (потому что дальнейшие шаги не откладываются в долгий ящик).

Финальный день ШРИ, мы выступаем с готовым проектом. 23 декабря. Резюме — мы сделали админку, которая позволяет сотруднику перед собеседованием по фронтенду создать URL поисковой выдачи, свёрстанной с ошибками. Ваня рассказывает, остальные трое присоединяются для ответов на вопросы. Кроме того, собеседующий может посмотреть историю ссылок и задать время жизни для своего URL. Эти ошибки расставляются автоматически за несколько секунд — достаточно указать их галочками. Мы добавили в админку возможность подготовить страницу с багами не только на основе интерфейса поиска, но и любого другого сервиса, если это нужно для собеседования. А на самом интервью, как уже было сказано, кандидат получает ссылку и должен найти и исправить все ошибки.

Клиентская часть — React. На серверной стороне используется NodeJS и фреймворк Express для хостинга интерфейса и обработки REST API-запросов. Полный технический отчёт по проекту выложили на Диск.

Авторы этого поста 🙂

24 декабря. Расходимся не сразу — ещё около недели живём в хостеле и проходим собеседования. Выписываемся только ближе к Новому году.

Теперь каждый из нас четверых работает в Яндексе, уже не на стажировке, а на бессрочном договоре. 21 мая 2019 года. Системой, которую мы сделали в качестве выпускного проекта в ШРИ, постоянно пользуются на собеседованиях. Мы — это разработчики интерфейсов Евгений Гончаренко, Иван Колобаев, Сергей Махлонов и Евгений Старостин.

Публикуем этот пост. 9 июля.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть