Сайт «Серьёзных игр». Как это было

В ноябре я работал над новым сайтом «Серьёзных игр». По пунктам расскажу, чему научился за время работы и с какими проблемами столкнулся. (Осторожно: много модных фронтендерских терминов.)

Сроки

У нас было 3 недели, чтобы запуститься :–)

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

Серверный рендеринг

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

С Редаксом я к тому моменту уже успел поработать, а серверный рендеринг настраивал впервые. За два дня разобрался с Экспрессом и настроил маршрутизацию. Сделал её такой, что и клиент, и сервер работают с одним роутером, поэтому вся логика маршрутизации собрана в одном месте.

Документация

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

В документации описал:

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

Опен‑сорс решения

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

Это важно, потому что проблемы стороннего кода станут нашими проблемами, как только мы начнём использовать его.

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

Разделение задач и делегирование

Мне доверили делить задачи между членами команды. Чтобы правильно делегировать, я разобрался, кто с чем быстрее справится. Научился корректировать план разработки, на личном опыте понял, что такое МВП.

Чтобы быстро проводить код‑ревью, научился вчитываться в чужой код. Это оказалось сложнее, чем я думал :–)

Настройка тестовой и продакшн‑сборки

Настроил сборку проекта для тестового и продакшн‑сервера. Разобрался с process.env и трудностями с окружением на разных платформах.

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

Итого

Большой объём работ, незнакомые технологии, тесты, код‑ревью и сжатый срок добавили к проекту вызов. Для меня это был один из самых насыщенных проектов. Круто, что мы смогли разобраться с проблемами и запуститься в срок.

← «Взлом маркетинга. Наука о том, почему мы покупаем» Конспект со встречи «Фронтенд‑фелоус» →