Рефакторинг PHP кода: когда он нужен и как его делать

Рефакторинг PHP кода: когда и как

Рано или поздно каждый PHP-разработчик сталкивается с кодом, который хочется переписать. Иногда это огромный «легаси-монолит» с тысячами строк, написанных в процедурном стиле. Иногда — свежий, но уже запутанный проект, в котором любое изменение вызывает «баги» в неожиданных местах. Именно в такие моменты возникает вопрос: а не пора ли заняться рефакторингом?

Рефакторинг PHP кода — это не переписывание всего с нуля и не героический «большой взрыв». Это методичное, безопасное изменение внутренней структуры программы без изменения её внешнего поведения. Другими словами, пользователь не должен заметить разницы, а вот разработчик — должен вздохнуть с облегчением.

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

Когда нужен рефакторинг PHP кода? Три главных симптома

Не каждое желание «причесать код» является обоснованным. Вот три железобетонных признака того, что рефакторинг PHP кода — это не прихоть, а необходимость.

Симптом 1: «Код-спагетти» и эффект бабочки

Вы меняете одну строчку в контроллере, и падает модуль оплаты. Вы добавляете новое поле в базу данных, и перестает работать генерация PDF-отчета. Знакомо? Это классический признак плохой архитектуры, где каждый элемент слишком тесно связан с другими.

Симптом 2: Большой «легаси-код» без тестов

Если вы боитесь нажать кнопку «Отправить» на сервер, потому что изменения могут что-то сломать — это звоночек. Отсутствие тестов — не приговор, но если код настолько запутан, что написать тест для него невозможно, значит, пора наводить порядок.

Симптом 3: Время добавления новой фичи растет экспоненциально

Когда-то вы добавляли новую функцию за час. Теперь на ту же задачу уходит два дня, а кодовая база выросла всего на 10%. Это верный признак того, что технический долг достиг критической массы.

Важно помнить: рефакторинг PHP кода не должен проводиться «просто так». Он должен решать конкретную бизнес-задачу: ускорение разработки, снижение количества багов, упрощение поддержки.

Когда рефакторинг PHP кода делать НЕ нужно

Как ни странно, есть ситуации, когда рефакторинг принесет больше вреда, чем пользы. Запомните эти случаи:

• Код работает и не планируется к изменению. Если функционал стабилен, а новых фич не предвидится — не трогайте его. «Работает — не лезь».
• Отсутствие тестов. Без тестов вы не сможете проверить, что ничего не сломали. Сначала напишите тесты, потом рефакторинг.
• Сроки горят. Рефакторинг в состоянии цейтнота приводит к небрежности и новым багам.
• «Синдром чистого кода». Желание переписать чужой код только потому, что он написан не так, как вы привыкли — не повод для рефакторинга.

Как безопасно проводить рефакторинг PHP кода: пошаговая стратегия

Рефакторинг — это как операция на сердце. Нельзя просто «открыть и посмотреть». Нужна подготовка, инструменты и план. Вот проверенная стратегия.

Шаг 1: Создайте «защитную сетку» из тестов

Прежде чем менять код, убедитесь, что вы можете откатить изменения или проверить, что ничего не сломалось. Если тестов нет — напишите их. Хотя бы интеграционные или приемочные (end-to-end).

Пример: допустим, у вас есть функция, которая форматирует цену:

<?php
// Старый код без тестов
function formatPrice($price) {
    return number_format($price, 2, ',', ' ') . ' руб.';
}
?>

Перед рефакторингом напишите простой тест (даже вручную):

<?php
// Простейший тест
assert(formatPrice(1234.5) === '1 234,50 руб.');
?>

Теперь вы можете быть уверены, что после изменений функция будет работать так же.

Шаг 2: Рефакторинг малыми шагами (правило «одного изменения за раз»)

Не пытайтесь переписать весь класс за один вечер. Разбейте задачу на микрошаги. Каждый шаг — это одно логическое изменение, которое не ломает тесты.

Плохой пример: одновременно переименовать переменные, разбить большой метод на несколько маленьких и добавить PHPDoc.

Хороший пример: Сначала только переименовать переменные. Запустить тесты. Затем разбить метод. Снова запустить тесты. И так далее.

Шаг 3: Используйте инструменты автоматизации

В PHP есть отличные инструменты, которые помогут вам провести рефакторинг быстрее и безопаснее:

• PHPStan или Psalm — статический анализ кода. Они найдут ошибки типов и несоответствия, которые вы могли пропустить.
• PHP CodeSniffer или PHP CS Fixer — приведут код к единому стандарту (PSR-12).
• Rector — мощный инструмент для автоматического рефакторинга. Он может сам переименовать классы, переписать устаревшие конструкции и многое другое.

Реальные примеры рефакторинга PHP кода (до и после)

Теория — это хорошо, но давайте посмотрим на конкретные примеры. Мы возьмем типичные «болезни» PHP-кода и покажем, как их лечить.

Пример 1: Избавляемся от «магических чисел» и дублирования

Проблема: В коде разбросаны числа, смысл которых непонятен. Например, скидка 15% и порог бесплатной доставки 1000 рублей.

До рефакторинга:

<?php
function calculateTotal($items) {
    $total = 0;
    foreach ($items as $item) {
        $total += $item['price'] * $item['quantity'];
    }
    if ($total > 1000) { // Что за 1000?
        $total = $total * 0.85; // Что за 0.85?
    }
    return $total;
}
?>

После рефакторинга:

<?php
class DiscountService {
    const FREE_SHIPPING_THRESHOLD = 1000;
    const DISCOUNT_RATE = 0.85; // 15% скидка

    public function applyDiscount(float $total): float {
        if ($total > self::FREE_SHIPPING_THRES