Как понять, что PHP-код устарел и его пора рефакторить

Legacy-код — это не обязательно плохой код. Часто это просто код, который долго приносил пользу, но теперь стал дорогим в поддержке. В нём сложно быстро внести правку, опасно обновить зависимость, непонятно, где формируется результат, и почти невозможно оценить последствия изменения.

Рефакторинг такого проекта не должен начинаться с идеи “переписать всё”. Обычно безопаснее найти самые рискованные места и постепенно привести их в управляемое состояние.

Признаки устаревшего PHP-кода

• один файл содержит HTML, SQL, бизнес-логику и отправку почты;
• контроллеры или обработчики занимают тысячи строк;
• одни и те же SQL-запросы скопированы в разные места;
• нет понятных логов ошибок;
• в коде много глобальных переменных;
• изменение одной формы ломает соседнюю;
• нет тестовой копии или простого способа отката;
• зависимости давно не обновлялись.

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

Не начинать с полного переписывания

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

Лучше сначала стабилизировать проект:

• добавить логи;
• создать тестовую копию;
• описать критичные сценарии;
• найти самые изменяемые участки;
• изолировать внешние интеграции;
• добавить минимальные проверки перед релизом.

Найти точки риска

Сначала нужно понять, какие части проекта чаще всего меняются и чаще всего ломаются. Обычно это формы, импорт, обмены, заказы, цены, остатки, почта и личный кабинет.

grep -R "mail(" -n .
grep -R "mysql_query" -n .
grep -R "file_get_contents" -n .
grep -R "curl_exec" -n .

Такие поиски быстро показывают старые участки: прямые SQL-запросы, внешние API без таймаутов, отправку писем без обработки ошибок.

Разделить код на маленькие шаги

Если обработчик формы делает всё сразу, его не нужно сразу переписывать на новую архитектуру. Сначала можно выделить понятные функции или сервисы.

public function handle(array $data): bool
{
    $this->validate($data);
    $leadId = $this->saveLead($data);
    $this->sendEmail($leadId);
    $this->sendToCrm($leadId);

    return true;
}

Даже такое разделение уже помогает: становится понятно, где валидация, где база, где почта, где CRM.

Добавить логи до изменения логики

Перед рефакторингом полезно добавить логи в критичные места. Тогда после правки можно сравнить поведение.

error_log(json_encode([
    'event' => 'order_created',
    'order_id' => $orderId,
    'source' => $source,
], JSON_UNESCAPED_UNICODE));

Не нужно писать в лог пароли, токены, полные данные карт и лишние персональные данные. Лог должен помогать диагностировать, а не создавать новый риск.

Сначала обернуть, потом заменить

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

class PriceCalculator
{
    public function calculate(array $product): float
    {
        return legacy_calculate_price($product);
    }
}

Когда все новые вызовы идут через класс, старую функцию проще заменить или покрыть проверками.

Не ломать внешний контракт

Если старый метод возвращал false при ошибке, а новый начал бросать exception, это может сломать вызывающий код. Перед изменением нужно понять контракт: входные данные, результат, ошибки, побочные эффекты.

Чек-лист первого этапа

1. Определить критичные сценарии проекта.
2. Найти самые часто изменяемые файлы.
3. Добавить логи в проблемные места.
4. Сделать тестовую копию и бэкап.
5. Выделять маленькие функции вместо полной переписи.
6. Не менять внешний контракт без проверки вызовов.
7. Изолировать внешние API и почту.
8. Проверять результат на реальных сценариях.

Рефакторинг legacy-кода должен снижать риск, а не увеличивать его. Если после каждого шага проект стал понятнее, лучше логируется и проще откатывается, движение выбрано правильно.