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

Именно в этом балансе рождаются самые интересные решения. Те, которые не просто «чинят» код, а открывают карту дальнейших преображений.

Не всегда решение будет красивым. И не всегда быстрым — иногда приходится делать шаг назад, добавляя слои абстракции или сетевые вызовы. Но это часть пути.

Пример из вчерашнего дня

После первого этапа рефакторинга нашёл ещё одну проблему: построение меню страдало от классической N+1 — вложенные запросы к БД в цикле.

Напомню, где мы были: - Время запросов к БД: 0.4778 s - Количество запросов: 114 - Время PHP: 0.9898 s - Общее время: 1.4675 s - Память: 63.55 MB

Само меню в легаси было закешировано и выдавало: 0.0037 мс — очень быстро!

Но внутри этого «быстро» скрывалась нагрузка на БД, которая тянула вниз часть системы.

После исправления — вынес логику в отдельное API. Время генерации этого участка стало: 0.0946 мс

Больше. Намного больше. Почему? Добавились накладные расходы на сеть.

Но! Если посмотреть на чистое время работы API (без сети): 0.0020 мс — это уже в два раза быстрее изначального!

Провал или победа?

Со стороны может показаться: «Шеф, всё пропало! Мы замедлили сайт!»

Но это взгляд обывателя. А со стороны архитектуры — теперь у нас есть:

Контроль данных — меню управляется централизованно Минимальный простой при переходе на новую версию Готовность к будущему — когда API заработает локально, без сетевых задержек, мы получим реальные 0.0020 мс

Да, сейчас мы терпим ~0.09 мс. Но на фоне общей загрузки страницы это незаметно. Зато мы разгрузили базу и дали возможность менеджерам работать без тормозов в их ЛК. Они тоже люди, им тоже нужно дышать. (;

Планируйте развитие системы. Особенно когда делаете рефакторинг.

Не бойтесь временных компромиссов — они покупают вам время в будущем и спасают драгоценные часы, которые ушли бы на бесконечные переписывания.

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

Как говорил один мудрый разработчик: «Иногда нужно замедлиться, чтобы потом ускориться по-настоящему» (;

#мотивациядлятебя #позитивдлятебя #рефакторинг #архитектура #компромисс #оптимизация #AmbrionDev #legacy #php

А вам приходилось принимать решения, которые казались шагом назад? Как справились? 👇