Как переписать панель управления и не потерять всех клиентов

Сегодня хотим рассказать о том, как мы в Timeweb Cloud переводили панель управления с PHP на React.

На старте Timeweb Cloud не был отдельным направлением: мы начинали с услуги VDS в рамках хостинга Timeweb. В 2021 году приняли решение развивать Cloud отдельно. У бизнеса было много требований к тому, как должен выглядеть продукт: клиентам хотелось видеть более широкую продуктовую линейку, современный дизайн, актуальный технологический стек, высокую скорость доставки изменений. Независимое развитие Клауда как раз предполагало фокус на этих критериях.

В момент, когда Timeweb Cloud встал на путь становления облачным провайдером, у нас уже была панель управления для VDS. Для старта — хорошо, но она явно требовала доработки, поскольку была технически несовершенной. В то время, когда ее начинали писать, рынок не был столь дальновидным, про open source мало кто думал, да и сами подходы к разработке сильно отличались от современных. Вот с какими проблемами мы столкнулись:

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

2) Большая часть кода была написана недостаточно качественно, возникало много багов — все это не позволяло нам гарантировать желаемый клиентский опыт.

3) Мир дизайна изменился: клиенты хотели работать с ненагруженными интерфейсами без визуального шума, а наша панель выглядела визуально устаревшей и ей требовался редизайн.

Вот так выглядела панель раньше:

У нас было несколько вариантов работы:

• Написать новую панель рядом со старой и начать разработку сразу по всем правилам.
• Взять текущую панель и развивать ее в имеющемся технологическом стеке, например, сделав только редизайн. В этом случае из-за того, что панель была написана не только на PHP, но и на backbone/marionette, с частями jquery и нативного js, код за много лет работы стал сложным и запутанным, а его поддержка — дорогой.
• Переставить решение на другой стек: мы выбрали React и Effector (хотя к нему пришли не сразу, сперва был MobX).

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

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

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

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

Что дает внедрение React:

• Не нужно постоянно загружать всю страницу полностью. За счет этого сайт работает быстрее, потому что при работе не нужно тянуть огромный объем данных: с сервера подтягивается только то, что необходимо отобразить прямо здесь и сейчас.
• Удобно настраивать взаимодействие элементов на странице: например, когда мы заходим в непрочитанное сообщение, нам легко в другом месте сбросить счетчик уведомлений. Все данные обновляются реактивно.
• Для работы с React много разработчиков на рынке: их легко искать, онбордить, и они готовы работать на нашем стеке, потому что их опыт будет релевантен в любой другой компании, которая также работает на React.
• У React постоянно выходят обновления и библиотеки для любой функции и чаще всего не обязательно писать что-то с нуля: можно взять решение, которое используется в других продуктах, потому что оно протестировано и проверено на практике.

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

Первым релизом мы выпустили новую сетку для контента, цвет фона, шрифты, левое и верхнее меню, список VDS, баз данных и балансировщиков. В этот день команда сидела до часу ночи и мониторила реакцию клиентов. В потоке базовых вопросов, непонимания и даже хейта, некоторые пользователи писали реальные, дельные замечания. Такой подход помог нам увидеть то, что мы могли не учесть по тем или иным причинам и исправить в real-time режиме. Помогали мониторить фидбек и вносить правки даже фаундеры.

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

У нас была цель сделать так, чтобы панель работала быстро и классно — это самые важные показатели современного продукта. Для того, чтобы добиться нужного эффекта, команда сформировала набор метрик из нескольких параметров (здесь только некоторые из них), например: скорость загрузки, скорость первой отрисовки, скорость первого взаимодействия клиента со страниц. Команда старалась довести каждый параметр до максимально высоких значений, параллельно меняя еще и бэкэнд.

Когда мы переписали примерно 65% панели, к нам пришел фаундер со словами:

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

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

Вот так темная и светлая тема выглядят сейчас:

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

Сразу после релиза мы получили вопрос от клиентов, которые работают на Windows, о том почему обновление выглядит так плохо. Мы, конечно, сразу все исправили, но кейс запомнили надолго.

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

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

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

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

Поделитесь своим опытом перехода на другой стек в комментариях!