Вчера стартовал новый Яндекс.Блиц — на этот раз конкурс будет интересен разработчикам интерфейсов. Обладателям мест с первого по пятое мы предложим устроиться к нам по упрощённой схеме: одна секция собеседования вместо четырёх. Тем самым Блиц остаётся наиболее быстрым способом попасть в Яндекс.
Задачи конкурса вновь приближены к боевым продакшен-задачам — от вас потребуются не только навыки фронтендера, но и знания алгоритмов. Зарегистрируйтесь здесь, чтобы успеть принять участие в квалификационном раунде.
Блиц — хороший повод поговорить об истории алгоритмических задач, возникающих в промышленном фронтенде, и о том, как они отличаются от конкурсных.
О задачах
Алгоритмически насыщенные задачи в разработке интерфейсов в Яндексе возникали всегда. Я могу вспомнить примеры ещё от 2005–2006 года. Одной из таких задач была система работы с абстрактными событиями. Требовалось сделать ядро, которое позволит навешивать обработчики (заданные функцией) на произвольные события (заданные строкой), после чего — вызывать определённое событие и удалять привязку обработчика. Дополнительная сложность состояла в том, что три перечисленные основные операции должны были выполняться максимально быстро. Про это даже есть секция в одном из старых докладов.
Ещё одна интересная задача была про расположение миниатюр в результатах поиска Яндекс.Картинок. Требовалось сделать выравнивание потока прямоугольных объектов одинаковой высоты и разной ширины по правому краю. В общем случае эта задача не имеет решения, поэтому допускалось менять исходные размеры картинки (уменьшать и обрезать), но чтобы потеря информации не превышала какой-то заданный разумный порог в процентах.
Были и задачи, связанные с разработкой шаблонизатора Яндекса, известного по ключевым словам XJST и BEMTHML. Основной сложностью было сделать его достаточно быстрым, сохранив при этом желаемую семантическую выразительность. Подробно про это можно посмотреть в многочисленных докладах, Вот одни из первых докладов с подробностями: events.yandex.ru/lib/talks/43 и events.yandex.ru/lib/talks/329, есть и многие другие.
Всяческие системы обработки в реальном времени, например при скролле и перетаскивании мышкой, тоже часто заставляют поразмыслить. Приходится придумывать разные алгоритмические трюки, чтобы интерфейс — как минимум, субъективно для пользователя — выглядел быстрым, если реальные действия выполняются объективно долго.
Например, в одной из первых версий Яндекс.Почты можно было перетаскивать почти все ключевые элементы друг на друга: письма в папки, метки на письма, письма на метки и даже папки на письма. В процессе, пока у пользователя «в руке» был зажат объект и он водил им по экрану, требовалось подсвечивать те элементы, на которые можно было его «сбросить». Наивная реализация «в лоб» тормозила до невозможности.
Отличия реальных задач от конкурсных
Задачи внутри Яндекса, как правило, решаются в командном режиме. Человек не предоставлен сам себе, как в конкурсе. Он может получить помощь от коллег и должен стыковать способ своего решения с интересами других участников процесса.
Может получиться и так, что ты написал быструю версию, но большинство твоих коллег считают код неоправданно сложным для понимания, развития и будущей поддержки. В таких случаях приходится искать компромиссы. Чаще всего командное взаимодействие устроено как последовательное добавление чего-то в решение или как одновременный процесс парного программирования. Мы почти никогда не делаем параллельно одно и то же, чтобы потом сравнивать и выбирать лучшее.
Ещё одно важное отличие — в том, что реальный код, который мы пишем, существует и продолжает поддерживаться достаточно долго. Это не процесс «сделал-забыл» и лишь бы тесты проходили. Важно помнить, что ваш код может продолжать жить — не только исполняться, но и редактироваться — в течение многих лет после написания.
О других конкурсах по фронтенду
Вы без труда найдёте в интернете сайты с задачами чисто по JavaScript. Это, по сути, то же самое спортивное программирование, просто на конкретном языке. Кроме того, существует формат «code in the dark», когда макет верстается без просмотра результата, вслепую, видишь только код. Соревнования, подобные нашему, особо не распространены, поскольку — в силу специфики разработки интерфейсов — очень сложно подобрать хорошие задачи и сделать для них автоматическую проверку. В Яндексе исторически сложилась сильная школа автоматического тестирования фронтренда, в том числе с использованием сравнения скриншотов из реальных браузеров. На основе этих наработок мы и стремились сделать проверки задач в конкурсе. Для нас это тоже эксперимент, но мы уверены, что он получится, и уже готовимся развивать тему дальше.
Автор: veged
