17 ноября 2018 года. Нас четверо. Настроение у всех приподнятое — прошли первый этап ШРИ, Школы разработки интферфейсов. Он состоял из лекций и домашних заданий: осваивали разные фронтендерские и околофротендерские технологии, инструменты, Скрам. Знали, что всё это придётся применять в боевом проекте на втором этапе. Но одно дело знать, и другое — действительно реализовать этот проект за ближайшие 5 недель.
Живём мы, кстати, все вчетвером в одном номере в хостеле Netizen. Яндекс поселил нас сюда ещё перед первым этапом. Хороший хостел, модный.
Сегодня презентации проектов. Не мы презентуем, а нам. Подразделения Яндекса приносят продакшен-задачи для внешних и внутренних сервисов, каждая как раз недель на 5, если делать небольшим составом людей. Задачи по большей части фронтендерские (мы же в ШРИ), но есть нюансы: нужно будет и небольшой бэкенд запилить, и дизайн. Старожилы говорят, в первые годы ШРИ было по-другому. Делали абстрактные задачи, не имеющие отношения к продакшену.
Собираемся всем потоком ШРИ 2018 в зале, здесь все, кто допущен до второго этапа. Нас впервые просят разбиться на команды: раньше каждый был сам за себя. Мы вчетвером быстро совещаемся и решаем — раз живём вместе, то и делать проект будем вместе. Команду назвали Bundle. Дальше нам рассказывают про доступные проекты, их больше, чем образовавшихся команд. Значит, у подразделений, откуда проекты поступили, есть стимул делать их интереснее для студентов, иначе можно остаться без исполнителей.
Нам объясняют, что каждая команда будет делать один проект, но сначала нужно выбрать несколько. Дальше система такая: если один проект выбрало несколько команд, то команда-исполнитель определяется среди них рандомно, и так пока все студенты не получат задачи на второй этап. Уходим вместе с нашими кураторами в переговорку, совещаемся, каждый из команды независимо от остальных голосует за понравившиеся проекты. По сумме голосов вычисляем те из них, которые нам как команде интересны.
21 ноября, среда. Два проекта, показавшиеся нам самыми интересными, по системе рандома забирают другие команды. Нам достаётся третий — инструмент для вариативности фронтендерских собеседований.
Разработчикам интерфейсов на собеседованиях в Яндекс часто дают задание на поиск багов в вёрстке поисковой выдачи. Кандидат должен открыть предложенную ссылку, там он увидит выдачу, которая свёрстана с ошибками. Нужно визуально и с помощью консоли JavaScript в браузере найти ошибки и предложить исправления.
Сложность в том, что хочется давать разным кандидатам разные наборы багов, варьировать их в зависимости от ожиданий собеседующего. Но тогда перед каждым интервью нужно садиться и вручную собирать выдачу. Лучше иметь под рукой инструмент, который бы сам её собирал, расставлял по ней баги и формировал ссылку на неё. В то же время сам вид ссылки не должен намекать кандидату, какие баги ему требуется найти. Это хоть и небольшая, но дополнительная сложность, ведь самый простой способ вставлять ошибки автоматически — передавать их через query-параметры в тексте ссылки. Условно, адрес yandex.ru/search/?text=cats&bug=object мог бы вести на выдачу, где блок объектного ответа свёрстан некорректно. Таких намёков давать не хотелось. Требовалось «проксировать» страницу, показывая её по адресу, который невозможно интерпретировать.
Этот проект оказался в списке нашей команды потому, что он разносторонний. Мы понимали — для написания админки собеседующего потребуется бэкенд и немного навыков в дизайне.
22 ноября, четверг. Вообще-то по будням только продолжаются лекции (уже без домашних заданий, для общего развития), а для работы по проекту предусмотрена суббота. В субботу с утра весь поток снова собирается вместе, имея весь день на то, чтобы вместе с менеджером (сотрудником Яндекса) планировать процесс и кодить, и так каждую субботу до окончания ШРИ. Это называется шрикатон, он проходит в офисе.
Но наша команда живёт вместе, так что мы начинаем пораньше. :) Это не очень большой чит — у нас четверых разный режим дня, работа помимо ШРИ. И всё же у нас есть возможность продвинуться по проекту и на неделе тоже.
Выбираем базу данных для бэкенда. У одного из нас, Вани, был опыт работы с MongoDB, это простая база с точки зрения интеграции, так что останавливаемся на ней. Яндекс.Облако предоставит нам кластер Managed MongoDB, чтобы можно было не думать об обслуживании базы. Для удобства работы с БД будем пользоваться библиотекой Mongoose — опишем основные сущности как схемы и модели Mongoose (c типизацией, взаимосвязями, валидацией). Чтобы базу можно было поднять локально, добавим ещё docker-compose.
24 ноября. Первый шрикатон. Каждая команда сидит за своим большим столом, у каждой есть доска — можно расклеить стикеры, смотреть статусы задач, проводить регулярные стендапы. Отвлекаешься только на обед. Кураторы нам помогают: консультируют по технической составляющей, рассказывают, как организовать общение, как из нас, четырёх разных людей, создать команду, работать по Скраму, нарисовать канбан-доску, ставить задачи, в общем — начать превращать идею в продукт.
Распределяем роли: двое из нас займутся фронтендом админки, а другие двое — бэкендом. В Яндексе такой бэк называют backend for frontend — используем прослойку из сервера на Node.js. Сервер решаем писать на языке TypeScript — выбираем именно его для соблюдения строгой типизации и реализации концепции ООП в полной мере. Для маршрутизации на сервере берём минималистичный, гибкий и функциональный веб-фреймворк Express. Понимаем, что бэк и фронт должны разрабатываться независимо, поэтому вводим временные «заглушки» — вручную подготовленные данные для фронта, как если бы их формировал и передавал уже работающий бэк. Пишем документацию в сервисе Swagger к каждой HTTP-ручке, чтобы правильно интерпретировать заглушки и чтобы потом было достаточно достаточно все их убрать и схлопнуть фронт и бэк. Для этого готовимся писать REST API.
Определяем главную цель — реализовать четыре сущности:
— сервер для админки,
— клиентскую часть для админки,
— инфраструктуру,
— страницы с багами.
В конце каждого шрикатона (их четыре) кто-то из команды должен выступить и показать демо с промежуточными результатами по проекту. Договариваемся, что каждый из нас проведёт по одному демо целиком. На первом демо показываем в основном вёрстку с багами — в том виде, в котором её будут изучать кандидаты на собеседованиях. Показываем и базовую админку — те её части, которые успели сделать за первый день.
Неделя с 26 ноября по 2 декабря. Зима и наш проект набирают обороты. Обговорили и задокументировали API и контракты по обмену информацией между клиентом и сервером.
Договариваемся сделать в админке больше функциональности, чем сказано в ТЗ. Дело в том, что кандидат, которому мы показываем вёрстку с багами, может потом поделиться ссылкой на эту страницу со знакомым или во фронтендерском сообществе, чтобы упростить жизнь другим кандидатам. Значит, ссылка должна через какое-то время «сгорать», становиться неработоспособной. Это было известно сразу, ещё когда нам давали проект, но мы теперь хотим для удобства собеседующего выводить в админке редактируемое поле с точным временем «жизни» ссылки.
Кроме того, добавляем историю. Админка в своём первоначальном виде была только инструментом для генерации ссылок. История, подумали мы, позволит посмотреть, какие ссылки уже были сгенерированы и в течение какого времени они действовали. Ещё мы добавили возможность для собеседующих прикреплять к записям в истории текстовые комментарии (в свободной форме).
Демо на втором шрикатоне по-прежнему показываем с заглушками — бэкенд ещё пилится. В процессе тестирования демо находим ряд проблем с архитектурой, вносим их в бэклог с высоким приоритетом.
Неделя с 3 по 9 декабря. Очередной спринт. Определили, что оптимальная для нас длина спринта — 6 дней, начиная с понедельника и заканчивая шрикатоном в субботу. После шрикатонов, по воскресеньям, устраиваем ретро и составляем бэклог на следующий спринт.
Практикуем код-ревью. Каждый пул-реквест ревьюится по меньшей мере двумя членами команды (за редким исключением в виде пул-реквестов, содержащих незначительные исправления). Стараемся использовать следующие практики:
— не затягивать с проверкой пул-реквеста,
— писать рецензии в виде запросов на обсуждение, а не команд,
— в замечаниях объяснять не только предлагаемое изменение, но и причину,
— щедро использовать примеры кода и ссылки на полезные ресурсы.
Возник вопрос по редизайну. Мы реализовали дизайн, который нам в виде макетов Яндекс предоставил изначально, но количество фич возросло, в админке нужны изменения, в том числе визуальные. Общаемся с заказчиками, договариваемся о частичном редизайне, начинаем его делать.
Исправляем проблемы в архитектуре, избавляемся от заглушек между фронтендом и бэкендом, подключаем БД. Составленная нами документация помогла: когда мы отключили заглушки и внесли совсем небольшие корректировки, то данные стали корректно поступать с бэка на фронт. Впервые показываем демо в боевом режиме.
Последние две недели. Меняемся местами: двое из нас, которые отвечали за фронт, теперь отвечают за бэк — и наоборот. Мы придумали такую схему для того, чтобы каждый из нас знал проект целиком. Попутно обсуждаем с менеджером и заказчиками детали процесса по внедрению админки в продакшен. Руководитель группы тестирования интерфейсов поиска Оля Молчанова очень нам помогла, мы согласовали конкретные шаги по внедрению.
Чтобы составить технический отчёт по проекту (это требуется от всех команд), пишем, почему выбрали тот или иной подход или инструмент:
Реализовали UI как Single Page Application из-за большого количества плюсов перед «классическими» многостраничными сайтами. Во-первых, SPA напоминает простые нативные приложения, разница лишь в том, что они исполняются в браузере, а не в собственном процессе операционной системы. Во-вторых, у таких приложений всегда богатый UX. Из-за того, что у нас всего одна веб-страница, построить насыщенный и функциональный пользовательский интерфейс гораздо проще. При этом удобно хранить и обновлять состояние представлений, а также управлять им. В-третьих, SPA исключает постоянные запросы к одному и тому же контенту при перемещении по сайту.
Минусы у SPA тоже есть. Когда собеседующий впервые откроет админку, ему потребуется загрузить чуть больше данных. Однако в нашем проекте собранный bundle в сжатом виде (gzip) весит чуть более 100 КБ и разбивается на фрагменты (chunks). В итоге сайт отрисовывается одинаково быстро. К минусам SPA традиционно относят и то, что практически все поисковые роботы и социальные сети не видят контент таких сайтов. Наше приложение разрабатывалось для внутреннего использования, поэтому нам не нужно использовать серверный рендеринг или вообще как-то заботиться о SEO.
В качестве библиотеки для разработки SPA-приложения был выбран React, так как:
— многие новые проекты в Яндексе пишутся на React, а старые переписываются,
— можно использовать библиотеку компонентов Лего,
— все члены команды были знакомы с React,
— у React 117 697 звездочек на GitHub, комьюнити состоит из миллионов разработчиков.
Для удобной работы с датами (в частности, для вывода оставшегося промежутка времени действия ссылки) используется библиотека Moment.js.
Ещё в техническом отчёте нужно перечислить, что каждый из нас узнал нового. Общее из четырёх списков:
1. Оценили всю мощь TypeScript. Язык позволяет отловить ошибки при написании кода, делает рефакторинг и добавление фич приятнее. Познакомились с организацией проекта на основе нескольких конфиг-файлов.
2. Поработали в парадигме микросервисной архитектуры и монорепозитория.
3. Узнали много нового про React (в том числе от друг друга). Поняли, как организовывать компоненты, чтобы их было легче поддерживать и переиспользовать.
4. Кто-то из нас открыл для себя, а кто-то доосвоил разные инструменты:
— Docker и Docker Compose. Научились устанавливать, базово конфигурировать и запускать контейнеры.
— Git. Закрепили на практике разбор, создание, вливание пул-реквестов. Доосознали важность этого процесса.
— Библиотека Moongose, админка mongo-express.
— Яндекс.Облако.
— Swagger.
— BitBucket.5. Получили колоссальный скачок в развитии благодаря командной разработке.
— Научились работать в команде по скраму.
— Поработали в Трекере задач, познакомились с канбан-доской, спринтами. В реальных условиях поняли, насколько продуктивнее вести разработку короткими циклами с постоянным фидбеком.
— Настроили CI через TeamCity.
— Увидели, что код-ревью полезно для всех участников. Порой чтение чужого кода приносит больше пользы, чем написание.
— Поработали с менеджером проекта, это приближало разработку к «полевым» условиям.
— За счёт регулярных демо получили навыки публичных выступлений.
Доделываем сервис, выполняем комплексное тестирование, составляем документацию. Параллельно нужно готовиться к нашим собственным собеседованиям в Яндекс — часть из них пройдёт уже на следующий день после сдачи проекта! Это и плохая новость (потому что подготовка немного отвлекает от проекта), и хорошая (потому что дальнейшие шаги не откладываются в долгий ящик).
23 декабря. Финальный день ШРИ, мы выступаем с готовым проектом. Ваня рассказывает, остальные трое присоединяются для ответов на вопросы. Резюме — мы сделали админку, которая позволяет сотруднику перед собеседованием по фронтенду создать URL поисковой выдачи, свёрстанной с ошибками. Эти ошибки расставляются автоматически за несколько секунд — достаточно указать их галочками. Кроме того, собеседующий может посмотреть историю ссылок и задать время жизни для своего URL. А на самом интервью, как уже было сказано, кандидат получает ссылку и должен найти и исправить все ошибки. Мы добавили в админку возможность подготовить страницу с багами не только на основе интерфейса поиска, но и любого другого сервиса, если это нужно для собеседования.
На серверной стороне используется NodeJS и фреймворк Express для интерфейса и обработки REST API-запросов. Клиентская часть — React. Полный технический отчёт по проекту выложили на Диск.
Авторы этого поста :)
24 декабря. Расходимся не сразу — ещё около недели живём в хостеле и проходим собеседования. Выписываемся только ближе к Новому году.
21 мая 2019 года. Теперь каждый из нас четверых работает в Яндексе, уже не на стажировке, а на бессрочном договоре. Мы — это разработчики интерфейсов Евгений Гончаренко, Иван Колобаев, Сергей Махлонов и Евгений Старостин. Системой, которую мы сделали в качестве выпускного проекта в ШРИ, постоянно пользуются на собеседованиях.
9 июля. Публикуем этот пост.
Автор: Евгений Гончаренко
