Что должен уметь фронтенд-разработчик в известной компании, которая предлагает своим покупателям широкий спектр товаров: от спортивного инвентаря и специализированной одежды до мячиков-антистресс? Знать стандартные решения и немного DevOps, использовать весь свой наработанный опыт, внимательно вести документацию. Как придумываются велосипеды в IT-подразделении «Спортмастера» во время конференции «Frontend Live 2020» рассказал фронтендер Sportmaster Lab Сергей Чумак.

Frontend в Sportmaster Lab

На онлайн-конференциях у сотрудников «Спортмастера» всегда были бейджи с названием компании, именем и фамилией. Когда коллеги подходили к нам и видели их, удивлялись и спрашивали: «Спортмастер? Но ведь это магазины, в которых продается спортивный инвентарь. Что вы здесь делаете?».

У нас есть группа компаний, среди которых такие известные, как «Спортмастер», Ostin и FUNDAY. Чтобы вся эта огромная машина работала, внутри существует целая IT-индустрия. Сейчас она называется Sportmaster Lab. В компании работает больше тысячи человек: около 400 разработчиков, пара десятков фронтендеров и другие сотрудники. Поэтому нет совершенно ничего удивительного в том, что у нас есть фронтенд.

Мы занимаемся IT-поддержкой производства, логистики, финансов. Кроме того, в IT-индустрии компании существуют департаменты веб-разработки, обеспечения качества и другие.

Мы разрабатываем новые системы и поддерживаем старые. В компании очень большой стек технологий. Я сам чаще работаю с веб-приложениями. Но есть у нас и сайты-гиганты – это «Спортмастер» и Ostin, а есть те, которые поменьше: FUNDAY, группа компаний монобрендов, таких, как Columbia, FILA, Demix. Часто приходится сталкиваться с внутренней автоматизацией. Так что для разработчиков существует довольно большой плацдарм, где можно прокачать свои скиллы и получить новый опыт.

Фронтенд в классическом понимании этого понятия зародился у нас всего несколько лет назад. До этого, как и у всех, наверное, были всевозможные фреймворки: Knockout, jQuery – куда же без него? Все это накладывало достаточно много ограничений и на разработку, и на поиск новых сотрудников, и на перемещение между проектами.

Но пришло время для того, чтобы разработать стандарты. Первое, что мы сделали – разобрали вообще все наши ПО: из чего они состоят, на чем написаны. А после этого создали радар технологий.

В настоящее время мы все контролируем. Если необходимо завести в радар какую-то новую технологию, мы формируем команду R&D. Эта команда хорошенько исследует технологию, составляет по ней документ, заводит его в центр компетенции, и уже в нем она досконально разбирается. Если все хорошо и технология действительно будет полезна, заводим ее в радар.

Кроме того, мы провели большой R&D для выбора фреймворка. И решили, что это будет Vue. Все новое ПО пишется на Vue, старое – переписывается. И я могу сказать, что фронтенд у нас существует на достаточно хорошем уровне.

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

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

Конечно, вполне логично при таких объемах работы, что во внутренней автоматизации у нас задействовано очень много людей.

Как проходит работа с сайтами

Своеобразным первопроходцем среди всех наших сайтов был Ostin. Он написан при помощи новых технологий (Node, Vue, SSR и т.д.), вышел в продакшен, развивается, и все работает просто замечательно.

Сайт текущей вариации «Спортмастера» был написан года 4 назад. И с ним не все так хорошо, как этого бы хотелось. Но открою вам секрет: сейчас идет разработка «Спортмастер 3.0». Совсем скоро мы выйдем в продакшен и вы его увидите. Он написан при помощи новых технологий, и у него будет новый дизайн.

Кроме того, у нас есть сайты монобрендов. Это собственные торговые марки и те, которыми мы торгуем по франшизе. Их довольно много. Речь идет Demix, Skechers, Columbia, FILA и т.д.

Когда-то я был временным ядром команды монобрендов, занимал позицию тимлида, а сейчас являюсь их куратором.
Эти сайты тоже разработаны на новом стеке: Node, Vue, SSR.

До перехода в IT, я 5 лет проработал в бизнесе. И я стараюсь создать продукт, который был бы удобен и с пользовательской стороны, и со стороны IT — чтобы внутренний мир проекта был понятен всем участникам разработки. Я не раз сталкивался со свежесозданным ПО, и у меня есть ощущение, что программисты пишут его только для себя.

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

Первая состоит в том, что компании пренебрегают метриками пользователя. Мы замечали, что на моем любимом сайте карточка открывается 20 секунд, а любой фильтр применяется за 10-15. И когда людям нужно что-то купить, вместо того, чтобы наслаждаться процессом, они вынуждены бороться с сайтом.

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

Поэтому сначала мы разработали компонентную схему: обозначили, где у нас будут находиться определенные блоки, какими будут связи и т.д. Мы очень много времени прорабатывали именно эти связи, чтобы все работало как можно быстрее.

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

Мы смогли добиться минимизации размера ответа, и он стал совсем маленьким. У нас существуют тесты. И если на каком-то endpoint договорились, что идет такой-то формат js, то когда он поменяется, сборка не пройдет. API стало более стандартизированным. Кроме того, мы установили по всем endpoints одинаковое название ключей, и теперь можно очень быстро сориентироваться в случае необходимости.

В ходе работы над новым функционалом, мы очень быстро договариваемся о контракте. В нашей компании front drive API: то есть фронтенд диктует бэкенду, что нам необходимо для успешной работы.

Кроме того, у нас есть договоренность по статике. У нас много frontend-разработчиков, и они понимают, что такое папка Public, где хранится статика, и какие проблемы она может доставить.

У меня были проекты, в которых эта папка в течение первых лет весила 10 МБ, а потом увеличивалась 20 ГБ. Тут все понятно: там лежали 10 файликов, но в какой-то момент появлялось требование изменить картинки, это делали, а старые картинки не удаляли.
И у нас появилась договоренность о том, что мы отказываемся от Public. Эту папку автоматически генерирует наше приложение.

Сейчас нашему проекту уже около 2 лет, и вся статика весит не больше 30 МБ. Так как мы работаем по CI/CD, все разворачивается очень быстро, статика разворачивается буквально за секунду, а весь деплой занимает около 10-15 секунд.

Мы максимально вели разработку таким образом, чтобы не было дублирования кода. И верстали так, чтобы можно было адаптировать сделанное под разные устройства. Большая работа была проделана с SEO-специалистами. Они рассказали нам, какие блоки SEO-зависимые, а какие нет, и выделили критический CSS. Он приезжает вместе с версткой.

Все эти действия привели к тому, что если вы зайдете на Columbia, FILA, или Demix, увидите, что вся страничка весит не больше 20 КБ. А сайты открываются мгновенно.

Детальный подход к документации

Когда мы разрабатывали сайты-монобренды, начали писать документацию не в том виде, как это обычно принято – список компонентов и описание того, что они делают. Документировали все: проекты, команды запуски, зависимости, расписали всю сборку, окружение, code style и т.д. Изначально это все делалось просто для себя.

Когда мы начинали этот проект, в команде было всего 5 человек, а сейчас в ней уже 20. И новым сотрудникам уже ничего не нужно рассказывать на словах. Мы просто отдаем им документацию, они читают ее 2-3 дня, после чего готовы идти в бой и справляться с поставленными задачами.

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

T-Shaped People во фронтенде

Мы идем в направлении T-shape.



Довольно долгое время в мире пропагандировался принцип разделения труда и делаются ставки на узких специалистов, которые могут делать что-то одно, но быстро и качественно.
Такие узкие специалисты называются I-shaped. Обычно они хорошо разбираются в одном направлении, но имеют смутные представления о смежных областях. Это долго было удобным, ведь человек хорошо мог сделать свою часть проекта и передать ее другим. Но при этом рабочий процесс выстраивается довольно долго, и в команды иногда приходится привлекать сторонних экспертов.

T-Shaped People — это специалисты, которые гармонично сочетают широкий кругозор с углубленной экспертностью в одной из областей, на которой они специализируются. Это уникальные эксперты, которые могут сочетать в своей работе разные области.

В реальности это выглядит следующим образом: можно наращивать компетенции вокруг разработки, но если в процессе работы в команде стал необходим DevOps, все тот же разработчик может узнать о нем побольше и применить знания на практике. Это делается для того, чтобы команда могла справиться с поставленными задачами сама, без привлечения сторонних специалистов.

Мы планируем, что внутри компании скоро будут специалисты, которые знают и фронтенд, и DevOps. Думаю, в настоящее время таких очень мало, или их не существует вовсе.
Но уже сегодня мы можем писать бэкенд на Node, фронтент – на Vue, а можем перенести все это в Kubernetes. При этом, всем этим может заниматься один человек.

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

Управление внутри компании

У нас второй год идет трансформация по гибким методологиям — мы работаем по Agile. Сейчас в компании около 50 продуктовых команд. Они разрабатывают продукты и занимаются их сопровождением. Каждая команда – это целый ряд сотрудников с разными компетенциями: бизнес, аналитики, разработчики, тестировщики, автоматизаторы. Есть портал с метриками команд, есть департамент методологов. Они взаимодействуют с командами напрямую, помогая настроить потоки. Если речь идет о команде более высокого уровня, методологи убеждаются в компетентности ее членов, после чего команда продолжает работать самостоятельно. Именно так и происходит управление внутри компании.

Sportmaster Lab — созданное в 2019 году IT-подразделение, в котором в настоящее время трудятся более тысячи специалистов. Его сотрудники поддерживают работоспособность сайтов компании, занимаются приложением и рассказывают о том, как создается «Спортмастер».