Решённые задачи
Начну с самого интересного - результатов своей работы.
1. 🏗️ Монорепа разделена на фронтенд и бэкенд
Проект "с нуля" - Сборка партнерской версии клиентского приложения вынесена в отдельный проект для возможности сделать независимой сборку от инфраструктуры, хост-среды и других удивительных факторов. По итогу решен ряд сложных задач по упрощению процесса разработки и деплоя (как следствие - мы могли разрабатывать и тестировать новые версии продукта с меньшими усилиями и временными затратами).
Теперь деплой фронта не требует сборки бэкенда, а сборка фронта на всех инстансах работает одинаково
2. 💼 Управление Бизнес Логикой стало прозрачным
Главная особенность текущего проекта (точнее, одного из тех что в работе) заключается в требовании гибкой настройки ветвлений пользовательских сценариев, периодически требующее добавления шагов (в дальнейшем - дискретных состояний Стейт-Машины). Новая реализация позволяет донастраивать различные сценарии поведения веб-приложения и дебажить эти сценарии на разных уровнях (внутренняя бизнес-логика, данные по API, вычисляемые значения на основе вводимых пользователем данных - одним словом, все параметры, влияющие на успешный User Flow). Чего удалось достичь:
- Настраиваемая последовательность шагов на уровне конфига Стейт Менеджера XState. Это важно, т.к. в прошлых версиях проекта, с ростом вариантов ветвлений сценариев, настраивать их было весьма затруднительно (императивный подход к мутации DOM требовал анализа всего кода без возможности декомпозировать его на отдельные подзадачи)
- Появилась гибкая валидация ответов API на уровне СТМ (сценарий не пойдет дальше, если ответ не соответствует валидации, все подобные ошибки теперь можно транслировать в UI с соответствующей формулировкой)
- На всем промежутке времени моей деятельности в компании не было представителя бизнеса, который полностью владел логикой приложения (даже Продукт менеджер не мог знать до конца, как должен работать проект - но это не его вина, просто проект очень стар). На мои попытки явным образом получить описание бизнес-логики в виде вопросов "Как оно должно здесь работать?", я получал что-то вроде "Оно же как-то работает, а сейчас требуется внести небольшое изменение" (опять же, ничего страшного, просто наша команда попала в ловушку легаси без доки). Итак, Документация - теперь она есть в виде конфига XState + интерактивной схемы! Теперь любой разработчик не только будет знать как оно работает, но сможет это объяснить любому менеджеру и при необходимости быстро донастроить поведение интерфейса при появлении новых требований.
Теперь основная часть бизнес-логики (понятная и очевидная схема пользовательских сценариев) может быть быстро настроена на уровне конфига и визуально продемонстрирована в виде интерактивной блок-схемы - что оказалось очень удобным при необходимости согласований. Взаимодействие с менеджером Продукта стало эффективнее. DX стал более совершенным и декларативным
3. 📈 Повысилась эффективность отдела IT
Дебаг и отладка теперь не требуют лишних усилий, репорты по критическим ошибкам сами летят в "Телегу"...
- BFF сервисы (немного фулл-стека): Появилась возможность добавить автоматизированные оповещения об ошибках по socket.io (далее некоторые из них улетают в Google Sheets, Telegram и т.д.) по Socket соединению в отдельном потоке Web Worker. Анализ логов теперь также может быть автоматизирован для ретрансляции в чаты в виде задач (возможно даже с указанием исполнителя).
- Добавлена функция "Сообщить об ошибке", позволяющая отправить сообщение от Пользователя и историю его взаимодействия с приложением для анализа Разработчиком
Теперь информация по каждому прецеденту прилетает в Telegram группу! Ранее были проблемы в скорости реагирования на ошибки на продакшене - их диагностика занимала много времени. Теперь анализ логов взаимодействия пользователя с интерфейсом (и не только) в рамках сессии занимает минуты
4. 🤝 Кастомизация UI для каждого из партнёров стала гибче
Решены проблемы вариативности дизайна, связанные с тем, что кодовая база собираемого приложения ранее НЕ была разделена на подпроекты - изменения интерфейса (как и бизнес-логики) затрагивали одну единственную сборку для всех пользователей. Не было unit & e2e тестов - теперь есть.
Ранее были проблемы реализации специфичного дизайна в зависимости от роли/типа пользователя. Теперь каждый из партнёров будет перенаправлен на конкретное SPA в соответствии с внешним роутом NGINX
Резюме в сухом остатке
В 2024 году вышла в релиз новая версия Offline Trade-In, которая сильно превосходит легаси, реализованное на стеке 2017 года.
Стек технологий легаси-кода (2017)
- SSR на стороне Django (Python v3.6) - по итогам рефакторинга, из этого репозитория "ушел" фронтенд (бэкенд переписывать не потребовалось);
- jQuery / JS Vanilla / Web API;
Стек технологий после рефакторинга (2024)
- Vite / React / Typescript (принято в стек как современный стандарт, когда SSR не требуется);
- XState v4.x (отлично вписался под свои задачи, связанные с ветвлением пользовательских сценариев, 5-я версия на тот момент ещё была не готова к релизам в прод);
- Valtio (минималистичный и гибкий подход к управлению состоянием на базе нативных JS механизмов объекта Proxy);
- Tailwind CSS / Headless UI (ориентированная на утилиты CSS-инфраструктура для быстрого создания современных веб-сайтов, которая позволяет удобно и быстро создавать кастомные компоненты с заданными стандартными параметрами - настройки стилей типовых элеметнов и т.д.);
- CSS modules / SCSS (для компонентов с нестандартной версткой);
- Необычное решение: Web Socket connection in Web Worker (для отправки логов в отдельном потоке, не нагружая основной поток); Бонус - Одно сокет-соединение на все открытые вкладки для страниц, использующих SharedWorker в случае, если он поддерживается браузером;
Немного деталей
В 2020 году код фронта (при моем первом знакомстве с ним) представлял собой спагетти-легаси и содержал в себе императивную логику преобразования DOM в зависимости от различных событий (понятие Бизнес Логика в приложении отсутствовало в декларативном виде). Таким образом с 2017 по 2024 велась доработка фич (+ максимально возможный рефакторинг в пользу DX), но все это время требовался новый продукт с более удачным подходом в плане поддержки кода и управлению Бизнес Логикой на уровне менеджмента - именно это и будет составлять основную ценность в будущем. И в 2024, наконец, пришло время переписать старое легаси на современные рельсы (ссылка на демо будет в конце). Чтоб эта информация не потерялась, решил задокументировать текущие подходы и достижения в области решения проблем отладки в числе прочего (это был основной момент, требующий решения, т.к. устранив это, мы стали работать намного эффективнее).