Решённые задачи

Начну с самого интересного - результатов своей работы.

1. 🏗️ Монорепа разделена на фронтенд и бэкенд

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

2. 💼 Управление Бизнес Логикой стало прозрачным

Главная особенность текущего проекта (точнее, одного из тех что в работе) заключается в требовании гибкой настройки ветвлений пользовательских сценариев, периодически требующее добавления шагов (в дальнейшем - дискретных состояний Стейт-Машины). Новая реализация позволяет донастраивать различные сценарии поведения веб-приложения и дебажить эти сценарии на разных уровнях (внутренняя бизнес-логика, данные по API, вычисляемые значения на основе вводимых пользователем данных - одним словом, все параметры, влияющие на успешный User Flow). Чего удалось достичь:

• Настраиваемая последовательность шагов на уровне конфига Стейт Менеджера XState. Это важно, т.к. в прошлых версиях проекта, с ростом вариантов ветвлений сценариев, настраивать их было весьма затруднительно (императивный подход к мутации DOM требовал анализа всего кода без возможности декомпозировать его на отдельные подзадачи)
• Появилась гибкая валидация ответов API на уровне СТМ (сценарий не пойдет дальше, если ответ не соответствует валидации, все подобные ошибки теперь можно транслировать в UI с соответствующей формулировкой)
• На всем промежутке времени моей деятельности в компании не было представителя бизнеса, который полностью владел логикой приложения (даже Продукт менеджер не мог знать до конца, как должен работать проект - но это не его вина, просто проект очень стар). На мои попытки явным образом получить описание бизнес-логики в виде вопросов "Как оно должно здесь работать?", я получал что-то вроде "Оно же как-то работает, а сейчас требуется внести небольшое изменение" (опять же, ничего страшного, просто наша команда попала в ловушку легаси без доки). Итак, Документация - теперь она есть в виде конфига XState + интерактивной схемы! Теперь любой разработчик не только будет знать как оно работает, но сможет это объяснить любому менеджеру и при необходимости быстро донастроить поведение интерфейса при появлении новых требований.

3. 📈 Повысилась эффективность отдела IT

Дебаг и отладка теперь не требуют лишних усилий, репорты по критическим ошибкам сами летят в "Телегу"...

• BFF сервисы (немного фулл-стека): Появилась возможность добавить автоматизированные оповещения об ошибках по socket.io (далее некоторые из них улетают в Google Sheets, Telegram и т.д.) по Socket соединению в отдельном потоке Web Worker. Анализ логов теперь также может быть автоматизирован для ретрансляции в чаты в виде задач (возможно даже с указанием исполнителя).
• Добавлена функция "Сообщить об ошибке", позволяющая отправить сообщение от Пользователя и историю его взаимодействия с приложением для анализа Разработчиком

4. 🤝 Кастомизация UI для каждого из партнёров стала гибче

Решены проблемы вариативности дизайна, связанные с тем, что кодовая база собираемого приложения ранее НЕ была разделена на подпроекты - изменения интерфейса (как и бизнес-логики) затрагивали одну единственную сборку для всех пользователей. Не было unit & e2e тестов - теперь есть.

Резюме в сухом остатке

В 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, наконец, пришло время переписать старое легаси на современные рельсы (ссылка на демо будет в конце). Чтоб эта информация не потерялась, решил задокументировать текущие подходы и достижения в области решения проблем отладки в числе прочего (это был основной момент, требующий решения, т.к. устранив это, мы стали работать намного эффективнее).