Чек‑лист начинающего разработчика для code review

Code review - это не «проверка тебя», а проверка кода. Мы все хотим один результат: чтобы проект жил и развивался.

Зачем нужен code review

Цель                               Как достигается
──────────────────────────────────  ──────────────────────────────
Найти баги до продакшена            Свежий взгляд ловит то, что автор не видит
Распространение знаний              Ревьюер учит, автор учится (и наоборот)
Единый стиль кода                   Команда пишет «одним почерком»
Улучшение архитектуры               Второе мнение ловит overengineering
Документация решений                PR-описание = история «почему так»

Чек‑лист перед PR/MR

Подготовка

  • Один PR = одна задача (не мешай фикс бага с рефакторингом)
  • Понятное описание: что изменено, зачем и как проверить
  • Размер: до 400 строк изменений (больше - сложно ревьюить качественно)

Чистота

  • Нет мусорных файлов (.DS_Store, node_modules, .idea/)
  • Нет секретов (.env, API-ключи, пароли, токены)
  • Нет отладочного кода (fmt.Println, console.log, TODO: remove)
  • Нет закомментированного кода (Git помнит всё)

Качество

Если ты сам находишь и исправляешь мелочи до ревью - тебя любят. Это закон природы. Сделай self-review перед тем, как назначить ревьюера.

Как писать описание PR

Хорошее описание PR экономит время ревьюеру и будущим читателям:

## Что сделано
Добавлен rate limiter для API-эндпоинтов авторизации.

## Зачем
BUG-042: боты перебирают пароли, нужно ограничить
до 5 попыток в минуту на IP.

## Как проверить
1. Запустить `make dev`
2. Сделать 6 запросов на /api/login за минуту
3. 6-й должен вернуть 429 Too Many Requests

## Что НЕ изменено
Лимиты для аутентифицированных пользователей - отдельная задача.

Автоматизация: линтеры и CI

Автоматические проверки снимают с ревьюера рутину:

Инструмент         Что проверяет
─────────────────  ──────────────────────────────
golangci-lint      Стиль, сложность, ошибки в Go
gofumpt            Форматирование (строже gofmt)
eslint + prettier  Стиль JavaScript/TypeScript
gitleaks           Утечки секретов
go test -race      Data races в тестах

# .gitlab-ci.yml - автопроверки при каждом MR
lint:
  script:
 - golangci-lint run ./...
 - gitleaks detect --source .

test:
  script:
 - go test -race ./...

Когда линтер и тесты запускаются в CI - ревьюер не тратит время на «у тебя отступ не тот» и фокусируется на логике и архитектуре.

Линтер ловит стиль и простые баги. Он не видит: ошибки в бизнес-логике, плохую архитектуру, отсутствие edge cases, неточное именование. Для этого нужен человек.

Культура code review

Как давать фидбэк

Плохо                               Хорошо
──────────────────────────────────  ──────────────────────────────
«Это неправильно»                   «Здесь может быть race condition,
                                     если два запроса придут
                                     одновременно. Может, mutex?»

«Переделай»                         «Предлагаю вынести валидацию
                                     в отдельную функцию -
                                     проще будет тестировать»

«Почему ты так сделал?»             «Интересный подход. Я бы
                                     рассмотрел X, потому что Y.
                                     Что думаешь?»

Правила конструктивного фидбэка:

  1. Критикуй код, не автора - «эта функция сложная» vs «ты написал сложно»
  2. Предлагай альтернативу - не просто «плохо», а «лучше так, потому что...»
  3. Отличай блокеры от nit - пометь nit: мелочи, которые не блокируют merge
  4. Хвали хорошие решения - «чистая функция, легко читается» мотивирует

Как принимать фидбэк

  1. Не принимай на свой счёт - ревьюят код, не тебя
  2. Задавай вопросы - «можешь объяснить, почему X лучше Y?»
  3. Благодари за находки - ревьюер потратил время, чтобы помочь
  4. Не спорь о вкусах - если линтер не ловит, а команда не решила, уступи

Типичные находки при ревью

Большинство этих категорий - прямое отражение принципов SOLID: жёсткие зависимости - нарушение DIP, толстые классы - SRP, фиксированные switch - OCP.

Категория        Что искать
───────────────  ──────────────────────────────────────
Безопасность     SQL-инъекции, XSS, секреты в коде
Ошибки           Необработанные err, panic вместо error
Производительность  N+1 запросы, отсутствие индексов
Тестируемость    Жёсткие зависимости, глобальные переменные
Именование       Непонятные имена, нарушение конвенций Go
Граничные случаи nil, пустые слайсы, нулевые значения

Self-review: ревью самого себя

Перед тем как назначить ревьюера, просмотри diff сам:

  1. Открой PR в GitLab/GitHub
  2. Прочитай каждый файл как чужой код
  3. Задай себе вопросы: «Понятно ли это через месяц? Есть ли тесты? Обработаны ли ошибки?»
  4. Исправь всё, что нашёл

Self-review ловит 30-50% замечаний до ревьюера. Это экономит время всем.

Механика самого MR - шаблоны описания, Draft, squash on merge, треды и approval rules - разобрана в уроке про Merge Request в треке Git.

Мини-задание

  • Возьми свой последний PR и пройди по чек-листу из этого урока
  • Напиши описание PR по шаблону «Что / Зачем / Как проверить»
  • Настрой golangci-lint в CI если ещё не настроен
  • При следующем ревью используй формат «nit:» для мелочей

Зарегистрируйтесь бесплатно, чтобы пройти квиз, решить задание с автопроверкой и вести прогресс.