Хабрахабр

Алгоритмические задачи во фронтенде. Примеры и конкурс Яндекса

Вчера стартовал новый Яндекс.Блиц — на этот раз конкурс будет интересен разработчикам интерфейсов. Обладателям мест с первого по пятое мы предложим устроиться к нам по упрощённой схеме: одна секция собеседования вместо четырёх. Тем самым Блиц остаётся наиболее быстрым способом попасть в Яндекс.

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

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

О задачах

Алгоритмически насыщенные задачи в разработке интерфейсов в Яндексе возникали всегда. Я могу вспомнить примеры ещё от 2005–2006 года. Одной из таких задач была система работы с абстрактными событиями. Требовалось сделать ядро, которое позволит навешивать обработчики (заданные функцией) на произвольные события (заданные строкой), после чего — вызывать определённое событие и удалять привязку обработчика. Дополнительная сложность состояла в том, что три перечисленные основные операции должны были выполняться максимально быстро. Про это даже есть секция в одном из старых докладов.

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

Основной сложностью было сделать его достаточно быстрым, сохранив при этом желаемую семантическую выразительность. Были и задачи, связанные с разработкой шаблонизатора Яндекса, известного по ключевым словам XJST и BEMTHML. Подробно про это можно посмотреть в многочисленных докладах, Вот одни из первых докладов с подробностями: events.yandex.ru/lib/talks/43 и events.yandex.ru/lib/talks/329, есть и многие другие.

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

В процессе, пока у пользователя «в руке» был зажат объект и он водил им по экрану, требовалось подсвечивать те элементы, на которые можно было его «сбросить». Например, в одной из первых версий Яндекс.Почты можно было перетаскивать почти все ключевые элементы друг на друга: письма в папки, метки на письма, письма на метки и даже папки на письма. Наивная реализация «в лоб» тормозила до невозможности.

Отличия реальных задач от конкурсных

Задачи внутри Яндекса, как правило, решаются в командном режиме. Человек не предоставлен сам себе, как в конкурсе. Он может получить помощь от коллег и должен стыковать способ своего решения с интересами других участников процесса.

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

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

О других конкурсах по фронтенду

Вы без труда найдёте в интернете сайты с задачами чисто по JavaScript. Это, по сути, то же самое спортивное программирование, просто на конкретном языке. Кроме того, существует формат «code in the dark», когда макет верстается без просмотра результата, вслепую, видишь только код. Соревнования, подобные нашему, особо не распространены, поскольку — в силу специфики разработки интерфейсов — очень сложно подобрать хорошие задачи и сделать для них автоматическую проверку. В Яндексе исторически сложилась сильная школа автоматического тестирования фронтренда, в том числе с использованием сравнения скриншотов из реальных браузеров. На основе этих наработок мы и стремились сделать проверки задач в конкурсе. Для нас это тоже эксперимент, но мы уверены, что он получится, и уже готовимся развивать тему дальше.

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

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

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

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

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