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

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

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

Начать курс

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

Code review — это не просто формальность, а мощный инструмент для роста команды и повышения качества кода. Для начинающих PHP-разработчиков процесс ревью часто кажется пугающим: «А вдруг я пропущу баг?», «Как сказать коллеге, что его код плохой?». В этой статье мы разберем, на что обращать внимание при проверке PHP-кода и как давать обратную связь, чтобы она была полезной, а не обидной.

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

Начнем с технической стороны. Вот основные категории, которые стоит проверять при code review PHP-проекта:

Безопасность (Security) — самая критичная зона. Проверьте, нет ли SQL-инъекций, XSS-уязвимостей, незащищенных входных данных.
Соответствие стандартам кодирования — PSR-1, PSR-12 (или стандарты вашей команды). Это читаемость и единообразие.
Производительность — избегайте излишних запросов к БД, неоптимальных циклов, тяжелых операций внутри циклов.
Архитектура и логика — соблюдение принципов SOLID, DRY, KISS. Не дублируется ли код? Не слишком ли сложна логика?
Обработка ошибок — есть ли try-catch? Корректно ли логируются исключения? Не подавляются ли ошибки?
Типизация и строгость — использует ли код strict_types? Правильно ли указаны типы аргументов и возвращаемых значений?

Вот пример плохого и хорошего кода с точки зрения безопасности:

<?php
// ПЛОХО: уязвимость к SQL-инъекции
$query = "SELECT * FROM users WHERE id = " . $_GET['id'];
$result = mysqli_query($conn, $query);

// ХОРОШО: использование подготовленных запросов
$stmt = $conn->prepare("SELECT * FROM users WHERE id = ?");
$stmt->bind_param("i", $id);
$id = (int)$_GET['id'];
$stmt->execute();
$result = $stmt->get_result();
?>

2. Как давать обратную связь: принципы конструктивного ревью

Техническая часть — это половина дела. Вторая половина — это умение донести свои замечания так, чтобы автор кода захотел их исправить, а не обиделся или защищался.

Основные правила обратной связи:

Говорите о коде, а не о человеке. Вместо «Ты написал ужасный код» скажите «В этом месте есть потенциальная уязвимость, давай обсудим, как её исправить».
Используйте «Я-сообщения». «Я вижу, что здесь может возникнуть ошибка, потому что...» — это звучит мягче, чем «Ты ошибся».
Объясняйте «почему». Не просто «Используй prepared statements», а «Prepared statements защищают от SQL-инъекций, потому что отделяют данные от кода запроса».
Предлагайте альтернативы. Вместо «Это плохо» покажите, как можно сделать лучше.
Хвалите за хорошее. Не забывайте отмечать удачные решения: «Отличная идея вынести валидацию в отдельный класс!».

Пример конструктивного комментария:

<!-- ПЛОХОЙ комментарий -->
<!-- Почему ты не используешь строгую типизацию? Это же база! -->

<!-- ХОРОШИЙ комментарий -->
<!-- Предлагаю добавить declare(strict_types=1) в начало файла. 
Это заставит PHP проверять типы строго и предотвратит случайные 
неявные преобразования, которые могут привести к багам. -->

3. Типичные ошибки PHP-кода, которые стоит искать при ревью

Вот список частых проблем, которые встречаются в коде начинающих PHP-разработчиков. Обратите на них особое внимание:

Отсутствие валидации входных данных. Никогда не доверяйте $_GET, $_POST, $_REQUEST, $_FILES.
Глобальные переменные и суперглобальные массивы внутри функций. Это нарушает инкапсуляцию и усложняет тестирование.
Смешивание логики и представления. PHP-код не должен быть вперемешку с HTML. Используйте шаблонизаторы (Twig, Blade) или хотя бы отделяйте логику.
Отсутствие обработки ошибок. Если код может выбросить исключение, его нужно ловить и обрабатывать (логировать, показывать пользователю понятное сообщение).
Неоптимальные запросы к БД. N+1 проблема — когда в цикле выполняются отдельные запросы для каждой записи. Используйте JOIN или eager loading.
Жестко закодированные значения (magic numbers). Вместо if ($status == 3) используйте константы: if ($status === Status::ACTIVE).

Пример проблемы N+1 и её решения:

<?php
// ПЛОХО: N+1 запросов
$users = $db->query("SELECT * FROM users");
foreach ($users as $user) {
    $posts = $db->query("SELECT * FROM posts WHERE user_id = " . $user['id']);
    // ... обрабатываем посты
}

// ХОРОШО: один запрос с JOIN
$usersWithPosts = $db->query("
    SELECT u.*, p.title AS post_title 
    FROM users u 
    LEFT JOIN posts p ON u.id = p.user_id
");
// или используем ORM с жадной загрузкой (eager loading)
?>

4. Практические советы: как организовать процесс code review в команде

Чтобы ревью приносило пользу, а не превращалось в бюрократию, следуйте этим рекомендациям:

Не ревьюйте слишком большие изменения. Чем больше diff, тем выше вероятность пропустить ошибку. Оптимальный размер — 200-400 строк кода на одно ревью.
Используйте автоматические инструменты. PHPStan, Psalm, PHP