Заказ и планирование

Контекст

Это приложение на Angular 11 - сердце платформы услуг для частных и корпоративных клиентов. Без него большая часть заказов просто не обрабатывается.

Когда я впервые открыл проект, это был настоящий шок: код без документации, без надёжных тестов, с такой глубокой технической задолженностью, что несколько разработчиков до меня уже бросили проект. Я тогда не знал Angular, и некому было объяснить, как всё работает.

Я мог просто выжить, но решил разобраться.

В итоге я полностью взял проект на себя - в одиночку, почти на два года.

Технический долг

Структурный технический долг

• 🍝 Код «спагетти»: логика разбросана и тесно переплетена, с множеством скрытых побочных эффектов, которые сложно предугадать при изменении
• ⚠️ Нестабильные внутренние зависимости, критически важные и опасные для удаления без риска поломки системы
• 🔀 Смешение фронтенд- и бэкенд-логики: нет чёткого разделения ответственности

Проявления

• 📦 Главный JS-бандл весил 15 МБ, что сильно тормозило загрузку на слабых устройствах и сетях - прямое влияние на выручку
• ⏳ Каждое изменение занимало в разы больше времени
• 💥 Высокий риск ошибок и регрессий

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

Оптимизация производительности

Между спринтами я заметил крупную возможность ускорения и предложил сделать её приоритетной.

Главная причина тормозов - размер начального бандла: загружался код всего приложения вне зависимости от страницы.

Я сосредоточился на самом эффективном решении - ленивая загрузка модулей:

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

• 🧼 Очистка корневого модуля: удаление лишних зависимостей и перенос их в места реального использования

  ⚠️ Важное замечание

  В этой версии Angular перенос зависимости без проверки всех её точек использования может нарушить существующее поведение без ошибок.

Размер бандла уменьшился с 15 до 5.59 МБ, но этого было недостаточно.

Дальнейшие улучшения включали:

• 🧹 Очистку общего модуля
• 🗑️ Удаление мертвого кода
• ⚡ Оптимизацию сетевых запросов

Результат

• ✅ Сокращение основного бандла на 88%
• ✅ Lighthouse вырос с ~34 до ~78, экономия 13,2 секунды на LCP
• ✅ Бизнес-логика сохранена, 0 регрессий

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

Lighthouse до оптимизации

После: + ~130% улучшения

Переработка личного кабинета

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

Цели:

• 🧠 Улучшение UX: интерфейс отражает структуру данных и ведёт пользователя к нужному действию
• 📞 Снижение нагрузки на поддержку
• 🎨Современный UI: интерфейс стал понятным, приятным и последовательным

Подход и реализация

В процессе я:

• 👥 Работал с не-техническими стейкхолдерами, собирая реальные отзывы
• 📊 Принимал дизайн-решения на основе данных Hotjar
• 🧬 Обеспечил полную обратную совместимость, учитывая старое «спагетти»-поведение
• 🛫 Внёс изменения постепенно через A/B тестирование с отслеживанием через аналитику

Версия v1 показывала все детали заказа на одной странице: статус, список услуг, действия. Пользователь сам должен был разбираться, что и когда делать, что приводило к путанице и обращениям в поддержку.

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

Создание и планирование: единый workflow

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

Я уточнил реальный scope и сделал единый многошаговый workflow: выбор услуг с ценами, подтверждение слотов в общем календаре, без наследования старого технического долга.

Всё интегрировано с существующей системой без регрессий.

Документация и передача знаний

Быть единственным разработчиком сложного приложения значит нести скрытую ответственность: код живёт дольше авторов.

В этом проекте это особенно заметно: коллективная память исчезла с уходом предыдущих разработчиков. Я не хотел повторять эту историю.

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

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

Итог

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

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

Основные выводы:

• ⚡ Изучение Angular и RxJS прямо на продакшене
• 🛠️ Полная ответственность за стратегическое приложение
• 🧠 Понимание влияния своих решений на поддерживаемость