Code review в PHP: что проверять и как давать обратную связь на практике

Онлайн-тренажер Python для начинающих

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

Начать курс

Введение: почему code review — это не про контроль, а про рост

Code review (ревью кода) в PHP — это не архаичная процедура контроля начальника над подчинённым. Это профессиональный диалог между разработчиками, направленный на повышение качества кода, распространение знаний внутри команды и предотвращение ошибок на ранних этапах. Однако, как показывает практика, многие PHP-разработчики (особенно на старте) либо боятся ревью, либо превращают его в пустую формальность.

В этой статье мы разберём, на что конкретно обращать внимание при code review PHP-кода, как формулировать замечания, чтобы не обидеть коллегу, и как самому извлекать максимум пользы из этого процесса. Материал основан на реальном опыте работы с проектами на PHP 7.4+ и фреймворках вроде Laravel и Symfony.

1. Что проверять в PHP-коде: практический чек-лист

Универсального списка не существует, но для PHP-проектов можно выделить 5 ключевых зон, которые обязательно нужно прогнать через призму ревью.

1.1. Безопасность (Security)

PHP — язык, где легко допустить уязвимость. Первым делом проверяем:

SQL-инъекции: используются ли подготовленные запросы (PDO / prepared statements) вместо конкатенации строк?
XSS (межсайтовый скриптинг): экранируется ли вывод через htmlspecialchars() или шаблонизаторы (Blade, Twig)?
CSRF-защита: есть ли токены на формах, изменяющих состояние?
Валидация ввода: проверяется ли тип и длина данных на серверной стороне?

// Плохо: конкатенация в SQL
$query = "SELECT * FROM users WHERE id = " . $_GET['id'];

// Хорошо: подготовленный запрос PDO
$stmt = $pdo->prepare('SELECT * FROM users WHERE id = :id');
$stmt->execute(['id' => $_GET['id']]);

1.2. Архитектура и SOLID

Даже если проект — не энтерпрайз, базовые принципы должны соблюдаться:

Единая ответственность: не делает ли класс/метод слишком много?
Инверсия зависимостей: использует ли код интерфейсы вместо конкретных классов?
Отсутствие божественных объектов: нет ли классов на 1000+ строк?

1.3. Стиль и PSR-стандарты

Для PHP это критично. Проверяем соответствие PSR-12 (стиль кодирования):

Отступы — 4 пробела, а не табуляция.
Фигурные скобки на новой строке для классов и методов.
Правильное именование: camelCase для методов, snake_case для переменных (если это не принято иначе в проекте).

1.4. Производительность

В PHP легко написать медленный код. Ищем:

Запросы в цикле (N+1 проблема) — вместо этого используйте жадную загрузку (Eager Loading) в ORM.
Игнорирование кэша: повторные вычисления одних и тех же данных.
Неэффективные функции: например, in_array() на большом массиве лучше заменить на isset($hash[$key]).

// Плохо: запрос в цикле
foreach ($users as $user) {
    $posts = DB::table('posts')->where('user_id', $user->id)->get();
}

// Хорошо: один запрос с жадной загрузкой
$users = User::with('posts')->get();

1.5. Обработка ошибок и типизация

Есть ли strict_types в начале файла?
Используются ли типы для аргументов и возвращаемых значений?
Обрабатываются ли исключения, а не глушатся голым try-catch?

2. Как давать обратную связь: от "это плохо" до "давай улучшим"

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

2.1. Правило "Сэндвича"

Начинайте с позитива, затем — конструктивная критика, и снова позитив в конце. Пример:

✅ "Отлично, что ты вынес логику в отдельный сервис — это сильно упростит тестирование."
⚠️ "Однако здесь лучше использовать интерфейс вместо конкретного класса, чтобы мы могли легко подменить реализацию."
✅ "В остальном код чистый, молодец!"

2.2. Конкретика вместо общих фраз

Вместо "этот код плохой" скажите: "В строке 45 есть потенциальная уязвимость XSS. Давай добавим экранирование через e() в шаблоне."

2.3. Разделяйте "must have" и "nice to have"

Не все правки обязательны. Используйте теги:

Блокирующие (blocker): баги, уязвимости, нарушение логики.
Рекомендации (suggestion): улучшение читаемости, рефакторинг.
Вопросы (question): "Почему выбран этот подход?" — иногда это раскрывает неочевидные требования.