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

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

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

Начать курс

Введение: зачем нужен Code Review в C++

Code review (ревью кода) — одна из ключевых практик профессиональной разработки. В мире C++, где ошибки управления памятью или неверное использование STL могут привести к трудноуловимым багам и утечкам, качественное ревью становится критически важным. Это не просто проверка стиля, а систематический поиск потенциальных проблем: от логических ошибок до нарушений RAII (Resource Acquisition Is Initialization).

В этой статье мы разберём, на что обращать внимание при code review C++ кода, как формулировать замечания, чтобы они были полезны, а не обидны, и как внедрить культуру здорового ревью в команде.

Что проверять при Code Review C++ кода

Ревью — это не чтение кода как книги. Это активный анализ. Используйте следующий чек-лист, чтобы не упустить важное.

1. Безопасность работы с памятью и RAII

C++ не прощает невнимательности к ресурсам. Проверяйте:

Используются ли умные указатели (std::unique_ptr, std::shared_ptr) вместо голых new/delete.
Нет ли утечек памяти, если код использует сырые указатели в сложных сценариях.
Соблюдается ли принцип RAII: все ресурсы (файлы, сокеты, мьютексы) должны быть обёрнуты в классы с корректными конструктором и деструктором.

// Плохо: сырой указатель, ручное управление
void process() {
    int* data = new int[100];
    // ... забыли delete[] — утечка
}

// Хорошо: умный указатель
void process() {
    auto data = std::make_unique<int[]>(100);
    // память освободится автоматически
}

2. Корректность использования STL и алгоритмов

Стандартная библиотека C++ мощна, но её легко применить неправильно.

Проверьте, не написан ли ручной цикл там, где можно использовать std::find, std::copy, std::transform.
Обратите внимание на инвалидацию итераторов (например, после push_back в std::vector).
Используется ли const для ссылок, когда объект не изменяется (const std::string& вместо std::string).

// Плохо: копирование строки и ручной поиск
bool hasValue(std::string s, char c) {
    for (size_t i = 0; i < s.size(); ++i) {
        if (s[i] == c) return true;
    }
    return false;
}

// Хорошо: const ссылка и алгоритм
bool hasValue(const std::string& s, char c) {
    return std::find(s.begin(), s.end(), c) != s.end();
}

3. Правила современного C++ (C++11/14/17/20)

Устаревшие конструкции — красный флаг.

Замена typedef на using.
Использование auto для сложных типов (но не везде — читаемость важнее).
Применение nullptr вместо NULL или 0.
Проверка на constexpr и noexcept там, где это уместно.

4. Производительность и архитектура

Даже корректный код может быть медленным или неподдерживаемым.

Избегайте лишних копирований: передача по значению больших объектов — частая ошибка.
Проверьте, не вызывается ли виртуальная функция в горячем цикле (если это не оправдано).
Оцените связанность классов: не нарушает ли код принципы SOLID.

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

Техническая часть — половина дела. Вторая половина — человеческий фактор. Неправильно поданное замечание может демотивировать автора или вызвать конфликт.

1. Разделяйте критику кода и личности

Говорите о коде, а не о программисте. Вместо «Ты написал ужасный код» скажите «В этом месте лучше использовать умный указатель, чтобы избежать утечки».

2. Используйте «почему», а не «что»

Объясняйте причину замечания. Это помогает автору учиться.

Плохо: «Замени на const».
Хорошо: «Добавь const, чтобы гарантировать, что функция не изменит аргумент — это повысит безопасность и читаемость».

3. Применяйте технику «сэндвича»

Начните с позитива (что сделано хорошо), затем укажите на проблемы, закончите ободрением. Пример:

«Отличная архитектура модуля! Есть один нюанс с утечкой памяти в функции loadData — давай обернём указатель в unique_ptr. В остальном код готов к мержу.»

4. Предлагайте, а не требуйте

Используйте формулировки: «А что если попробовать…», «Мне кажется, здесь будет безопаснее…». Дайте автору право выбора, если нет строгих стандартов команды.