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

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

Сроки

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

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

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

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

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

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

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

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

• как работать с Редаксом,
• как работает сервер,
• как пользоваться роутером;

...компоненты:

• их свойства,
• примеры вызова;

...работу с данными:

• разницу между статическими и динамическими данными,
• как обращаться к серверу API;

...работу с гитом:

• как писать сообщения коммитов,
• что делать, прежде чем отправлять пул-реквест;
• какие опен-сорс решения мы используем, и почему именно эти;

...сборку проекта:

• локальную,
• тестовую,
• для продакшена;

...обнаруженные проблемы, и как их избежать.

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

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

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

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

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

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

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

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

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

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

Итого

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