Прошедшая неделя принесла битву за 300 спартанцев запросов и охоту за призраками UI.

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

Так и произошло у меня на прошлой неделе. Сосредоточился на «точечной хирургии» карточки товара магазина, а попутно нашёл проблемы со страницами брендов и меню на 300+ запросов, а также проблемы UI, которые призрачными проявлениями бередили округу и наводили на пользователей ужас.

Результаты оказались впечатляющими.

Битва за страницу и меню «Бренды»

Работая с карточкой товара, искал решение ряда проблем и периодически, в списке товаров, натыкался на раздел «Бренды». Не мог понять: откуда в отладке там столько запросов и тормозов?! Страница грузится 6-7 секунд (нет, это не тренд «сикс-севен» это СПАРТА ЛЕГАСИ)!

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

Можете себе представить, что меню и список всех брендов генерировали более 300 (!) лишних запросов к базе данных? Каждый раз. Каждый пользователь. Каждый такой запрос — это микро-тормоз, который в сумме превращал загрузку страницы в пытку для сервера, не говоря уже о пользователях.

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

Результат в цифрах

Было: • Общее время: \5.7 сек\ • Запросы к БД: \416\ (время: \1.56 сек\) • Память: \85 МБ\

Стало: • Общее время: \1.2 сек\ (**ускорение почти в 5 раз!**) • Запросы к БД: \85\ (время: \0.13 сек\ — **в 12 раз меньше!**) • Память: \63 МБ\ (**на четверть легче**)

Для магазина это значит одно: страница теперь открывается почти мгновенно, а сервер перестаёт задыхаться при высоком трафике.

Охота на «призраков» интерфейса

Скорость — это не всё. Есть ещё UX-баги, которые сводят с ума.

Проблема «вечной загрузки»: При нажатии кнопки «Назад» в браузере из каталога страница могла уйти в бесконечную загрузку. Стоит ли говорить, что подобные «призраки» толпами блуждают по проекту? (: Исправил логику возврата — теперь всё работает корректно и предсказуемо. *(Попутно зафиксировал утечки памяти в текущем UI — это будет моей следующей большой целью).*

Плашка «В наличии»: Раньше при каждом наведении курсора на эту надпись выполнялся тяжёлый запрос к БД. Из-за задержки пользователь мог видеть лаг в отображении результата — то самое «ничего не работает». Теперь данные подготавливаются один раз при рендере списка товаров. Навёл курсор — и информация появляется мгновенно, без лишних обращений к серверу. Радуем всех менеджеров и посетителей новыми улучшениями.

Карта для будущих поколений

Любое изменение должно быть задокументировано. Актуализировал документацию по проекту и сохранил все наработки в Git. Обновил тесты. Теперь потомкам не придётся использовать археологические навыки и выдумывать историю работы «колеса», а достаточно будет прочитать «как это было и с какой целью».

Вот такие итоги недели

Рефакторинг — это не про «сделать красиво ради красоты». Это про уважение: - к времени пользователя (который не ждёт 6 секунд) - к ресурсам сервера (который теперь отдыхает) - к коллегам (которые получат чистый код и документацию)

Маленькие победы складываются в большую надёжность системы.

#AmbrionDev #легаси #рефакторинг #отчётзанеделю

«А какие «быстрые победы» в оптимизации запоминаются вам больше всего? Делитесь в комментариях! 👇»