Сайт «Серьёзных игр». Как это было
В ноябре я работал над новым сайтом «Серьёзных игр». По пунктам расскажу, чему научился за время работы и с какими проблемами столкнулся. (Осторожно: много модных фронтендерских терминов.)
Сроки
У нас было 3 недели, чтобы запуститься
За первую неделю я продумал жизненный цикл приложения, написал его скелет и набор интерфейсных компонентов. Это помогло разделить страницы между членами команды и успеть в срок.
Серверный рендеринг
Для поисковых роботов важно, чтобы страницы с разными адресами показывали разный контент. Поэтому для одностраничных приложений придумали серверный рендеринг — когда приложение запускается на сервере, проигрывается до нужного места, и в таком виде отдаётся браузеру. А он потом запускает приложение с этой точки.
С Редаксом я к тому моменту уже успел поработать, а серверный рендеринг настраивал впервые. За два дня разобрался с Экспрессом и настроил маршрутизацию. Сделал её такой, что и клиент, и сервер работают с одним роутером, поэтому вся логика маршрутизации собрана в одном месте.
Документация
Проект объёмный, над ним работает несколько технологов. Чтобы не было путаницы, работа шла согласованно, а проект был целостным, я его задокументировал.
В документации описал архитектуру:
- как работать с Редаксом,
- как работает сервер,
- как пользоваться роутером;
...компоненты:
- их свойства,
- примеры вызова;
...работу с данными:
- разницу между статическими и динамическими данными,
- как обращаться к серверу API;
...работу с гитом:
- как писать сообщения коммитов,
- что делать, прежде чем отправлять пул-реквест;
- какие опен-сорс решения мы используем, и почему именно эти;
...сборку проекта:
- локальную,
- тестовую,
- для продакшена;
...обнаруженные проблемы, и как их избежать.
Опен-сорс решения
Я определял, какие из готовых компонентов мы будем использовать в проекте, а какие нет. Просматривал документацию каждого из вариантов, сравнивал свойства и методы. Решал, какие лучше подойдут для наших задач.
Это важно, потому что проблемы стороннего кода станут нашими проблемами, как только мы начнём использовать его.
Например, со стилизованным селектом я промахнулся. Взял готовый, но в процессе работы оказалось, что ему не достаёт свойств, а возможности расширить нет. Пришлось написать свой.
Разделение задач и делегирование
Мне доверили делить задачи между членами команды. Чтобы правильно делегировать, я разобрался, кто с чем быстрее справится. Научился корректировать план разработки, на личном опыте понял, что такое MVP.
Чтобы быстро проводить код-ревью, научился вчитываться в чужой код. Это оказалось сложнее, чем я думал
Настройка тестовой и продакшн-сборки
Настроил сборку проекта для тестового и продакшн-сервера. Разобрался с process.env и трудностями с окружением на разных платформах.
В продакшн-сборку мы отправляем только сжатые версии библиотек, скриптов и стилей. Логи и ошибки выводим не в консоли браузера, а отправляем на наш сервер статистики. Таким образом, если появляется ошибка, то приходит письмо с её описанием.
Итого
Большой объём работ, незнакомые технологии, тесты, код-ревью и сжатый срок добавили к проекту вызов. Для меня это был один из самых насыщенных проектов. Круто, что мы смогли разобраться с проблемами и запуститься в срок.