👀 Эффективный код ревью: показывай, а не навязывай

Код ревью — это важная часть процесса разработки. Но как часто вы сталкивались с тем, что получали комментарии вроде: «Здесь неправильно», «Переделай», «Не надо так делать»? А где же объяснение, почему неправильно и как сделать правильно?

Хороший код ревью — это когда мы прикладываем результат, а не просто пушим оппонента.

Проблема типичного код ревью

Представьте, что вы получили такой комментарий:

«Эта функция слишком большая, разбей на части»

Что вы почувствовали? Вероятно, немного раздражение и непонимание. Почему большая? Как разбить? На какие части? Что должно быть в каждой?

А теперь представьте другой вариант:

«Эта функция делает три разных вещи: получает данные, обрабатывает их и рендерит результат. Можно разбить на три функции: fetchUserData(), processUserData() и renderUserData(). Это упростит тестирование и повысит читаемость.»

Разница очевидна. Во втором случае вы сразу понимаете проблему и получаете конкретное решение.

Принципы эффективного код ревью

1. Всегда предлагай решение

Не просто указывай на проблему, а показывай, как её решить. Вместо:

// Плохо
Плохое именование переменной

Пиши:

// Хорошо
Переменная `d` не очевидна. Лучше назвать `userData` или `response`, чтобы было понятно, что она содержит.

2. Объясняй «почему», а не только «что»

// Плохо
Не используй var
 
// Хорошо
Лучше использовать `let` или `const` вместо `var`, потому что они имеют блочную область видимости и предотвращают ошибки с поднятием (hoisting).

3. Давай конкретные примеры

// Плохо
Сложная логика, можно упростить
 
// Хорошо
Можно упростить с помощью методов массивов:
const activeUsers = users
  .filter(user => user.isActive)
  .map(user => user.name);

Шаблоны эффективных комментариев

Шаблон 1: Предложение улучшения

«Сейчас [проблема]. Можно улучшить, сделав [решение]. Это даст [выгода].»

Пример:

«Сейчас компонент делает сразу несколько сетевых запросов. Можно объединить их в один с помощью Promise.all(). Это уменьшит количество запросов и ускорит загрузку.»

Шаблон 2: Объяснение проблемы

«[Код] может привести к [проблема], потому что [причина]. Лучше использовать [решение], потому что [преимущество].»

Пример:

«Использование any в TypeScript отключает проверку типов и может привести к ошибкам во время выполнения. Лучше указать конкретные типы или использовать unknown с последующей проверкой.»

Шаблон 3: Альтернативное решение

«Вместо [текущий подход] можно использовать [альтернатива]. Вот пример: [код]. Это лучше, потому что [преимущество].»

Пример:

«Вместо ручного перебора массива можно использовать find(). Пример:

const user = users.find(u => u.id === targetId);

Это короче, понятнее и быстрее, потому что find() останавливается на первом совпадении.»

Чек-лист эффективного код ревью

Перед тем как отправить комментарий, спроси себя:

✅ Ясно ли описал проблему?
✅ Предложил ли конкретное решение?
✅ Объяснил ли, почему это важно?
✅ Указал ли преимущества предлагаемого решения?
✅ Сохранил ли уважительный тон?

Польза для команды

Когда вы прикладываете результат, а не просто критикуете:

1. Автор PR растёт быстрее — получает не только критику, но и знания
2. Улучшается атмосфера в команде — люди чувствуют поддержку, а не нападение
3. Повышается качество кода — конкретные предложения легче реализовать
4. Растёт уровень всей команды — все учатся на примерах

Личный опыт: как я научился делать эффективные ревью

Раньше я тоже писал комментарии вроде: «Не надо так», «Переделай», «Плохой код». Коллеги раздражались, PR затягивались, атмосфера в команде ухудшалась.

Потом я понял: если я вижу проблему, я обязан показать, как её решить. С тех пор я всегда:

1. Пишу, что не так
2. Объясняю, почему это проблема
3. Показываю, как сделать лучше
4. Иногда даю альтернативные варианты

Результат не заставил себя ждать. PR стали проходить быстрее, коллеги начали благодарить за ревью, а код в проекте стал заметно лучше.

Вывод: будь тем, кого хочешь видеть

Хороший код ревью — это не демонстрация своего превосходства, а помощь другим стать лучше. Вместо того чтобы накидывать на ветряк критику, покажи, как можно сделать лучше.

Не говори людям, как быстро бегать. Беги быстро сам, и они последуют за тобой.

В следующий раз, когда будете делать код ревью, вспомните: ваша цель — не победить в споре, а помочь проекту и коллегам стать лучше. Покажите результат, а не просто укажите на проблему. Ваша команда скажет вам спасибо.